A TCP weakness in Linux systems allows network traffic hijack

demostration: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=S4Ns5wla9DY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=S4Ns5wla9DY</a><p>paper: <a href="https:&#x2F;&#x2F;www.usenix.org&#x2F;system&#x2F;files&#x2F;conference&#x2F;usenixsecurity16&#x2F;sec16_paper_cao.pdf" rel="nofollow">https:&#x2F;&#x2F;www.usenix.org&#x2F;system&#x2F;files&#x2F;conference&#x2F;usenixsecurit...</a>

Apparently this command fixes the problem:<p>echo &#x27;net.ipv4.tcp_challenge_ack_limit = 999999999&#x27; &gt;&gt;&#x2F;etc&#x2F;sysctl.conf;sysctl -p<p>I got this from <a href="http:&#x2F;&#x2F;www.isssource.com&#x2F;fixing-an-internet-security-threat&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.isssource.com&#x2F;fixing-an-internet-security-threat&#x2F;</a> but they had a typo

Here&#x27;s the commit for fixing this: <a href="https:&#x2F;&#x2F;git.zx2c4.com&#x2F;linux&#x2F;commit&#x2F;?id=75ff39ccc1bd5d3c455b6822ab09e533c551f758" rel="nofollow">https:&#x2F;&#x2F;git.zx2c4.com&#x2F;linux&#x2F;commit&#x2F;?id=75ff39ccc1bd5d3c455b6...</a>

Currently listed as vulnerable and unfixed in Debian: <a href="https:&#x2F;&#x2F;security-tracker.debian.org&#x2F;tracker&#x2F;CVE-2016-5696" rel="nofollow">https:&#x2F;&#x2F;security-tracker.debian.org&#x2F;tracker&#x2F;CVE-2016-5696</a>

What&#x27;s interesting is that this is a protocol bug, not an implementation&#x2F;software bug (in RFC 5961).<p><i>It is intriguing to realize that the three information leakages are enabled by the three (and only three) conditions that trigger challenge ACKs...</i><p>Indeed. It almost looks like an intentional back door.

I&#x27;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.

Probably affects Android too since it uses the Linux kernel.<p>Personally I consider this to be a mild to moderate vulnerability since under no circumstances should you <i>ever</i> 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 &quot;not even there.&quot;

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

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