A TCP weakness in Linux systems allows network traffic hijack | Hacker News Reader

A TCP weakness in Linux systems allows network traffic hijack

isssource.com

129 pointsattilagyorffy23 comments

Open articleView on HN

demostration: https://www.youtube.com/watch?v=S4Ns5wla9DY

paper: https://www.usenix.org/system/files/conference/usenixsecurit...

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/ but they had a typo

Here's the commit for fixing this: https://git.zx2c4.com/linux/commit/?id=75ff39ccc1bd5d3c455b6...

Currently listed as vulnerable and unfixed in Debian: https://security-tracker.debian.org/tracker/CVE-2016-5696

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.

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

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

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.

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.

I still think the title is misleading. Compare:

“A TCP weakness in Linux systems allows ...” vs “A TCP weakness allows ... on Linux systems”

Technically, it's not just Linux that's affected - it's the TCP protocol itself. The “on Linux systems” part is sort of redundant, and only serves to point out that other operating systems are unaffected as they don't implement that part of the RFC.

Not quite -- the RFC recommended rate limiting challenge ACKs, but it didn't say to do it with a per-system global variable that would leak shared state. From the paper:

> Therefore, the Linux kernel has faithfully implemented this feature by storing the challenge ACK counter in a global variable shared by all TCP connections. This approach, unfortunately, creates an undesirable side channel, as will be elaborated.

I think it's reasonable to call it a Linux bug. You can certainly criticize the RFC as failing to disclose (or more likely, failing to realize) the risk of an insecure implementation with side channels.

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.

So far it looks pretty real. CVE exists[0], been picked up by RedHat[1]. It's possible that they're wrong - I haven't personally verified it - but at this point it'd be very surprising. Apart from anything else, these are serious researchers with real track records.

I'm proceeding on the assumption that it's real, and working towards ensuring everything (with a kernel >= 3.6 and < 4.7) is patched. I'd humbly suggest it might be a good idea for others to do so also.

0: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696 1: https://access.redhat.com/security/cve/cve-2016-5696

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.

The ISS Source article appears to be a copy of the UCR press release: https://ucrtoday.ucr.edu/39030

I skimmed over the paper and that is pretty scary stuff. Just being able to infer that two arbitrary hosts are communicating with each other is bad enough but this seems to allow for arbitrary data injection and connection reset attacks.

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."

> 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.

This strongly reminds me that Silence on the wire by Michal Zalewski, really is an excellent read.

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

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.

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...

There's been a few TCP sequence related vulnerabilities over the years, but this is slightly different - it's actually a problem with how ACKs are processed, making it far easier than it should be to conduct a well-known attack type (blind in-window).

EDIT: it's of course still sequence related, but a new vuln, not a restarting of an older, fixed one.

Reply on news.ycombinator.com