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:
  • 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.
  • Re:Good (Score:2, Interesting)

    by beh (4759) * on Tuesday April 20, 2004 @03:19PM (#8920464)

    Might this be THE final topic to bring IPv6 to a wider attention?

    I'd hope so... ;-)

  • 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
  • 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 advocate_one (662832) on Tuesday April 20, 2004 @03:26PM (#8920578)
    NISCC slashdotted so fast... what would happen in a real emergency??? when everybody really wants to know...
  • Stupid (Score:1, Interesting)

    by afay (301708) on Tuesday April 20, 2004 @03:29PM (#8920607)
    This is really just trying to get someone's name out on the security sites. Currently, in a decent TCP/IP implementation, you have to know the source and destination IP's, the source and destination ports, and the sequence number. Now, some of those are fairly easy to determine, but others like the source port (assuming connecting to a server) and the sequence number are not. (BTW, I do realize that in some crappy implementations the source port is easy to guess, but whatever) You would need to be able to sniff the actual connection. And in all honesty, if you can sniff the connection, there are much easier ways to cause a DOS (for example, bringing down the interface).
  • OUCH! (Score:2, Interesting)

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

    BGB disruption. This is worse than you can even guess. I anticipate this will lead to effective phishing scams, and other things.

    The danger is that by killing off the legiment routes to a host, somebody with a cracked router can then claim to have the legitament route to the host. Which of course, it doesn't. So, quite effective traffic redirection from the internet to a malitious web server.

  • Bait (Score:1, Interesting)

    by chris_mahan (256577) <chris.mahan@gmail.com> on Tuesday April 20, 2004 @03:36PM (#8920717) Homepage
    The big guys already knew about this.

    The script kiddies just found out.

    If you're a script kiddie and you try to exploit, you won't get anywhere, and you'll get arrested.

    If you're a serious hacker, you won't do that.

    If you're a serious cracker, you either already have done it, or you've moved on to another, juicier target, because there's no pride in going in after Yahoo! news stories.

    So this is just a way for the FBI to track down script kiddies.
  • 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 Anonymous Coward on Tuesday April 20, 2004 @03:40PM (#8920771)
    At my corporation, they run a product which listens for P2P software like Kazaa and exploits this vulnerability by sending a spoofed RST to shut down the service. I had to patch my TCP stack to check the ACK # in order to keep my FastTrack client leeching porn.

    Sounds like IETF is zeroing in on these guy's business model. Good. The anti-P2P vendors will probably catch up by spoofing both numbers, but they will have to ensure that their RST beats the actual packet there, which is tricky.
  • 3 way wave-goodbye? (Score:2, Interesting)

    by Cougem (734635) on Tuesday April 20, 2004 @03:43PM (#8920810)
    Hey, the 3 way handshake works for establishment, and it'd solve this problem if we implemented it for disconnections.

    x wishes to close connection, y checks this by sending random bits and a check request, x sends these bits back to ensure that it really is x wishing to close it, and voila.
  • OpenBSD is safe? (Score:3, Interesting)

    by scum-e-bag (211846) on Tuesday April 20, 2004 @03:50PM (#8920894) Homepage Journal
    Perhaps this might be a good time to encourage everyone to move over to IPV6.
  • by BrewerDude (716509) on Tuesday April 20, 2004 @04:01PM (#8921067)
    There is a new Internet draft [ietf.org] addressing this issue.
  • 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:2, Interesting)

    by denis-The-menace (471988) on Tuesday April 20, 2004 @04:11PM (#8921219)
    Let's say we ALL did over night. Given its new-ness you'll have 20 bugs to kill in under 18 months. I prefer the gradual approach.
  • 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 swb (14022) on Tuesday April 20, 2004 @04:32PM (#8921528)
    Not all of IPX, but at least the numbering scheme felt halfway thought out: full addresses were 80 bits long, comprised of 32 bits of network address and 48 bits of node addresss, the latter almost always being the device's MAC address (which is a delicious hack for ARP tables on ethernet networks).

    The 48 bit node address space would make it easy to have large single-subnet LANs without dealing with multiple subnets/NAT/routing, and the network portion of the address space is as large as the entire /24 space for IPv4.

    The rest of IPX was kind of a kludge, but I liked the numbering system.

  • by Mr. Firewall (578517) on Tuesday April 20, 2004 @04:33PM (#8921540) Homepage

    Gore took the initiative in creating the Internet by taking the initiative to support the legislation required to get it going.

    And just how, exactly, did he do that? He wasn't even in Congress at that time. IIRC he was in college, or high school, or something.

    nothing in his statement could be properly construed to imply such

    Look it up. He clearly implied that he was present at the creation of the Internet, and actively made it happen -- which is clearly a falsehood.

    Yes, he apparently DID do some things to help the Internet while in Congress -- for which he deserves credit -- but the Internet already existed; he sure as hell didn't 'invent' it.

    And it has nothing to do with which team (Bush v. Gore) you were rooting for. Everyone SHOULD be able to rationally sort out the facts regardless of ideology. Of course, the Gore people still have trouble being rational, but that's another thread....

  • 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:BGP vulnerable (Score:2, Interesting)

    by Anonymous Coward on Tuesday April 20, 2004 @05:14PM (#8922101)
    Until this week, yes. Of the ~250 peering sessions we have, there were 20 that had MD5 keys on them. This was the generally accepted practice until last week.
  • Re:BGP vulnerable (Score:2, Interesting)

    by NilsK (74600) on Tuesday April 20, 2004 @05:22PM (#8922212) Homepage
    Okay I do not know much about BGP, but the MD5 on the peering session is happening within the BGP, right? How does that make the underlying TCP connection more stable or less vulnerable to this attack? Maybe I am wrong about the design of IP-layers, but changing the upper layer should not fix the lower one ... And attacking the lower one will affect all higher ones. Or does BGP with MD5 checksums no longer require a persistant TCP connection?

    Either I have a stupid day or I do not understand the benefit of putting MD5 into BGP.

    To make an end user example: If I have a very long POP3 session (because somebody zipped the google cache and sent it by mail) I would be vulnerable, because this long lasting session could be attacked. Then I loose the session and have to establish a new one. Building a checksum into POP3 won't change much about that.

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

    by Anonymous Coward on Tuesday April 20, 2004 @05:29PM (#8922299)
    But IPv6 makes encryption (and "signing") possible so you can't spoof those packets. TCP is above IP in the stack ya know?

    Or did _I_ miss something?
  • Am I the only one... (Score:2, Interesting)

    by Ketnar (415489) <Ketnar@NosPam.ketnar.org> on Tuesday April 20, 2004 @05:36PM (#8922390) Homepage
    Out here who took notice that this is more or less the same old hat trick of resetting connections that has been around

    SINCE THE CREATION OF TCP/IP?

    *Duh*
    c'mon, script kiddys have been throwing packets to reset connections for years.

    Same old trick, new aplication. Yes, now we all have the ability to throw a good fingerpoint at a vendor or two and say shame on them, and make some great BSD-is-safe-again! remarks.

    Moving right along...The only people 'vulnerable' to this are people who don't configure routers/firewalls or BGP's properly to use hashing, or no-brainer spoof blocking at the forefront, etc.

    And guess what that means? They should have paid closer attention in class. Darwin works in more places than just the gene pool.

  • Peeve (Score:3, Interesting)

    by j h woodyatt (13108) <jhw@conjury.org> on Tuesday April 20, 2004 @05:50PM (#8922537) Homepage Journal

    From the advisory:
    [...] In the absence of vendor patching of the TCP implementation, the following are general mitigating steps: Implement IP Security (IPSEC) which will encrypt traffic at the network layer, so TCP information will not be visible; [...]

    We told you not to deploy NAT because (among other reasons) it would break IPsec authenticated header (AH) mode. You did it anyway and told us we were pedantic academic pinheads.

    You deserve what you get.


    --
  • zebra? (Score:1, Interesting)

    by Anonymous Coward on Tuesday April 20, 2004 @05:55PM (#8922604)
    unfortunately zebra [zebra.org] doesn't support MD5 on BGP. Now what? 'upgrade' to cisco?

    AC
  • by void* (20133) on Tuesday April 20, 2004 @06:13PM (#8922779)
    In practice, these attacks are quite tricky to perform, because they require good timing and quite a bit of skills

    Well, they require a packet with the right sequence number to hit in the right time period.

    Since there's a window of accepted sequence numbers, it really only requires a shitload of packets with likely numbers. Send enough good guesses and one will hit at the right time.

    Like a race exploit, I don't think this requires 'good timing', I think it requires enough attempts to reduce the odds - many will fail, but one may succeed.
  • Re:IPv6 (Score:3, Interesting)

    by Spudley (171066) on Tuesday April 20, 2004 @06:26PM (#8922906) Homepage Journal
    This is a good point - is this attack still possible in IPv6? If not, could this be the killer event that make the switch seem like a good idea to all the companies that have been refusing to change.

    (if the hack is still possible in IP6, then I can only ask *why*??, since the basic principles of the flaw have been known for a long time)
  • Re:Good (Score:2, Interesting)

    by IKEA-Boy (223916) on Tuesday April 20, 2004 @06:31PM (#8922975) Homepage
    Lets go for starters, BGP packets unless multihop should have a TTL of exactly 1 and come through a point to point interface.

    First of all, it's trivial to deliver a packet to a certain host on the Internet so that the TTL on the packet is exactly 1 (just do a traceroute and send out the packet with a TTL to match the number of hops). Second, I would say that many important BGP sessions are NOT accross point to point links, they are over Gigabit Ethernet at IXP's.

    Basic anti-spoofing on each side will stop any packets that cleam to be from the other end of that interface from comming in any other interface

    Please explain to me how you would do this on a Cisco 12000 with Engine 0 or 1 linecards and still maintain line rate. In fact, please explain to me how this can be done on any Cisco at all. (URPF doesn't protect against this.)

    BGP does support preshared keys as well though I'm not sure if that will stop this attack as it's more to prevent session hijacking. I dont see a 'fix' for this comming out besides normal security settings.

    I'm not sure either. I'm aware of the enormous BGP MD5 authentication setup rage that has been going on over the past week and while I think this is a good effort I'm not entirely sure if it will protect against the RST attack. BGP lies on top of TCP so if you are able to kill the underlying TCP session I don't think MD5 authentication protects against this. Anyone care to enlighten me?

    The best thing I can think of so far is tweaking windows sizes etc. and do ingress filtering on your network where possible.
  • by Oriumpor (446718) on Tuesday April 20, 2004 @11:22PM (#8925192) Homepage Journal
    From my daily reading it looked like the recent mailing regarding the Rose attack [securityfocus.com] Which could affect nearly as many systems as this TCP vulnerability. With two vulnerabilities of this extent, and their relative quiet reception by the security community I don't think there will be much of a push to fix this problem, while the k1dd13s go to work acquiring proof of concepts.
  • Re:OpenBSD is safe? (Score:3, Interesting)

    by Eivind (15695) <eivindorama@gmail.com> on Wednesday April 21, 2004 @02:16AM (#8926127) Homepage
    Sure. But randomized source-port only helps when BSD is the client, makes no difference at all when BSD is the server as is much (as in orders of magnitude) more common. (because most services run on, and must run on, well-published ports)

    So, those 20 people who use bsd as a network *client* are somewhat less likely to have their tcp-connections successfully attacked as those who use predictable source-ports. (still not 48000 times safer as Theo writes, predictable does not typically equate "100% guessable with 1 try")

    This "vulnerability" is kinda lame really. Previously, people who didn't think about it very much, assumed that since to reset a TCP-connection you need to guess the sequence-number, the chance of successfully doing so would be no higher than 1 in 2^32.

    This "vulnerability" only points out that infact tcp-implementations will accept as valid any sequence-number between $CURRENT and $CURRENT+$WINDOW_SIZE.

    So, instead of needing to try 2^32 times, you need "only" to try (2^32)/$WINDOW_SIZE times. Still fairly hard under typical conditions.

    Window-size is however typically proportional to bandwith and inversely proportional to delay, so it'll be easiest to exploit on a tcp-connection that has high bandwith, and high ping-times. For example any connection that goes over satelite. (those of you that knee-jerk and think that high bandwith and high ping can't coexist should go reread first-year networking-curriculum.)

  • Re:This is new?? (Score:3, Interesting)

    by evilviper (135110) on Wednesday April 21, 2004 @04:37AM (#8926629) Journal
    The news here is that you no longer require the sniffer

    You didn't before either. Guessing sequence numbers used to be much easier...

    And BTW, guessing sequence numbers based upon the predicitability of different vendors' TCP stacks is also quite old.

    About the only new thing here is that some moron reporter decided to write a fire and brimstone story about this well-known issue.

    Does everybody remember back when CNET reported that Mozilla was going to become a full office-suite? Yes, that who article was based on one random person posting that (one-line) suggesting to the mailing list. Many reporters really are pure slime.
  • by chrysalis (50680) on Wednesday April 21, 2004 @05:02AM (#8926708) Homepage
    No, everyone is not vulnerable to the recently published vulnerability in the TCP protocol that allows to shut down BGP routers. Because Cisco hardware is, stupid writers yell that the whole internet is vulnerable. Come on, Cisco is not the internet.

    As stated by Theo de Raadt and Henning Brauer, OpenBSD is not vulnerable because (quoting Henning) :

    Even without TCP MD5, bgpd on OpenBSD is not affected, because: - we use random emphereal ports - we do not use insanely hughe window sizes as Cisco does - we require the RST sequence number to be right on the edge of the window

    (quoting Theo) :

    That is right. If you have a Cisco, you can tear down BGP sessions by
    spoofing:

    64K of
    SYN's or RST's sent to #.#.#.#:179 -> #.#.#.#:{1024,+512,+512,...}

    The SYN and RST methods are different, but the end effect is that
    a tiny little burst of packets will cause a flap.

    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.

    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.

    It will have the most impact on vendors who do BGP over poor TCP
    stacks. In particular, Cisco.

    Cisco has not been teaching engineers to block SYN's coming in; they
    have only been teaching them to block SYN-ACK's from going out in
    return. And... well, you'll see.

What hath Bob wrought?

Working...