Stories
Slash Boxes
Comments

SoylentNews is people

UCR Today: Study Highlights Serious Security Threat to Many Internet Users

posted by janrinok on Wednesday August 10 2016, @02:14PM   Printer-friendly
from the not-good-news dept.

MrPlow writes:

Submitted via IRC for Beige

Researchers at the University of California, Riverside (UCR) have identified a weakness in the Transmission Control Protocol (TCP) of all Linux operating systems since late 2012 that enables attackers to hijack users' internet communications completely remotely.

Such a weakness could be used to launch targeted attacks that track users' online activity, forcibly terminate a communication, hijack a conversation between hosts or degrade the privacy guarantee by anonymity networks such as Tor.

Led by Yue Cao, a computer science graduate student in UCR's Bourns College of Engineering, the research will be presented on Wednesday (Aug. 10) at the USENIX Security Symposium in Austin, Texas. The project advisor is Zhiyun Qian, an assistant professor of computer science at UCR whose research focuses on identifying security vulnerabilities to help software companies improve their systems.

While most users don't interact directly with the Linux operating system, the software runs behind-the -scenes on internet servers, android phones and a range of other devices. To transfer information from one source to another, Linux and other operating systems use the Transmission Control Protocol (TCP) to package and send data, and the Internet Protocol (IP) to ensure the information gets to the correct destination.

For example, when two people communicate by email, TCP assembles their message into a series of data packets—identified by unique sequence numbers—that are transmitted, received, and reassembled into the original message. Those TCP sequence numbers are useful to attackers, but with almost 4 billion possible sequences, it's essentially impossible to identify the sequence number associated with any particular communication by chance. The UCR researchers didn't rely on chance, though. Instead, they identified a subtle flaw (in the form of 'side channels') in the Linux software that enables attackers to infer the TCP sequence numbers associated with a particular connection with no more information than the IP address of the communicating parties.

[...] Encrypted connections (e.g., HTTPS) are immune to data injection, but they are still subject to being forcefully terminated by the attacker. The weakness would allow attackers to degrade the privacy of anonymity networks, such as Tor, by forcing the connections to route through certain relays. The attack is fast and reliable, often taking less than a minute and showing a success rate of about 90 percent. The researchers created a short video showing how the attacks works.

Source: https://ucrtoday.ucr.edu/39030

