On Friday 26 August 2016 23:11:23 Perry E. Metzger wrote: > On Fri, 26 Aug 2016 21:06:15 +0200 Frederic Marchal > > <frederic.marc...@wowtechnology.com> wrote: > > On Friday 26 August 2016 11:04:04 Perry E. Metzger wrote: > > > According to: > > > > > > https://security-tracker.debian.org/tracker/CVE-2016-5696 > > > > > > Wheezy and Jessie are still vulnerable. The attack in question is > > > kind of bad (it allows blind injection of arbitrary data into > > > things like http downloads) and has been known for a few weeks > > > now to the general public. > > > > I don't think the issue is that bad. > > > > It allows an attacker to find out if you are connected to a > > particular web site and makes it easier to interrupt the transfer > > by sending a RST or SYN packet or inject junk data to corrupt the > > flow. It's simple denial of service. > > You are completely wrong. This attack allows you to inject > *meaningful* things into the data flow. It isn't denial of service, > it is one of the most flexible data injection attacks in years.
You are referring to this paper by Yue Cao and al: http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf The paper explains how a patch described in RFC5961 makes it even easier to guess the correct TCP sequence number. The paper states that it is trivial to inject legitimate looking packets into a long-lived, unencrypted, TCP connection with few packets exchanged between the client and server. The requirements are: * TCP connection, * long-lived, * unencrypted, * long silences. I'll add that the protocol must allow the server to initiate data sending with only one packet (such as news pushed from the server to the client). Any protocol relying on an exchange is ruled out as the attacker won't see the victim's response. The authors found www.usatoday.com meets the requirements. Even if the requirements are met, the attack fails if the client is protected by a stateful firewall (either on a NAT router, modem or computer). The attacker needs a direct connection to an open port to probe the target system. If the attack is made against the server: I expect any decent server accepting data from a client to use https (I may be presuming too much here :-) ). The attack is also useless if the attacker can't spoof the source IP address. Routers in corporate environments usually block this by design or due to VLAN. For that reason, the attack can't come from the same LAN to bypass the border firewall. This rules out an unhappy coworker, infected computer or a student with too much time on his hands. I bet the authors demonstrated the exploit in a very hacker friendly environment by disabling the target computer firewall and using a switch to connect the attacker and the victim on the same LAN. Now, I wonder if many sites or protocols do meet the requirements. Except for the above requirements, I can't see many cases where legitimate packets injection is possible without visible side effects giving the attack away. It is not as simple as randomly injecting <script>alert("hello")</script> into any given open connection and expect it to land nicely in an HTML stream without breaking something visible to the end user (assuming the client is downloading html and not css, js, png, json,…). Yet, it is what attackers have to deal with on most sites. > > But to achieve that, you must be downloading something from a web > > site the attacker is actually targeting. The attacker must know you > > are doing so or find out by sheer luck. > > "Sheer luck" isn't hard at all. There are a half dozen good ways > understood to people in the field where you can figure out what > sites someone is looking at regularly if you are targeting them > without needing to listen in on their connection directly. Knowing someone is connected to a particular web site is only the first and easier step (just watch when someone post a message for instance). The attacker must then find (without looking at the actual connection) the following data: * the actual server IP address when multiple servers serves the web site (load balancing), * the client IP address (not as easy as it sound except when targeting an individual for which data have been collected by other channels); * the TCP source port; * a valid TCP sequence number. In the best case, it takes some time (around one minute according to the paper). The connection must last that long. AJAX is not a candidate as AJAX goes like this: Client connects to server. Client to server: is there something new? Server to client: no. Close connection. Wait some time... Client connects to server. Client to server: is there something new? Server to client: yes, display X. Close connection. Due to the keep-alive timeout, sparse AJAX requests are all independent connections. All using a different TCP sequence number and source port. They rarely last long enough to inject anything. Ssh lasts long enough with long silences the attacker can exploit to inject packets without risking conflicts with regular client/server packets. But it is encrypted. So it is impossible to inject any legitimate data. Websocket may be a better candidate. Maybe a site build with meteor.js or webtoolkit would offer some opportunities provided it doesn't use https. Plain unencrypted IMAP might work if the attacker can guess a lot of data about the actual mailbox content. Failure to get the correct data would result in the mail client displaying inconsistent data. TLS renders the attack useless except as a bothersome denial of service (please forgive the understatement if it ever happened to you :-) ). > > The download must be long > > enough (more than one minute) for the attacker to discover the set > > of parameters that will make the attack successful. > > You've forgotten how the modern web works. People have http: > connections live for very long periods of time, with dynamic content > flittering back and forth over the channel. It isn't like 1996 any
