
A TCP weakness in Linux systems allows network traffic hijack - attilagyorffy
http://www.isssource.com/fixing-an-internet-security-threat/
======
espes
demostration:
[https://www.youtube.com/watch?v=S4Ns5wla9DY](https://www.youtube.com/watch?v=S4Ns5wla9DY)

paper:
[https://www.usenix.org/system/files/conference/usenixsecurit...](https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf)

------
grymoire1
Apparently this command fixes the problem:

echo 'net.ipv4.tcp_challenge_ack_limit = 999999999' >>/etc/sysctl.conf;sysctl
-p

I got this from [http://www.isssource.com/fixing-an-internet-security-
threat/](http://www.isssource.com/fixing-an-internet-security-threat/) but
they had a typo

------
zx2c4
Here's the commit for fixing this:
[https://git.zx2c4.com/linux/commit/?id=75ff39ccc1bd5d3c455b6...](https://git.zx2c4.com/linux/commit/?id=75ff39ccc1bd5d3c455b6822ab09e533c551f758)

------
0x0
Currently listed as vulnerable and unfixed in Debian: [https://security-
tracker.debian.org/tracker/CVE-2016-5696](https://security-
tracker.debian.org/tracker/CVE-2016-5696)

------
caf
What's interesting is that this is a protocol bug, not an
implementation/software bug (in RFC 5961).

 _It is intriguing to realize that the three information leakages are enabled
by the three (and only three) conditions that trigger challenge ACKs..._

Indeed. It almost looks like an intentional back door.

~~~
e40
If your comment is true, then the title is misleading. It's not just Linux
that is vulnerable, right?

~~~
zokier
Of major operating systems Linux is the only one that implements that part of
the RFC

~~~
X86BSD
In whole or in part? Because FreeBSD partially supports it and one of the
authors of the RFC, Randal Stewart, is a FreeBSD source committer.

~~~
jfindley
Linux is the only OS that fully implements the RFC, and thus the only one
that's vulnerable. OSX, Windows and FBSD either don't implement it or
partially implement it, making them not vulnerable.

------
attilagyorffy
I've found this on isssource and am surprised that it has not spread like
wildfire. If the claims are true then this is an issue that should be taken
seriously. Posting here for discussion.

~~~
nmc
The vulnerability claim is very interesting.

The ISS Source article itself is garbage.

They do not explain the origin of the attack, instead simply mention _" a
subtle flaw (in the form of 'side channels')"_ [sic]. They do not explain why
their _" temporary patch"_ [sic] of raising the challenge ack limit makes the
vuln _" practically impossible to exploit"_.

Hell, they do not even link to the original paper.

~~~
cokernel
The ISS Source article appears to be a copy of the UCR press release:
[https://ucrtoday.ucr.edu/39030](https://ucrtoday.ucr.edu/39030)

------
api
Probably affects Android too since it uses the Linux kernel.

Personally I consider this to be a mild to moderate vulnerability since under
no circumstances should you _ever_ trust a non-encrypted non-authenticated
channel to be safe. TCP offers in-order delivery and decent integrity checking
but otherwise offers absolutely no security guarantees at all. From a crypto
point of view an authentication method like TCP sequence numbers should be
considered "not even there."

~~~
cjbprime
> Personally I consider this to be a mild to moderate vulnerability since
> under no circumstances should you ever trust a non-encrypted non-
> authenticated channel to be safe.

So you're saying you.. don't use TCP? That seems unlikely.

Someone using this vulnerability can prevent you from opening the encrypted
authenticated channel you're trying to be safe with (by injecting RST). I
don't see how you can call it mild.

------
p4bl0
This strongly reminds me that _Silence on the wire_ by Michal Zalewski, really
is an excellent read.

------
dozzie
Wasn't it fixed long, long ago? As I remember, kernel developers were fixing
TCP sequence numbers at some point.

~~~
attilagyorffy
I vaguely remember something around a potential fix but I lost track of it.
The strange thing is that this appeared yesterday. I haven't had time to
actually test this, am just looking to see what the community knows, whether
someone could confirm this.

~~~
cjbprime
Someone else has already linked to a fix that the Linux kernel developers
applied, which tells us that it's a confirmed problem (at least in theory):
[https://git.zx2c4.com/linux/commit/?id=75ff39ccc1bd5d3c455b6...](https://git.zx2c4.com/linux/commit/?id=75ff39ccc1bd5d3c455b6822ab09e533c551f758)

