Linux Bug Leaves USA Today, Other Top Sites Vulnerable To Serious Hijacking Attacks (arstechnica.com)

Dan Goodin, reporting for Ars Technica: Computer scientists have discovered a serious Internet vulnerability that allows attackers to terminate connections between virtually any two parties and, if the connections aren't encrypted, inject malicious code or content into the parties' communications. The vulnerability resides in the design and implementation of RFC 5961, a relatively new Internet standard that's intended to prevent certain classes of hacking attacks. In fact, the protocol is designed in a way that it can easily open Internet users to so-called blind off-path attacks, in which hackers anywhere on the Internet can detect when any two parties are communicating over an active transmission control protocol connection. Attackers can go on to exploit the flaw to shut down the connection, inject malicious code or content into unencrypted data streams, and possibly degrade privacy guarantees provided by the Tor anonymity network. At the 25th Usenix Security Symposium on Wednesday, researchers with the University of California at Riverside and the US Army Research Laboratory will demonstrate a proof-of-concept exploit that allows them to inject content into an otherwise legitimate USA Today page that asks viewers to enter their e-mail and passwords.

Comments

TLS

[DarkOx]

And using SSL/TLS or ipsec would basically close this hole entirely. What we see here is that it might be a little easier to inject into non-ciphered non-authenticated content and there may be a slightly larger scope of attackers positioned to do it.

NON STORY

There has always been a risk that plan text traffic could be tampered with, nothing has really changed here and I don't see that risk even being significantly increased.

Re:Once again, open source is vulnerable

[OrangeTide]

Do you have some examples of secure closed source? It's hard to find examples that have an install base in the server world as big as Windows or Linux, and examples of less used systems can be a bit suspect as they could simply be a statistical anomaly or not well known and not a popular target in the hacker scene. (although some of those guys will dig into pretty much anything, especially if they can work out a cool presentation at DEF CON)

Linux vulns tend to get corrected pretty quickly, as there are a lot of contributors. And like most vulns the easy way to avoid this is not to add so many damn features.

PS - OpenBSD doesn't have this flaw, and it is also open source.

Re:Once again, open source is vulnerable

[Anonymous Coward]

Most ordinary users don't look at the source because they just want a computer that works and does what they want it to. However, publishing source code allows hackers to find the vulnerabilities more easily than guessing them with closed source software. Open source software is inherently insecure and closed source offers far greater security.

At the 25th Usenix Security Symposium on Wednesday, researchers with the University of California at Riverside and the US Army Research Laboratory will demonstrate a proof-of-concept exploit that allows them to inject content into an otherwise legitimate USA Today page that asks viewers to enter their e-mail and passwords.

It looks to me that by having the source code available, these researchers - white hats - found the vulnerability before the bad guys did. Of course, USA Today being highjacked wouldn't exactly be this horrible ordeal or any real loss to humanity.

Re:Seems too scary to be believable

[kamakazi]

Yeah, I am also having a little trouble with the "hackers anywhere" You can't inject into traffic you can't see, so saying you don't need a man in the middle is a little disingenuous. Yes, you don't need an actual man in the middle routing packets, but it appears that you need a controlled host on a subnet through which the traffic passes.

In a switched network even this would be insufficient, since in the terminal subnets (both client and server) IP traffic is only visible on the actual switchport to which the relevant host is connected.

In the routing subnets between the terminal subnets I would hope that any computers that exist (as opposed to hardware switches and routers and flow shapers and such) would be very carefully monitored and protected. I know on the college campus network I administer the routing subnets are very small (/29s or even /30s) and usually do not contain any general purpose computers.

If you have a compromised computer actually in a position to see IP traffic it has always been trivial to spoof TCP RST packets and such to break a connection.

So yes, the vulnerability exists, but I don't see anything that I will lose sleep over. The problem with the hack is it seems to require the hacker to have already owned a machine on one of the terminal subnets involved in the attack which can see a lot more than it should be able to. A promiscuous NIC still can't see switched traffic. If this is indeed the case there has been a severe misconfiguration on the network.

Even in a wireless scenario I am not sure it is a serious threat, unless the hacker has full visibility in the wired network behind the access points, since WPA2 is going to make packet injection pretty tough

I looked briefly at the RFC mentioned, and it is attempting to make the old school "spoof a RST" type attacks harder, but those attacks should be very difficult on a modern network simply because layer 2 switching makes it hard to collect the parameters needed to build the layer 3 attack packets.

There was a company a decade or so ago (maybe they still exist, I dunno) called Audible Magic which was designed to prevent downloading copyrighted music. It required a span or mirror port so it could see the entire internet feed, it then watched TCP connections, did some sort of hash based song detection, then spoofed RSTs to both ends of the connection. Didn't work all that well, probably because it took to long to detect the song, and bittorrent made it useless because you don't get big enough pieces to fingerprint the song from a single connection, so we didn't have it around too long. I just don't understand how this attack works without that full sniffer connection.

If you were to combine some kind of storm attack in the network to cause the switches to fall into dumb repeater mode then yes, you could see the packets, but at that point the network is probably too dysfunctional for the target TCP connection to stay up anyway.