I wrote:

> Go Linux <golinux@???> wrote:
>
>> For those of you so inclined. Is this important, old news or just academic posturing?
>
> I think it's all three !
> It looks very much related to a CVE from 2004
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2004-0230

OK, so it now looks like it is a new development - but still related.

As Arnt Karlsen mentioned in the Bootloaders thread, there a new twist which is the result of a security fix

http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_communications/

In a bid to thwart the risk from injected packets carrying the right quintuplet of source and dest IPs, source & dest ports, and sequence numbers, it now seems that there are "occasional" challenge packets sent.
Simplifying a lot, basically one end will send packets to the other asking "did you really send that ?" - so if someone is spoofing fake traffic then it'll come to light.

As these packets are globally rate limited - a third party can send a flood of dodgy packets to cause this limit to be exceeded, and thus disable the protection it provides. As I read it, the attack doesn't really bring anything new other than the ability to disable the security offered by RFC 5961 - and thus lower the threshold to that of the original CVE from 2004.

I can't help thinking that some of the threat is over-stated though. The article mentions "The only piece of information that is needed is the pair of IP addresses ... which is fairly easy to obtain". So a starting point is that you have to know that two IPs are communicating - that may be obvious for some situation, but is far from "easy to obtain" in the general case.

It then goes on to say "To successfully insert data into a connection you have to know the two IP addresses and the source and destination ports – known as a four-tuple – plus the next valid serial numbers stamped on the exchanged packets." One port number will be obvious in many cases - eg port 25 for SMTP, port 80 for HTTP - but the other end may well be using any of a random pick from 1024 to 65535.
In fact, one mitigation route for a DNS attack figured out a few years ago was the simple act of making your resolver *not* use source port 53 for outbound requests - thus avoiding the simple attack of triggering a resolver to make a lookup, and flooding it with false replies to inject fake results into it's cache.

And you still need to know the sequence numbers being used or the fake packets will be dropped as out of sequence. And of course, you need to know when the transmission is taking place.
Put another way ... IF you know that two devices are communicating, AND you know when this is taking place, AND you know the port numbers used by both ends, AND you know the packet sequence numbers - then this "new" attack will allow you to use an old attack method by disabling the mitigation put in to block it.
But if you're using SSL (or in fact, any half decent form of encryption or data validation) over the connection then the attack would fail anyway.

So while it *may* be a risk for certain type of traffic, *iff* the potential rewards are high enough to make the substantial effort worthwhile, I can't help thinking it's a bit like so many other areas of risk mitigation - worrying about a hard attack then there's an easier one. A bit like how (according to stuff I've read) cars are now so hard to drive away without the keys, that the thieves often just nick the keys from the lesser secured house.