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
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.
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 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.
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."
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.
EDIT: it's of course still sequence related, but a new vuln, not a restarting of an older, fixed one.