Forgot your password?
typodupeerror

TCP Vulnerability Published 676

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

TCP Vulnerability Published

Comments Filter:
  • OpenBSD is safe? (Score:5, Informative)

    by Anonymous Coward on Tuesday April 20, 2004 @03:16PM (#8920405)

    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!
    • by Anonymous Coward on Tuesday April 20, 2004 @03:20PM (#8920473)
      What about proactive spelling auditing?
      • by JPriest (547211) on Tuesday April 20, 2004 @03:54PM (#8920951) Homepage
        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
        • by JPriest (547211) on Tuesday April 20, 2004 @04:13PM (#8921248) Homepage
          BTW, I pasted this here mostly as damage control. I know how some people (and yahoo apparently) like to fly off the handle and claim the world is ending without bothering to even RTFA. You wonder why some people are Afraid to use a computer. If I wrote for the auto industry and intentionally tried to scare the shit out of people Detroit would sue me off the map.

          There is a new vulnerability that will cause every GM vehicle and cause your children to cry. Vandals can place 1 domestic house cat into the fan and cause the fan to stop and under some cases, cause the vehicle to overheat. This was previously written off as house cats are usually soft ans squishy and have little effect on the powerful fan but Joe Shmoe PHD realised that many house cats have colars that are pretty tough for the fan to digest. Car experts say this is a serious problem and will be dealt with in a serious manner. Suggested work around is to keep your cat tied in the house, and to drive a bicycle instead.

        • by HTH NE1 (675604) on Tuesday April 20, 2004 @04:20PM (#8921369)
          Note: that's 1/2^32 (substitute your own favorite exponential syntax), not one in two hundred thirty-two.
        • by janoc (699997) on Tuesday April 20, 2004 @04:58PM (#8921884)

          Actually, this is just a variation on an old attack with sequence number guessing. Some OSes have a very poor generator for these numbers (even though the vulnerability is known for ages) and it is possible to exploit it. Probably the most famous attack of this sort was Mitnick's break-in into Shimomura's machine ten years ago.

          In practice, these attacks are quite tricky to perform, because they require good timing and quite a bit of skills, so they are quite rare. It is far easier to just exploit some common buffer overflow than this.

          The impact could be not only DOS (by resetting the connection), but you can do also packet injection with potential for total system compromise. However, if the protocol used is encrypted (in Shimomura's case it wasn't, if I am not mistaken, Mitnick attacked rsh or rlogin), then the DOS is probably the worst thing that could happen to you. The encryption will reject the bogus packets, if properly implemented.

          So, keep calm - this was here since at least 80-ties and there isn't much that you can do against it, except to use encryption. You can only hope, that your system vendor will decide to make their TCP stack less vulnerable (not likely to happen, since many systems still ship with the crappy sequence number generator!). Full fix is not possible anyway, unless you want to break the protocol.

          Regards, Jan
    • by shatfield (199969) * on Tuesday April 20, 2004 @03:20PM (#8920481)
      Great, I guess Microsoft will just have to copy the BSD TCP/IP code again to ensure that their customers are safe ;-)
      • Re:OpenBSD is safe? (Score:5, Informative)

        by Jeremiah Cornelius (137) on Tuesday April 20, 2004 @03:32PM (#8920652) Homepage Journal
        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"!

        • Re:OpenBSD is safe? (Score:4, Interesting)

          by Jeremiah Cornelius (137) on Tuesday April 20, 2004 @04:04PM (#8921110) Homepage Journal
          Some genius modded my post as a Troll. I guess it's because they know so much about this vulnerability, and how the exposure goes up as one increases TCP window-size. ;-)

          Really, though. If you need to calculate a valid offset from the ISN, big TCP-window sizes are of advantage to the attacker.

          To quote from the announcement:

          In a TCP session, the endpoints can negotiate a TCP Window size. When this is taken into account, instead of attempting to send a spoofed packet with all potential sequence numbers, the attacker would only need to calculate an valid sequence number that falls within the next expected ISN plus or minus half the window size. Therefore, the larger the TCP Window size, the the larger the range of sequence numbers that will be accepted in the TCP stream.

          BGP-4 relies on persistent connections, with huge window sizes.

          • Re:OpenBSD is safe? (Score:5, Interesting)

            by JPriest (547211) on Tuesday April 20, 2004 @04:34PM (#8921560) Homepage
            As a side note, all the major sites with several BGP peering points have recently started using MD5 authentication. We have been updating all of our peering sessions over the last week or so.
          • Re:OpenBSD is safe? (Score:4, Informative)

            by netwiz (33291) on Tuesday April 20, 2004 @05:07PM (#8921977) Homepage
            Or it might be that you just read the article, and more or less parroted what a more experienced individual said. Especialy given that anyone who deals w/ BGP on a regular basis knows (or better know) how to secure peering links against this kind of vulnerability.

            It's actually quite trivial to do. ebgp-multihop and using the remote host loopback address as the neighbor IP, along with a few small architectural configuration tricks are all that's needed to completely prevent this kind of attack, or, at the very least, minimize it significantly.

            Are _you_ going to scan, not only the entire range of source ports, but all those ports times the entire RFC1918 address space? Good luck killing my systems, buddy, 'cause that's what you're in for.

            Oh, even with the large window sizes, once you've found all the above, you've still got to find my sequence numbers.
        • RFC 2385 (Score:5, Informative)

          by apankrat (314147) on Tuesday April 20, 2004 @05:39PM (#8922421) Homepage
          There is RFC 2385 [ietf.org] titled Protection of BGP Sessions via the TCP MD5 Signature Option. In the first paragraph of its Introduction section it says -

          The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets.

          The date of publishing - August 1998, which makes it about 6 years old.

          However the proposed option was primarily meant as a quick BGP fixup, which should've got depricated as soon as IPsec got RFC'ed and deployed. It did went standard few months later, but IPsec implementations enjoyed full share of cross-vendor compatibility problems.

          With time Authenticated Header (AH) IPsec protocol didn't see much use or acceptance and IPsec slowly evolved (and keeps evolving) into confidentiality rather than authentication layer.

          Besides it's an IP security after all, while the RST spoofing is a TCP problem. And one can quite rightfully percieve authenticating TCP with IPsec as an overkill.

          Anyhow, long story short - it's a known and rather old problem with handful of existing and equally unattractive solutions. Perhaps this time around it will be addressed better due to the amount of the publicity it's aimed to get.

    • by GoofyBoy (44399) on Tuesday April 20, 2004 @03:23PM (#8920527) Journal
      >For what
      they discuss, OpenBSD handles this extremely well. We'll explain more in a week or so.

      Is the margin of the page too small to explain the wonderful reason why it handles this so well?
      • by AndyBusch (160585) on Tuesday April 20, 2004 @03:27PM (#8920588)
        Good and funny :) but I think what they mean is that more details would give more info for exploits, so their sitting mum til things can get solidified a little more.
      • Re:OpenBSD is safe? (Score:5, Informative)

        by lcde (575627) on Tuesday April 20, 2004 @05:36PM (#8922388) Homepage
        Theo Wrote:
        Let me be more clear.

        This entire thing is being "sold" as `cross-vendor problem'. Sure.
        Some vendors have a few small issues to solve in this area. Minor
        issues. For us, those issues are 1/50000 smaller than they are for
        other vendors. Post-3.5, we have fixes which make the problem even
        smaller.

        But one vendor -- Cisco -- has an *UTTERLY GIGANTIC HUGE* issue in
        this regard, and as you can see, they have not yet made an
        announcement see..

        You are being told "lots of people have a problem". By not seperating
        out the various problems combined in their notice, or the impact of
        those problems, you are not being told the whole truth.


        More Theo:
        OpenBSD (and I am sure other systems too) have for some time contained
        partial countermeasures against these things.

        OpenBSD has one other thing. The target port numbers have been random
        for quite some time. Instead of the Unix/Windows way of
        1024,1025,1026,... adding 1 to the port number each time a new local
        socket is established... we have been doing random for quite some
        time. That means a random selection between 1024 and 49151. This
        makes both these attacks 48,000 times harder; unless you already know
        the remote port number in question, you must now send 48,000 more
        packets to effect a change.

        At least one other free operating system incorporated our random port
        selection code today..

        We've made a few post-3.5 changes of our own, since we are
        uncomfortable with the ACK-storm potention of the solutions being
        proposed by the UK and Cisco people; in-the window SYN or RST's cause
        ACK replies which are rate limited.

        At least one other free operating system today incorporated the same
        changes......


    • by thedillybar (677116) on Tuesday April 20, 2004 @03:24PM (#8920535)
      It sounds (again) like proactive security auditting saves the day!

      It doesn't save anything. When someone exploits this and takes out 90% of the Internet's routers, you're screwed no matter what.

      It definitely makes a good argument for both OpenBSD and proactive security auditting. But it doesn't save the day.

    • by MrHanky (141717) on Tuesday April 20, 2004 @03:36PM (#8920729) Homepage Journal
      In a press release from Microsoft, Bill Gates states:
      All Windows versions from 3.11 to 2003 are quite safe from this exploit, since Windows also supports the famously reliable NetBEUI protocol. In a proactive measure, Windows update will remove support for TCP/IP and ensure that all updated computers have support for NetBEUI only. NetBEUI will once again rule the earth! Take that, Steve! No, not you, Ballmer, the other Steve. The hippe. Woahahahahahaha!

      In a quickly following press release, Bill Gates adds:
      Woahahahahahaha! Hahahaha! Hahaha! Thank you.
      • by MrHanky (141717) on Tuesday April 20, 2004 @03:52PM (#8920917) Homepage Journal
        Ah, come on! I was joking, not trolling for flames. And besides, how the hell was that going to attract flames? If that really was flamebait, it should be modded -1, ineffective.

        (Was it the hippie part? Yeah, sure calling Steve Jobs a hippie is flamebait, but this was also clearly a joke. Some moderators are just in a dire need of a blow job.)
      • by markan18 (718118) <sm@bigserver.hopto.org> on Tuesday April 20, 2004 @04:23PM (#8921406)
        Security Update for Windows XP (KBTCPDRM-666)

        This update addresses the vulnerability addressed in Microsoft Security Bulletin 666. Find out about more recent critical updates in the Overview section.

        File Name:

        WindowsXP-MSTCPDRM-x86-ENU.exe

        Download Size:

        1261 GB

        Date Published:

        4/20/2004

        Version:

        666

        Overview

        This patch fixes criticals security vulnerabilities present in Windows TCP stack.
        This patch also add the new DRM TCP extension.
        When is patch is applied, your computer will connect to drm.microsoft.com prior establishing any other connection to make sure the requested end point is an authorized Microsoft partner. All rogue packets are now rejected and reported by the Windows TCP-DRM firewall (TM).
        This patch also upload the registry key HKEY_LOCAL_MACHINE and all subkeys and values to drm.microsoft.com so we can make sure all software is used according to their end user licence agreements.

        System Requirements

        Supported Operating Systems: Windows XP

        Windows XP Professional
        Windows XP Home Edition
    • by Anonymous Coward on Tuesday April 20, 2004 @03:39PM (#8920758)
      From: Theo de Raadt <deraadt@cvs.openbsd.org>
      [snip]

      Let me be more clear.

      This entire thing is being "sold" as `cross-vendor problem'. Sure.
      Some vendors have a few small issues to solve in this area. Minor
      issues. For us, those issues are 1/50000 smaller than they are for
      other vendors. Post-3.5, we have fixes which make the problem even
      smaller.

      But one vendor -- Cisco -- has an *UTTERLY GIGANTIC HUGE* issue in
      this regard, and as you can see, they have not yet made an
      announcement see..

      You are being told "lots of people have a problem". By not seperating
      out the various problems combined in their notice, or the impact of
      those problems, you are not being told the whole truth.
    • by pyros (61399) on Tuesday April 20, 2004 @03:45PM (#8920827) Journal
      I guess they were smart enough to implement the new Evil Bit added to TCP last April. Those OpenBSD folks sure are forward thinking.
  • by Anonymous Coward on Tuesday April 20, 2004 @03:17PM (#8920409)
    Just unplug your PC from the internet and wash your hands of it.. the whole thing feels holier than swiss cheese :(
  • by Novanix (656269) * on Tuesday April 20, 2004 @03:17PM (#8920412) Homepage
    This kind man responsible for finding this vulnerability is going to present this exploit at the security conference in Vancouver this Thursday. He then predicts "hackers will understand how to begin launching attacks 'within five minutes of walking out of that meeting.'" The article talks about how the government has been "fortifying" its networks against this, does that means they quickly rewrote the tcp protocol? I would love to know.
    • by somethinghollow (530478) on Tuesday April 20, 2004 @03:23PM (#8920531) Homepage Journal
      Maybe the speed at which TCP was written is the problem. If they re-wrote it, I hope they did a slow re-write, because we will need the patches.

      Really, I think the problem is that the flaw affected /some routers/ whose implementation of the TCP stack was flawed. That is what I gathered, anyway. If this is so, they just need to find non-flawed software.
      • by CyberBill (526285) on Tuesday April 20, 2004 @03:33PM (#8920669)
        No, its not a problem that is software-specific. They are utilizing a 'flaw' in the design of TCP by spoofing the sender's IP address and port, *AND* guessing the recvwindow number!!

        The reason it only affects long-term connections is because it takes awhile to probe for the magic number to reset the connection, and ALL this does is reset the connection, nothing more.

        This whole thing is retarded, if you know enough about TCP this exploit was already on your mind and forgotten because its stupid. :P

        -Bill
        • by shostiru (708862) on Tuesday April 20, 2004 @04:03PM (#8921107)
          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 [ietf.org]) 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.

          • by Floody (153869) on Tuesday April 20, 2004 @04:15PM (#8921292)
            Of course, in a sanely designed backbone, ingress filtering should be in place to filter source ips from BGP peers that aren't specifically on the interface matching the peer (yes, there's multi-hop BGP, but ignoring that for the moment...).

            I do realize this likely isn't the case on many networks, but perhaps this will push such sanity (and very simple) filtering to become more widespread.

          • by Tackhead (54550) on Tuesday April 20, 2004 @04:21PM (#8921391)
            > 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).

            Maybe it's about fucking time ISPs started using egress filtering. At the very least, there'd be an order of magnitude less crap (smurfage, etc) if ISPs dropped spoofed source IP packets before they got to the backbone.

            OK, so the ability of any skript kiddie to spoof and insert a BGP update is a pretty fucking huge mess. But "pretty fucking huge" it may be the only kind of mess that motivates the clueless fucktards pretending to be "ISPs" these days.

      • by deman1985 (684265) <dedwards.kappastone@com> on Tuesday April 20, 2004 @03:38PM (#8920754) Homepage
        From what I gathered in the two links and also my knowledge of TCP/IP, it would not necessarily require a flawed implementation of the stack in order to be vulnerable to attacks of these sort. In fact, it is the routers and/or software which doesn't implement the stack according to spec which are less likely to be affected.

        In the mean time, there are a few workarounds which can be put in place, such as IPSec, and options which can be changed to reduce the liklihood of an attack, such as the window size. The smaller it is, the harder it is to guess a sequence number in the range quickly.
    • by Jaywalk (94910) on Tuesday April 20, 2004 @03:35PM (#8920714) Homepage
      The article talks about how the government has been "fortifying" its networks against this, does that means they quickly rewrote the tcp protocol?
      Nothing so drastic. Go back to the article and reread it, especially the "Mitigation" section. You will find:
      • It mainly affects the Border Gateway Protocol (BGP) that occurs at a high level in the net. Few computers are involved.
      • The issue was first publicized about a month ago at CanSecWest [cansecwest.com], so those in the know have had a month to work on this.
      • The steps to mitigate the problem are a matter of tweaking settings (like window size) or setting up protocols (like encryption). This is not a matter of rewriting the entire protocol.
      The article is interesting in that it shows how the bits and pieces of the Internet fit together, but I won't be losing any sleep over this one.
  • Good (Score:5, Funny)

    by rokzy (687636) on Tuesday April 20, 2004 @03:17PM (#8920425)
    let's all just start again

    TCP2
    SMTP2
    POP32 ...
    • Re:Good (Score:5, Informative)

      by frenetic3 (166950) * <houston@nOspaM.alum.mit.edu> on Tuesday April 20, 2004 @03:26PM (#8920566) Homepage Journal
      As frightening as this "vulnerability" sounds, this is nothing really new; other TCP weaknesses are syn floods [cs.hut.fi] (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
      • Re:Good (Score:5, Insightful)

        by TwistedSpring (594284) * on Tuesday April 20, 2004 @05:06PM (#8921971) Homepage
        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"),
        1. We know what the other TCP vulerabilities were. Anyone who's still susceptible to them is a lunatic.
        2. This is not at all the same thing and in no way similar other than the fact "it uses TCP".
        3. This vulnerability should not be called an RST flood. That would confuse it with a SYN flood which works totally differently and is much simpler. This should be called a broken window attack or something.

        I wouldn't say TCP is broken
        After noting all the other kinds of irrelevant TCP attack and reading up on this rather serious one, you wouldn't say it was broken? Could it be that, like everyone else including me, you never realised it was broken because you never looked close enough?
        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
        It's called IPSEC, it's secure on the IP level up so TCP is encrypted over it. The simpler way to increase security would be to maintain current window size but increase the sequence number field to 64 bits wide. This would make it nigh-impossible to find where the window is sitting.
        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
        Highways are fundamentally unsafe. They're full of retarded people shunting 3 ton hunks of metal around at speeds they're not comfortable with. But your point is void because people would not do that as they'd die as a result and kill a lot of people. I don't think a kid doing a TCP RST attack really needs to be that dedicated, and this could cost businesses millions of dollars if they don't wise up to it sharpish. Most people who'd took even a short course in networking would be wise to it already.

        The best defence against this? Simply check for a stream of RST packets. They dont come in huge bundles with incrementing sequence numbers often. Detect that signature, block IP, sorted.
  • OSVDB (Score:5, Informative)

    by plcurechax (247883) on Tuesday April 20, 2004 @03:17PM (#8920426) Homepage
    http://www.osvdb.org/displayvuln.php?osvdb_id=4030 [osvdb.org]

    TCP Reset Spoofing

    OSVDB ID: 4030
    Rating: TBD
    Disclosure Date: Apr 20, 2004

    Description:

    The TCP stack implementation of numerous vendors contains a flaw that may allow a remote denial of service. The issue is triggered when spoofed TCP Reset packets are received by the targeted TCP stack, and will result in loss of availability for the the attacked TCP services. ...
    • Re:OSVDB (Score:5, Insightful)

      by -tji (139690) on Tuesday April 20, 2004 @03:33PM (#8920671) Journal
      So, it's simply another type of denial of service. A TCP Reset packet can be faked, which will result in a legitimate open TCP connection being closed by a third party.

      It also assumes a few of things.. You would need to be in the network route, or have some other means of establishing the sequence numbers for the connection. You would also need to be in a network that does not filter out improper source addresses (which some networks do.. but more should do) to allow your spoofed packet to get through.

      So, the problem boils down to a low bandwidth method to DoS TCP connections. It does not give a method to hijack the connections, or otherwise gain access to data.

      Anyway.. Clear IP connections are very open, and completely based on trust. Any sensitive communication should be tunneled inside a VPN, where it would not be vulnerable to this type of attack. (A real IPSec tunnel would not be vulnerable - as it does not use TCP. "SSL VPNs" use TCP as a transport, so they might be open to DoS.. Stick with the security of IPSec for best results.
  • That's it! (Score:5, Funny)

    by Anonymous Coward on Tuesday April 20, 2004 @03:18PM (#8920431)
    I'm removing support for TCP right now. Give me UDP or give me death!
  • oops? (Score:5, Funny)

    by Tebriel (192168) on Tuesday April 20, 2004 @03:18PM (#8920436)
    Looks like someone left ISEXPLOITABLEFLAG = TRUE in the code.
  • No problem (Score:5, Funny)

    by niom (638987) on Tuesday April 20, 2004 @03:18PM (#8920438)
    I'll just switch to UDP.
  • Implementation issue (Score:5, Informative)

    by JohnGrahamCumming (684871) * <slashdot@nosPam.jgc.org> on Tuesday April 20, 2004 @03:19PM (#8920444) Homepage Journal
    Neither of the linked articles helps understand the issue but this one does [osvdb.org],
    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.

  • Work (Score:5, Funny)

    by somethinghollow (530478) on Tuesday April 20, 2004 @03:20PM (#8920470) Homepage Journal
    As a web designer, taking advantage of this could get me off work faster than a snow storm. I don't know if I'm afraid or enthused. ;)
  • by MrRuslan (767128) on Tuesday April 20, 2004 @03:20PM (#8920480)
    to switch over to IPX
  • by hatrisc (555862) on Tuesday April 20, 2004 @03:23PM (#8920529) Homepage
    you can exploit slow start too. was published last year for some conference. The paper is called "The Shrew vs. the Mice and the Elephants" and is by Aleksandar Kuzmanovic and Edward W. Knightly
  • Warning! (Score:5, Funny)

    by Disconnect (5083) on Tuesday April 20, 2004 @03:23PM (#8920532) Homepage
    Your computer is broadcasting an IP address!

    Seriously though, it doesn't look all that bad. (Nor does it look all that hard to do, but still..)
  • by forged (206127) <soltesz&gmail,com> on Tuesday April 20, 2004 @03:27PM (#8920589) Homepage Journal
    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 [cisco.com], 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.

  • BGP vulnerable (Score:5, Informative)

    by Anonymous Coward on Tuesday April 20, 2004 @03:27PM (#8920592)
    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.
  • by plcurechax (247883) on Tuesday April 20, 2004 @03:28PM (#8920596) Homepage
    Funny, but it seems that empherial source ports for a TCP connection may be more secure in this case, since it increases the space that the attacker has to guess within.

    Of course it is a pure "D'oh" that large TCP windows increase exposure to the older known weakness of TCP RST attacks (Steve Bellovin, wrote a paper [att.com] on it in 1989).
  • Known issue (Score:5, Informative)

    by httptech (5553) on Tuesday April 20, 2004 @03:28PM (#8920604) Homepage
    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 [sunsite.dk]

    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.
    • Exactly. (Score:5, Insightful)

      by FreeLinux (555387) on Tuesday April 20, 2004 @03:55PM (#8920955)
      It is indeed a problem with TCP but, it is in no way new. Many people have relied on this "vulnerabillity" for years. This is the technique that many firewalls implement in order to terminate undesirable sessions.

      This vulnerabillity impacts the applications that are unable to handle session interruptions. BGP is such an appilication but, its impact on BGP is critical because this attack could seriously impeed BGP and since the internet backbone relies on BGP such an attack could covceivably shut down the internet. This is a known vulnerabillity in BGP, as you said, and it is surprising to me that BGP has not been modified to prevent this from happening.

      By and large most applications will be able to deal with this and only minor annoyances such as DoS will occur.

      As for earlier posts about OpenBSD being immune, I am very eager to hear how that is possible. No matter what the implementation, it is still possible to reset TCP sessions. This means that OpenBSD is still potentially vulnerable to DoS attacks.

      Provided that BGP is modified to make it more fault tolerant, I can't see this problem with TCP being anything more than a short-lived niusance. I'm sure however that many people will try to use this as leverage to force IPv6 migration however, I believe that it too is vulnerable.
  • by dark-br (473115) on Tuesday April 20, 2004 @03:31PM (#8920632) Homepage
    i'm posting this over NetBEUI Protocol ;)

    *sight*

  • RFC3360 (Score:5, Informative)

    by RAMMS+EIN (578166) on Tuesday April 20, 2004 @03:31PM (#8920634) Homepage Journal
    For more information about what TCP resets are and why they can be harmful, see RFC3360 [faqs.org].
  • by GPLDAN (732269) on Tuesday April 20, 2004 @03:32PM (#8920648)
    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.
  • by Craptastic Weasel (770572) on Tuesday April 20, 2004 @03:38PM (#8920747)
    I am a lonely man living on the Galapagos Island. I use TCP/IP over carrier pigeon to communicate with a Nigerian who has promised my great wealth in exchange for securing funds in the First Galapagos Bank, of which I am owner/ceo/clerk, and janitor.

    I suspect someone is interupting my data stream and keeping the replies and account numbers he has been sending me in regards to my money. This vulnerability proves my theory. I am in desperate need!! How can I prevent this!!

    Anyone willing to help I will share my wealth with.

    /obscure humor (Does this make me a Galapagos Spammer?)
  • by Ascaroth (629227) on Tuesday April 20, 2004 @03:41PM (#8920794)
    Here's a link to US-CERT's TA04-111A [us-cert.gov] on this topic.
  • by JDizzy (85499) on Tuesday April 20, 2004 @03:58PM (#8921008) Homepage Journal
    I read the paper, which is nothing more than a rehash of what every security person already knows about: tcp sequence guessing.

    This issue erupted on the freebsd irc chat, and I had to kill it by posting this linkage: http://lcamtuf.coredump.cx/newtcp/ [coredump.cx]

    As you can see TCP sequncing is fairly random in most of the IP/TCP stacks out there in commercial use. The reasearch paper mentioned in the article only applies to the OS's in the above link that dont' have near true 32bit randomness.

    The feasability of overcoming realtime 32 sequence guessing is insane, however non-zero. just my .02c
  • by BrewerDude (716509) on Tuesday April 20, 2004 @04:01PM (#8921067)
    There is a new Internet draft [ietf.org] addressing this issue.
  • The real problem? (Score:5, Insightful)

    by getnuked (595037) on Tuesday April 20, 2004 @04:04PM (#8921123)
    The real problem is not in TCP (although sequence number windows are a bad idea), it's in allowing in spoofed IP datagrams. If network admins locked down their routers correctly then script kiddies wouldn't be able to send forget packets, and this wouldn't be an issue.

    Note to netadmins and sysadmins: block packets with source IPs that are not valid for the interface they came from! Geesh!

  • by weld (4477) on Tuesday April 20, 2004 @04:11PM (#8921223)
    Mudge from the L0pht talked about taking down the internet in 30 minutes with a router DoS attack in front of the US Senate in May 1998. Privately the L0pht told NIPC that this could be done with a BGP TCP reset attack. L0pht said it could be mitigated by doing ingress/egress filtering but that ISPs were to lazy and cheap to do it.


    In Aug 1998, RFC 2385 came out with protection of BGP with MD5 signatures. Using MD5 sigs will defeat this attack.


    This is a well known issue with well known solutions. If the infrastructure is at risk it is because ISPs haven't been doing their job and following best practices.


    -weld

  • by Anonymous Coward on Tuesday April 20, 2004 @04:25PM (#8921435)
    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 [google.com] from Alan Cox covers it nicely. Also see the rest of the thread.
  • by PureFiction (10256) on Tuesday April 20, 2004 @04:38PM (#8921638)
    Guessing a port and IP is fairly easy. Guessing the sequence number is not. This is why making sure that TCP initial sequence numbers are random [bindview.com] is important.

    This is old news.

    For the insanely paranoid use a hardware entropy generator (TRNG) [peertech.org] for choosing ISN's.

    There are all sorts of attacks against network protocols when poor random number sources are used. This is but one example...
  • by jakedata (585566) on Tuesday April 20, 2004 @04:45PM (#8921722)
    Title: Juniper NetScreen Advisory 58784
    Date: 21 April 2004
    Version: 1

    Impact:
    A design flaw in the RFC specification of TCP may allow a blind attacker to successfully close a TCP connection.

    Affected Products:
    Juniper NetScreen Firewalls (all versions)

    NISCC Reference: Vul/236929
    http://www.uniras.gov.uk/vuls/2004/236929/tcp.htm

    Max Risk: Medium

    Summary:
    A blind attacker with limited knowledge of a TCP connection may be able to successfully brute force the TCP Sequence number space and thereby cause a connection endpoint or firewall stateful filter to process a spoofed RST packet and close the connection.

    Details:
    The TCP Sequence number is one of the mechanisms that TCP uses to prevent a third party from inserting forged packets into the data-stream between two other hosts. While such an attack has always been known to be theoretically possible against TCP, it is was believed that the range of over four billion possible TCP Sequence numbers was large enough to prevent a successful attack. However, recently such an attack has been proven to be feasible in certain situations.

    Specifically, if two hosts are known to talk to each other on a regular basis and/or for long periods of time over known port(s) then it may be possible for an attacker to brute force the TCP Sequence number space and successfully inject a forged packet into the connection and possibly disrupt communications. Certain connections, such as BGP4, which are long lived between two devices are especially vulnerable.

    While all TCP connections are potentially vulnerable, NetScreen believes that NetScreen firewalls running BGP4 or with TCP Syn-Check enabled are likely to be vulnerable in practice. Other protocols such as SSH, HTTP and SMTP which usually have shorter connection times are less vulnerable.

    Recommended Actions:
    NetScreen firewall customers should do one or more of the following:
    1) Configure Anti-Spoof protection as appropriate.
    2) Use secure protocols such as ssh, HTTPS, BGP4 w/ MD5 Authentication
    and IPSec which are more resistant to attack.
    3) Limit management to dedicated and/or internal interfaces
    4) Upgrade to ScreenOS 5.0r6 which enhances the stateful firewall
    functionality to protect devices on the network.

    Patch Availability:
    ScreenOS version 5.0r6 is currently available for Juniper NetScreen firewalls.

    How to get ScreenOS:

    Customers with a valid product warranty or a support contract may download the software from the Juniper NetScreen CSO web portal:
    http://www.juniper.net/support/

    For all other customers, including those with expired support contracts, please call your regional Juniper NetScreen TAC center at one of the numbers listed in:
    http://www.juniper.net/support/nscn_support/t ao/co ntact.html

    Select option 2 from the telephone menu and be sure to select the correct product from the phone tree. Once connected with an engineer state that you are calling in regards to a Security Advisory and provide the title of this notice as evidence of your entitlement to the specified release.

    As with any new software installation, NetScreen customers planning to upgrade to any version of ScreenOS should carefully read the release notes and other relevant documentation before beginning any upgrade.
  • by spurious cowherd (104353) on Tuesday April 20, 2004 @07:08PM (#8923298)
    Here [cisco.com]

186,000 Miles per Second. It's not just a good idea. IT'S THE LAW.

Working...