Original Submission

 
This discussion has been archived. No new comments can be posted.
UCR Today: Study Highlights Serious Security Threat to Many Internet Users | Log In/Create an Account | Top | 25 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 3, Insightful) by canopic jug on Wednesday August 10 2016, @04:04PM

    by canopic jug (3949) Subscriber Badge on Wednesday August 10 2016, @04:04PM (#386296) Journal

    Just skimming the paper, it looks like the problem is not Linux per se but the RFC itself, which is RFC 5961. The paper says this:

    The feature is outlined in RFC 5961, which is implemented faithfully in Linux kernel version 3.6 from late 2012

    So Linux is implementing the RFC as intended and there is where the bug is. The solution will be bigger than "just" patching the kernel.

    --
    Money is not free speech. Elections should not be auctions.
    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   3  

  • (Score: 0) by Anonymous Coward on Wednesday August 10 2016, @04:32PM

    by Anonymous Coward on Wednesday August 10 2016, @04:32PM (#386313)

    "So Linux is implementing the RFC as intended and there is where the bug is. The solution will be bigger than "just" patching the kernel."

    So... patching the RFC?

    (Can RFCs even be patched, or do they need to be revoked/reissued/rerequested?)

    • (Score: 0) by Anonymous Coward on Wednesday August 10 2016, @10:31PM

      by Anonymous Coward on Wednesday August 10 2016, @10:31PM (#386411)

      I think they update a header or footnote on them to state that, but otherwise keep them intact.

      And yeah RFCs can amend, revoke, or replace other RFCs, but the original RFC will not be changed.

  • (Score: 3, Interesting) by Nerdfest on Wednesday August 10 2016, @04:53PM

    by Nerdfest (80) on Wednesday August 10 2016, @04:53PM (#386321)

    Wonder why just Linux is mentioned. Does Windows implement the spec improperly? What about OSX?

    • (Score: 4, Informative) by NotSanguine on Wednesday August 10 2016, @05:07PM

      by NotSanguine (285) <{NotSanguine} {at} {SoylentNews.Org}> on Wednesday August 10 2016, @05:07PM (#386324) Homepage Journal

      Wonder why just Linux is mentioned. Does Windows implement the spec improperly? What about OSX?

      From the paper [ucr.edu]:

      The Linux kernel first implemented all the features sug-
      gested in RFC 5961, in version 3.6 in September 2012.
      The changes were backported to certain prior distribu-
      tions as well.

      Vulnerabilities in other OSes:
      We examine if the
      studied vulnerability exist in the latest Windows and
      FreeBSD OSes (The latter TCP stack is also used by
      Mac OS X). In brief, these OSes are not vulnerable to
      the attack. First of all, neither Windows nor FreeBSD
      has implemented all three conditions that trigger chal-
      lenge ACKs according to RFC 5961. More importantly,
      the ACK throttling is not found for Windows or MAC OS
      X.

      --
      No, no, you're not thinking; you're just being logical. --Niels Bohr

      • (Score: 2) by Nerdfest on Wednesday August 10 2016, @06:18PM

        by Nerdfest (80) on Wednesday August 10 2016, @06:18PM (#386341)

        Strange that neither OS has implemented a networking specification that's many years old ... but then again, it's Apple and Microsoft.

  • (Score: 5, Informative) by NotSanguine on Wednesday August 10 2016, @05:01PM

    by NotSanguine (285) <{NotSanguine} {at} {SoylentNews.Org}> on Wednesday August 10 2016, @05:01PM (#386322) Homepage Journal

    Just skimming the paper, it looks like the problem is not Linux per se but the RFC itself, which is RFC 5961. The paper says this:

    The feature is outlined in RFC 5961, which is implemented faithfully in Linux kernel version 3.6 from late 2012

    So Linux is implementing the RFC as intended and there is where the bug is. The solution will be bigger than "just" patching the kernel.

    I disagree. The issue is the implementation of this feature in the Linux kernel, not the specification in the RFC. The challenge_ack functionality is exploitable due to the linux implementation of ack throttling. To wit, the default (100) number of challenge acks is small and is a static value.

    There are ways to mitigate the vulnerability without modifying the challenge_ack functionality defined in RFC 5961. The paper's authors suggest several methods for this [ucr.edu]. One bypasses the mechanism completely (potentially causing other issues addressed in RFC 5961) and one that tweaks the implementation of ack throttling:

    The best defense strategy is to eliminate the side chan-
    nel (the global challenge ACK count) altogether. One
    can still enable the per-connection rate limit as long as
    each connection has a completely separate counter that
    does not interfere with those of other connections. The
    downside of this strategy is that if the number of connec-
    tions in a system increases, the aggregate challenge ACK
    count can go up without any bound.

    However, if one is really concerned about
    wasting resources on sending challenge ACKs, we sug-
    gest a second solution which is adding noise to the chan-
    nel. This is a common defense strategy in mitigating side
    channel attacks. Specifically, instead of having
    a fixed global challenge ACK count of 100 in all inter-
    vals, we can add random values (either positive or negative) for each interval. This will essentially confuse the
    attacker during the search process. In fact, even if the
    attacker repeats the probe many times, the result will al-
    ways differ over time. To ensure that the added random-
    ness is theoretically sound, one can even apply differ-
    ential privacy to systematically introduce noise, as was
    done recently in [28]. We leave the design of the exact
    scheme to add randomness to future work. We also plan
    to propose the defenses to the Linux community.

    What's more, the RFC's authors note the issues mentioned in TFA and paper and make the following statements about potential issues:

    From RFC 5961 [ietf.org]:

    7. ACK Throttling

          In order to alleviate multiple RSTs/SYNs from triggering multiple
          challenge ACKs, an ACK throttling mechanism is suggested as follows:

          1) The system administrator can configure the number of challenge
                ACKs that can be sent out in a given interval. For example, in
                any 5 second window, no more than 10 challenge ACKs should be
                sent.

          2) The values for both the time and number of ACKs SHOULD be tunable
                by the system administrator to accommodate different perceived
                levels of threat and/or system resources.

          It should be noted that these numbers are empirical in nature and
          have been obtained from the RST throttling mechanisms existing in
          some implementations. Also, note that no timer is needed to
          implement the above mechanism, instead a timestamp and a counter can
          be used.

          An implementation SHOULD include an ACK throttling mechanism to be
          conservative. While we have not encountered a case where the lack of
          ACK throttling can be exploited, as a fail-safe mechanism we
          recommend its use. An implementation may take an excessive number of
          invocations of the throttling mechanism as an indication that network
          conditions are unusual or hostile.

          An administrator who is more concerned about protecting his bandwidth
          and CPU utilization may set smaller ACK throttling values whereas an
          administrator who is more interested in faster cleanup of stale
          connections (i.e., concerned about excess TCP state) may decide to
          set a higher value thus allowing more RST's to be processed in any
          given time period.

          The time limit SHOULD be tunable to help timeout brute force attacks
          faster than a potential legitimate flood of RSTs.

    10. Security Considerations

          These changes to the TCP state machine do NOT protect an
          implementation from on-path attacks. It also needs to be emphasized
          that while mitigations within this document make it harder for off-
          path attackers to inject segments, it does NOT make it impossible.
          The only way to fully protect a TCP connection from both on- and off-
          path attacks is by using either IPsec Authentication Header (AH)
          [RFC4302] or IPsec Encapsulating Security Payload (ESP) [RFC4303].

          Implementers also should be aware that the attacks detailed in this
          specification are not the only attacks available to an off-path
          attacker and that the counter measures described herein are not a
          comprehensive defense against such attacks.     Emphasis added.