What are the risks due to the "challange ACK" side channel attack [CVE-2016-5696]?

Question

I have just been reading more detailed about the recent CVE-2016-5696 vulnerability in linux kernels (version 3.6 and abov) at http://lwn.net/Articles/696868/ and there it tells that via an attack using the "challange ACK" side channel, data can be malicously injected into a TCP connection (e.g. a HTTP response/request).

I do not completely get the point, since I have always assumed that of course data can be injected/modified in a HTTP connection, because it is not encrypted to start with.

Am I right in assuming that the difference here is that this bug allows someone to inject data into a TCP connection, while not being a relaying node of that TCP connection (something they maybe phrasing off-path)?

Put more simply, is it wrong to say that essentially the CVE-2016-5696, consitutes a thread (malicious injection) which anyway existed, given tha the "on-path" relaying computer always had the change to alter content (if not prevented by encryption TLS/SSL)?

Answer 1

the difference here is that this bug allows someone to inject data into a TCP connection, while not being a relaying node of that TCP connection (something they maybe phrasing off-path)?

Anybody able to both sniff and modify/inject packets was able to modify TCP (and thus HTTP) connections before. The "challenge ACK" side channel attack replaces the requirement for direct sniffing (i.e. in-path) by a smart guess about the sequence number and port used by an existing TCP connection and thus makes it possible for an off-path attacker to modify the connection.

The attacker still needs to be able to inject the appropriate packets though, i.e. spoofing the source IP address need to be possible. If this is possible and for which IP addresses depends on the environment of the attacker. It is probably possible to fake a local IP address in most low security local networks, i.e. public hotspots or company networks. But in these even ARP spoofing might already be successful which allows the more powerful in-path attacks against the local user. Spoofing non-local IP addresses instead is harder. My somehow educated but not reliable guess is that this is probably impossible with the majority of DSL/Cable accounts because the ISP will filter spoofed IP. But it might be easier in more open networks at hosting companies or universities. And of course anybody with access to routers on the "open" internet is able to spoof IP, like internet service providers and probably also government agencies.