5 ms·

A TCP weakness in Linux systems allows network traffic hijack

129 points by attilagyorffy 10y ago

attilagyorffy 10y ago
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.
- jfindley 10y ago
  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 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696 1: https://access.redhat.com/security/cve/cve-2016-5696 https://access.redhat.com/security/cve/cve-2016-5696
- nmc 10y ago
  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 10y ago
    The ISS Source article appears to be a copy of the UCR press release: https://ucrtoday.ucr.edu/39030 https://ucrtoday.ucr.edu/39030
- alyandon 10y ago
  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.
dozzie 10y ago
Wasn't it fixed long, long ago? As I remember, kernel developers were fixing TCP sequence numbers at some point.
- attilagyorffy 10y ago
  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 10y ago
    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=75ff39ccc1bd5d3c455b6822ab09e533c551f758 https://git.zx2c4.com/linux/commit/?id=75ff39ccc1bd5d3c455b6...
- jfindley 10y ago
  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.
espes 10y ago
demostration: https://www.youtube.com/watch?v=S4Ns5wla9DY https://www.youtube.com/watch?v=S4Ns5wla9DY paper: https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf https://www.usenix.org/system/files/conference/usenixsecurit...
0x0 10y ago
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
zx2c4 10y ago
Here's the commit for fixing this: https://git.zx2c4.com/linux/commit/?id=75ff39ccc1bd5d3c455b6822ab09e533c551f758 https://git.zx2c4.com/linux/commit/?id=75ff39ccc1bd5d3c455b6...
caf 10y ago
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 10y ago
  If your comment is true, then the title is misleading. It's not just Linux that is vulnerable, right?
  - zokier 10y ago
    Of major operating systems Linux is the only one that implements that part of the RFC
    - X86BSD 10y ago
      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 10y ago
        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.
    - haasn 10y ago
      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.
grymoire1 10y ago
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
api 10y ago
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 10y ago
  > 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 10y ago
This strongly reminds me that Silence on the wire by Michal Zalewski, really is an excellent read.
heroictroll 10y ago
Earlier today I had an issue where, for some reason, my IP address was wrong. Like I was being sent through a VPN. Google and IRC were treating me as if I had a spammer's IP address. I know this is a common virus issue on Windows but couldn't find any explanation for why that would happen on Linux and, after turning on my actual VPN, it went away. So could someone explain if this is related to me? I was seriously freaked out by it, and still don't really have an explanation.

129 points by attilagyorffy 10y ago

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.

jfindley 10y ago
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 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696 1: https://access.redhat.com/security/cve/cve-2016-5696 https://access.redhat.com/security/cve/cve-2016-5696
nmc 10y ago
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 10y ago
  The ISS Source article appears to be a copy of the UCR press release: https://ucrtoday.ucr.edu/39030 https://ucrtoday.ucr.edu/39030
alyandon 10y ago
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.

dozzie 10y ago

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

attilagyorffy 10y ago
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 10y ago
  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=75ff39ccc1bd5d3c455b6822ab09e533c551f758 https://git.zx2c4.com/linux/commit/?id=75ff39ccc1bd5d3c455b6...
jfindley 10y ago
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.

espes 10y ago

demostration: https://www.youtube.com/watch?v=S4Ns5wla9DY https://www.youtube.com/watch?v=S4Ns5wla9DY paper: https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf https://www.usenix.org/system/files/conference/usenixsecurit...

0x0 10y ago

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

zx2c4 10y ago

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

caf 10y ago

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 10y ago
If your comment is true, then the title is misleading. It's not just Linux that is vulnerable, right?
- zokier 10y ago
  Of major operating systems Linux is the only one that implements that part of the RFC
  - X86BSD 10y ago
    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 10y ago
      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.
  - haasn 10y ago
    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.

grymoire1 10y ago

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

api 10y ago

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 10y ago
> 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 10y ago

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

heroictroll 10y ago

Earlier today I had an issue where, for some reason, my IP address was wrong. Like I was being sent through a VPN. Google and IRC were treating me as if I had a spammer's IP address. I know this is a common virus issue on Windows but couldn't find any explanation for why that would happen on Linux and, after turning on my actual VPN, it went away. So could someone explain if this is related to me? I was seriously freaked out by it, and still don't really have an explanation.