Slashdot Mirror

← Back to Stories (view on slashdot.org)

TCP Vulnerability Published

Posted by ryuzaki0 on from the DOS-for-fun-and-profit dept.

Bob Slidell writes "According to Yahoo!, there is a critical flaw in TCP that affects everyone and everything. The article is scant on details and long on fear, hopefully someone will post more details on this." The advisory has more information, and is long on details but only moderate on fear.

16 of 676 comments (clear)

  1. OpenBSD is safe? by Anonymous Coward · · Score: 5, Informative

    This just hit the misc@openbsd mail list:
    Date: Tue, 20 Apr 2004 12:57:12 -0600
    From: Theo de Raadt <deraadt@cvs.openbsd.org>
    [snip]

    In the OpenBSD case, this is something not to worry about. For what
    they discuss, OpenBSD handles this extremely well.

    We'll explain more in a week or so.
    It sounds (again) like proactive security auditting saves the day!
    1. Re:OpenBSD is safe? by Jeremiah+Cornelius · · Score: 5, Informative
      Yeah. The biggest problem here is the ease with which one could DoS the BGP-4 protocol.

      The Internet BGP tables are ricketey enough these days - they don't need every other route to "flap"!

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
  2. Implementation issue by JohnGrahamCumming · · Score: 5, Informative
    Neither of the linked articles helps understand the issue but this one does,
    Furthermore, RFC-793 allows a TCP implementation to verify both sequence and acknowledgement numbers prior to accepting a RST control flag as valid. No TCP stack implemention tested currently implements checking of both sequence and acknowledgement. All tested TCP stacks currently verify only the sequence number. This allows connections to be reset with dramatically less effort than previously believed.
    Hence this is an implementation issue that can be patched in TCP stacks.

    Move along, little to see here.

    John.

  3. Re:Good by frenetic3 · · Score: 5, Informative

    As frightening as this "vulnerability" sounds, this is nothing really new; other TCP weaknesses are syn floods (not quite the same thing, but somewhat similar -- in fact, this vulnerability might as well be called a "RST flood"), connection hijacking (by sniffing packets and sending spoofed packets with the correct sequence numbers), and so on. It's also an implementation issue that is largely caused by implementations having loose checking of TCP sequence and ack numbers, or accepting too large of a window of sequence numbers.

    I wouldn't say TCP is broken or that some other solution would be much better; it would be tough to design a transport protocol that is still simple (and doesnt use CPU burning hashing/encryption techniques) that wouldn't have these sorts of vulnerabilities (especially since it's so easy to spoof IP packets); calling this vulnerability severe is like screaming that highways are fundamentally unsafe because someone could point their car the wrong way and start smashing into oncoming traffic.

    -fren

    --
    "Where are we going, and why am I in this handbasket?"
  4. Impact moderate for users, serious for providers by forged · · Score: 5, Informative
    The exploit apparently allows an attacker to disconnect TCP sessions, so really home users won't have much to fear except perhaps to get more trouble connecting to their various sites than usual, and that is in case they would be under active attack.

    Service providers on the other hands, must protect their routers because the BGP protocol used to distribute Internet routes between them, massively uses TCP. And when routes go missing, it is hundreds if not thousands of routes to your favourite places that go unreacheable.

    The problem in the case of BGP is made worse by dampening, i.e. keeping the flapping routes out of the routing table for a certain amount of time (up to several hours). BGP routes dampening is not always configured. A determined attacker with this knowlege would be able to knock large portions of the Internet offline for hours.

  5. BGP vulnerable by Anonymous Coward · · Score: 5, Informative

    I happen to work for a large, nationwide backbone. We've known about this for about a week now. BGP, configured without an MD5 key (as is usually the case) is extremely vulnerable to this exploit. This is the reason for the top-secret effort in the past week to MD5 all peering sessions, both internal and external on most major networks worldwide. Without this, it's trivial to exploit, in fact we already have source code provided by the NCISS. Input a few IPs and BGP's TCP port number, and wham you take down a peering session. For those that don't understand what this means, prior to the security changes that have been implemented in the last week, the global internet was largely susceptible to this flaw in such a way that major portions could have been taken offline easily. A priority was put on this within the intra-NOC communications channels that exist that has never been seen before to lock this down before the public knew about it. We were embargoed by DHS to not release the information until tomorrow.

  6. Known issue by httptech · · Score: 5, Informative
    Apparently this has been known about for a while. Here's an excerpt from an IETF draft on BGP vulnerabilities from June 2003. Section 3.2.1.4 specifically mentions the attack described by Watson: From http://mirrors.sunsite.dk/drafts/draft-ietf-idr-bg p-vuln-00.txt

    3.2.1.4. TCP RST/FIN/FIN-ACK

    Event 18: If an attacker were able to spoof a RST, the BGP speaker would
    bring down the connection, release all associated BGP resources, delete
    all associated routes and run its decision process. If an attacker were
    able to spoof a FIN, then data could still be transmitted, but any
    attempt to receive would receive a notification that the connection is
    closing. In most cases, this results in the connection being placed in
    an Idle state, but if the connection is in the OpenSent state at the
    time, the connection returns to an Active state. Spoofing a RST in this
    situation requires an attacker to guess a sequence number that is in the
    proper half of the sending window, generally an easier task than
    guessing the exact sequence number so as to spoof a FIN. The use of [5]
    will counter this attack.
  7. Here is what to do... by GPLDAN · · Score: 5, Informative

    The article is being presented at CanSecWest, and is called "Slipping in the Window" by Paul A. Watson. I have two friends at CanSecWest, I've asked them to attend and report back what the feeling is.

    NANOG members are talking about it, and several regional Tier-1 players have already issued customer notifications.

    This exploit goes up against TCP connections that have been established for long periods of time. i.e. not web connections. The most prevalent would be BGP peer connections, which can be up for days on end easily. Without having read details, or the paper itself, by forging packets of BGP peers with adjusted window sizes, you can cause a router to reset (possibly hang, depending on IOS or JunoOS version, not sure about this) it's BGP peer connection. If you were doing eBGP and had your own AS, a directed attack against your gateway routers could force flapping, which would cause route dampening, and lead to denial of service.

    What you need to do, is contact your ISP if you are an enterprise network admin, and establish MD5 authentication on your BGP sessions. Check with Cisco or Juniper and find out if your code will drop non-MD5 BGP packets directed at it. An ACL won't do, the attacker would forge the src-ip of a known peer.

    This is a completely non-trivial attack to coordinate. You need to know the IP address of the BGP peer of a customer, or the route reflector, and then get the IP address right in an attempt to bypass ACLs and get the BGP session to hang. eBGP multihop means that IP could be any number of routers, and unless you have inside info, you don't know what it is.

    Potentially, looking glasses could be used to mount attacks at NAPs or other peering points, but again, I think the major players will be ready for it very shortly, and will spend most of today (if they are any good) coordinating with legal teams to slam the shit out of any forged sessions they see, and start cooperating to run traces with other providers.

    If I could editorialize one moment, none of this would be an issue if providers took better care to implement anti-spoofing techniques. Forged src-ip addresses are the bane of security. Most of these attacks don't care about 2-way communcations, they just want to reset connections. Spoofed src-ip lets them do that. Rant off.

  8. Re:It's Al Gore's fault... by hambonewilkins · · Score: 5, Informative
    Vinton Cerf: Good evening, or whatever time zone you are in, hi!! While we're waiting for questions, I'd like to clear up one little item - about the Vice President ... He really does deserve some credit for his early recognition of the importance of the Internet and the technology that makes it work. He was certainly among the first if not the first in Congress to realize how powerful the information revolution would be and both as Senator and Vice President he has been enormously helpful in supporting legislation and programs to help further develop the Internet - for example the Next Generation Internet program. I get to see a lot of this stuff because I am a member of the President's Information Technology Advisory Committee and we regularly review the R&D programs of the US Government and many have relevance to the evolving Internet.

    Real quote.

    --

    God Bless America. Why? Did it sneeze?
  9. What details, the info is already out by Anonymous Coward · · Score: 5, Informative

    The NISCC articles explains things clearly. Nobody needs any more information. Besides, this "new" attack was already known. People just didn't realize how easy it is.

  10. Link to US-CERT TA04-111A by Ascaroth · · Score: 5, Informative

    Here's a link to US-CERT's TA04-111A on this topic.

  11. Simple BGP solution has been around since 1998 by jroysdon · · Score: 5, Informative

    As they state, there is a simple solution: TCP MD5 Signature Option with BGP. Any ISP worth their salt will already be doing it. The rest will learn the hard way.

    This has been supported in Cisco IOS way back since ~1998 in IOS 11.2 .

    Read the BGP "Bible": Internet Routing Architectures or look at any best-practices guides which will state that TCP MD5 sigs should always be used with BGP.

    Or search CCO:

    router bgp 109
    neighbor 145.2.2.2 password v61ne0qkel33&

    It's just a single line that has to be added to both peer sides.

  12. NISCC slowing, here is the meat summary of article by JPriest · · Score: 5, Informative

    The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set.

    The packets need to have source and destination IP addresses that match the established connection as well as the same source and destination TCP ports.

    The fact that TCP sessions can be reset by sending suitable RST and SYN packets is a design feature of TCP according to RFC 793, but a reset attack is only possible at all because the source IP address and TCP port can be forged or "spoofed".

    Although denial of service using crafted TCP packets is a well known weakness of TCP, until recently it was believed that a successful denial of service attack was not achievable in practice. The reason for this is that the receiving TCP implementation checks the sequence number of the RST or SYN packet, which is a 32 bit number, giving a probability of 1/232 of guessing the sequence number correctly (assuming a random distribution).

    The discoverer of the practicability of the RST attack was Paul A. Watson, who describes his research in his paper "Slipping In The Window: TCP Reset Attacks", presented at the CanSecWest 2004 conference. He noticed that the probability of guessing an acceptable sequence number is much higher than 1/232 because the receiving TCP implementation will accept any sequence number in a certain range (or "window") of the expected sequence number. The window makes TCP reset attacks practicable.

    Any application protocol which relies on long term TCP connections and for which the source and destination IP addresses and TCP ports are known or can be easily guessed will be vulnerable to at least denial of service attacks

    --
    Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
  13. Neither forgotten nor stupid by shostiru · · Score: 5, Informative
    The relevant parts of this vulnerability are 1) that RST attacks are much, much easier than formerly thought, making them possible for your average broadband sub, and 2) that BGP in particular is highly vulnerable, given the consequences of a terminated BGP session.

    A recently published I-D (here) claims 200 seconds is sufficient time for a broadband sub to successfully attack a TCP session, provided their ISP doesn't use egress filtering (and way too few do so).

    This is rather serious. Whether you personally aren't susceptible is irrelevant if your upstreams are.

  14. Re:This is new?? by Geoff-with-a-G · · Score: 5, Informative

    Maybe I missed something in the advisory, but this sounds like a good old TCP reset attack...

    You did.

    The news here is that you no longer require the sniffer, because you don't have to know the exact sequence number. Now you just have to be kind of close. How close apparently varies in size amongst vendor implementations.


  15. That took long enough by Anonymous Coward · · Score: 5, Informative

    This came up on the linux-kernel mailing list two years ago during a thread on TCP MD5 stuff to avoid this very problem. Why is it just now making a splash?

    This post from Alan Cox covers it nicely. Also see the rest of the thread.