Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.

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: 4, Informative) by NotSanguine on Wednesday August 10 2016, @02:47PM

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

    From TFA:

    Qian said the researchers have alerted Linux about the vulnerability, which has resulted in patches applied to the latest Linux version. Until then, Qian recommends the following temporary patch that can be applied to both client and server hosts. It simply raises the `challenge ACK limit’ to an extremely large value to make it practically impossible to exploit the side channel. This can be done on Ubuntu, for instance, as follows:

            Open /etc/sysctl.conf, append a command “/net.ipv4/tcp_challenge_ack_limit = 999999999”.
            Use “sysctl -p” to update the configuration.

    Here's the paper presented [ucr.edu].

    --
    No, no, you're not thinking; you're just being logical. --Niels Bohr
    Starting Score:    1  point
    Moderation   +2  
       Informative=2, Total=2
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   4  

  • (Score: 3, Informative) by Anonymous Coward on Wednesday August 10 2016, @03:26PM

    by Anonymous Coward on Wednesday August 10 2016, @03:26PM (#386282)

    Open /etc/sysctl.conf, append a command “/net.ipv4/tcp_challenge_ack_limit = 999999999”.
    Use “sysctl -p” to update the configuration.

    That should read:

                    Open /etc/sysctl.conf, append a command “net.ipv4.tcp_challenge_ack_limit = 999999999”.
                    Use “sysctl -p” to update the configuration.

    • (Score: 2) by NotSanguine on Wednesday August 10 2016, @03:55PM

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

      Good catch. Thanks!

      That's what I get for just doing the copypasta and not proofreading other people's writing.

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

      • (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.

        • (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.

  • (Score: 2) by NotSanguine on Wednesday August 10 2016, @04:03PM

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

    As an aside, the default value for net.ipv4.tcp_challenge_ack_limit appears to be '100'.

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