Follow Slashdot stories on Twitter


Forgot your password?
Security The Internet Linux

Linux Bug Leaves USA Today, Other Top Sites Vulnerable To Serious Hijacking Attacks ( 115

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.
This discussion has been archived. No new comments can be posted.

Linux Bug Leaves USA Today, Other Top Sites Vulnerable To Serious Hijacking Attacks

Comments Filter:
  • TLS (Score:5, Insightful)

    by DarkOx ( 621550 ) on Wednesday August 10, 2016 @02:49PM (#52679181) Journal

    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.


    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.

    • R.I.P. IPsec (Score:4, Interesting)

      by OrangeTide ( 124937 ) on Wednesday August 10, 2016 @02:56PM (#52679229) Homepage Journal

      I wrote a tiny bit of IPsec code about 15+ years ago, for a router company thinking it would take off. It still hasn't taken off, and I've given up on anyone giving two shits about rolling out IPsec in any significant way.

      • by Anonymous Coward

        Me too (writing IPsec code years ago) and it was just so over-engineered, and had so many platform interoperability issues, no one wanted to use it. Hard to configure, hard to get right. Almost as if someone wanted it to be too complex to audit, and too full of holes.

        SSH and VPN tunnels are more useful in real life.

        • With simplicity being the goal, Id want some complexities for security; hense, smoke on the battlefields _ avoidance _ distractions are the aterior motives to discussion. IPSec, how many rules can you bend?
        • by skids ( 119237 )

          IKEv2 is a bit better in that respect than IKEv1 is.

          Really, the problem with doing IPSEC right has always been 90% inter-vendor interoperability and only 10% due to the complexities of the protocol. When you have to interoperate with vendors who have not made a complete IPSEC product, security with the well done implementations also suffers. Strongswan to Strongswan works pretty damn well, though.

    • by HBI ( 604924 )

      The DOS possibilities are ignored by you. This is a significant problem. Why bother with a DDOS via a botnet when you can do this kind of thing from a single host?

  • hackers anywhere on the Internet can detect when any two parties are communicating over an active transmission control protocol connection

    The above does not seem believable — in principle. Unless by "hackers anywhere" means "hackers able to login anywhere".

    Would any resident network experts care to comment?

    • by kamakazi ( 74641 ) on Wednesday August 10, 2016 @03:42PM (#52679523)

      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.

      • by DarkOx ( 621550 )

        I commented already that I don't think this is of concern either. If we really want to tin foil hat up though it might be possible to inject into traffic you can't see. If its highly predictable traffic.

  • by Anonymous Coward

    Am I the only one that (mis-)read the headline and went WTF?

  • I say good riddance!

  • Not A Linux Bug (Score:5, Interesting)

    by StormReaver ( 59959 ) on Wednesday August 10, 2016 @03:20PM (#52679365)

    The bug is in the RFC, which Linux implements faithfully. I find it funny that the only reason Linux is the only mainstream operating system that is vulnerable is because it's the only mainstream operating system that implements the RFC. And yes, it is a very critical bug, one which the RFC needs to address, too.

    Also, the fix was committed a few weeks ago, but distributions haven't pushed it out yet (at the time the arstechnica article was written).

    • by Anonymous Coward

      Really? Not A Linux Bug?

      How about it is a Linux bug, with ultimate responsibility going to the RFC. And no, it's not sufficient for the Linux world to say, "oh well, it's the RFC, so nothing to do with us." You used the RFC, you inherited the bug, you have a problem.

      Linux must now decide whether to wait for the RFC process to correct the issue at source (a process that could potentially take months or years), unilaterally change the spec and wait for the RFC process to catch up, or deprecate the RFC enti

      • by Dog-Cow ( 21281 )

        Your stupidity is so profound, you truly deserve to be tortured for decades.

        The very comment you replied to has a second paragraph, which you completely ignored in your rush to post a stupid rant about a complete non-issue.

    • by Mondragon ( 3537 )

      There is absolutely nowhere in the RFC that it specifies that the challenge ACK rate limiter should be a single global limiter. Claiming that the Linux implementation is "faithful" is mostly true, in a naive way, but a non-broken implementation would *also* be a "faithful" implementation of the RFC.

  • RFC5961 is flawed (Score:5, Informative)

    by kent.dickey ( 685796 ) on Wednesday August 10, 2016 @03:28PM (#52679409)

    I read the brief article, and read RFC5961, and here's a quick summary:

    A TCP connection is uniquely identified by the combination of: Source IP address; Destination IP address; Source port number; Destination port number. TCP also has a sequence number, which helps reorder packets. It also helps prevent spoofing, but spoofing is still possible. Any computer on the internet can craft a packet to send to a Destination IP address and Destination port with all the other fields spoofed. A spoofer cannot receive a reply (the Destination machine will send any replies to the indicated Source IP address, which the spoofer cannot see).

    So, it's possible to inject SYN and RST requests into valid streams, shutting down other people's connections (although you couldn't be sure you've succeeded). RFC5961 tries to prevent this by adding some cases where the SYN/RST are not treated as valid, but instead it sends a special ACK to the source requesting confirmation. To avoid denial of service, these special ACKs are rate-limited to 10 per 5 seconds. Note these special ACKs are only generated if the SYN or RST look "nearly" valid based on the sequence number, otherwise the RST or SYN is ignored.

    And that's what they discovered is the problem--open your own connection to any Destination which has long-term connections (and they picked a USA Today website, but anything would work), and every 2 seconds try to get it to generate those special SYN/RST ACKs. If it's not under "attack", you'll get your ACKs.

    Then, spoof billions of packets using a chosen source IP address (and loop through all sequence nums and port nums) and guess the dest port (say, 80).

    Now send a little traffic to the Destination on your valid connection to try to get these special SYN/RST ACKs. If you don't get your ACKs (due to the global rate limiting), then you "know" that you've stumbled upon a valid combination of Source IP/port and Destination IP/port and sequence number, so you know who's talking to the Destination machine. If you've picked a Source Address and port number not connected, then these special ACKs don't get generated, so your slow traffic generating these ACKs will not be rate limited, so you can tell this Source IP/port are not connected to this destination IP/port.

    So RF5961 turns a pesky annoyance bug into a bug where its possible to determine who's connecting to a particular website (although time consuming).

    With more care, they then figure out the sequence number--and once you have that, you can do targeted data injection. (It's always possible to do blind data injection, but the chance you can accurately inject javascript is hard since the sequence number is hard to predict).

    RFC5961 should not do global rate limiting--it leaks important data.

    • Re:RFC5961 is flawed (Score:4, Interesting)

      by kamakazi ( 74641 ) on Wednesday August 10, 2016 @04:16PM (#52679729)

      Actually, the global rate limiting may not be the problem, the fixed limit may be. If the global rate limit were periodically randomly set, instead of 100/second, somewhere between 95 and 105 per second, then this attack would not work. It depends completely on knowing the global rate limit, and assumes there is no other traffic generating challenge ACKs.

      A per connection rate limit would not accomplish the purpose of a rate limit, but an unknown global rate limit that changed fairly often would prevent this information leakage. Based on the attack time in the paper I think a rate limit that reset to a random value at a random time from 3-5 seconds would make this attack useless.

      If the time the limit changes is fixed then the attacker can synchronize with the reset clock and still achieve a workable attack window by probing to determine the new limit.

      I suppose you could skip the lifetime and just change it every second, since then the attacker would have great difficulty synchronizing with the limit counter as described in the article.

      • If you just want to know if a connection exists, the exact global rate limit doesn't matter.

        Let's say we're sending 5000 packets/sec to try to probe if a connection exists. And then we send 5 to see if we got it right (whatever you think the minimum per-second global throttle rate can be). If we get >= 3 on our test channel, then the probe is not for a valid connection. It doesn't matter if the server's throttle is to 5 per second or 200 per second.

        A per-connection rate limit does fix the DDOS amplifi

    • by Anonymous Coward

      The flaw is that RFC5961 even exist. It is trying to solve a problem in the wrong place.
      The proper solution for this problem is for networks not to allow packets with invalid source addresses (as in, does not belong to the network) to leave the network.

      Inter-networking operations and ISP's really need to start taking network sanitization seriously. Just like ISP's should handle abuse reports prudently. Those 2 together would take care of most botnet and DDoS attacks.

      Since the industry does not take care of

    • by skids ( 119237 )

      Thanks for the summary. Obviously, that points out some limitations to the attack -- you have to be on an insecure ISP that will accept your spoofed source addresses to launch it. Which addresses you can spoof can vary greatly based on the granularity of the ISP's and local network's source lockdowns, so attacking people on the same segment or the same organization may be more possible than those located elsewhere. That, and a DPI firewall on the attacked end that is able to detect such floods could prob

    • So RF5961 turns a pesky annoyance bug into a bug where its possible to determine who's connecting to a particular website

      Well what's the big deal? NextGenHacker101 showed us [] how to do that back in 2008!

  • by Anonymous Coward


    Off-Path TCP Exploits: Global Rate Limit Considered Dangerous

    Yue Cao, Zhiyun Qian, Zhongjie Wang, Tuan Dao, and Srikanth V. Krishnamurthy, University of California, Riverside; Lisa M. Marvel, United States Army Research Laboratory


    In this paper, we report a subtle yet serious side channel vulnerability (CVE-2016-5696) introduced in a recent TCP specification. The specification is faithfully implemented in Linux kernel version 3.6 (from 2012) and beyond, and affects a wide range of devices and hosts. In a nutshell, the vulnerability allows a blind off-path attacker to infer if any two arbitrary hosts on the Internet are communicating using a TCP connection. Further, if the connection is present, such an off-path attacker can also infer the TCP sequence numbers in use, from both sides of the connection; this in turn allows the attacker to cause connection termination and perform data injection attacks. We illustrate how the attack can be leveraged to disrupt or degrade the privacy guarantees of an anonymity network such as Tor, and perform web connection hijacking. Through extensive experiments, we show that the attack is fast and reliable. On average, it takes about 40 to 60 seconds to finish and the success rate is 88% to 97%. Finally, we propose changes to both the TCP specification and implementation to eliminate the root cause of the problem.

    Better fix this "Linux bug" by changing TCP specification standards? No, bitches.

    The title says Linux bug, this is bullshit. It is posted before they even demonstrated proof of concept later Wednesday
    >researchers with the University of California at Riverside and the US Army Research Laboratory will demonstrate a proof-of-concept exploit

    Over and over lately arstechnica have been quoted on Slashdot stories that have been lies. Does anybody else see this security flaw? Has anybody ever been affected by it even one time? No, they post this shit before they even demonstrate proof of concept. They call it a Linux bug yet want to change TCP/IP standards and even allude to Tor.

    Slashdot is FBI. Look at the names who are reporting this Linux bug too. "Lisa from the Army and.."


  • USAToday (Score:5, Funny)

    by tomhath ( 637240 ) on Wednesday August 10, 2016 @04:31PM (#52679819)
    If a hacker injected a story into USAToday that was total BS, would anyone notice the difference?
    • by swb ( 14022 )

      Way back in the 1980s when USA Today was just getting started, a news kiosk on campus had the logos of various papers on the wall next to the kiosk.

      One day next to the USA Today kiosk, a graffiti artist had added in extremely neat penmanship "...tomorrow the world!" in a kind of matching font.

      Not only was it pretty funny, but I think because it looked like it belonged, it never got removed.

    • by ebvwfbw ( 864834 )

      Na, it would fit right in with all the other BS.

  • Apparently Microsoft paid for the article, because its not a Linux bug. If I am not mistaken, Windows and all other TCP OSs have this problem because of the fact TCP is an insecure protocol (by itself), OF COURSE you can rewrite the packets if you are a man in the middle. This has been known for a very long time. TLS will solve this problem of course.

    • If you read the article, you would see it's not a flaw in TCP in general but in RFC 5961, which only Linux has implemented so far and thus why it's the only one that's vulnerable. It also does not require you to be in the middle of the connection. Even with TLS you can still create a denial of service using this attack.
  • The title of the article is WRONG. USA Today and most major sites are NOT vulnerable to this. If you did not notice, the video is from Match 22. The vulnerability fix was reported by the research group in July and patched upstream by the Linux kernel community shortly thereafter. USA Today and other sites were fixed ahead of this announcement back in July. Read more on this at

Basic is a high level languish. APL is a high level anguish.