11–20 of 25 posts
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.
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.
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.
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?
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.
Earlier quoted context omitted.
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
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
Earlier quoted context omitted.
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.
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."
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.
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.