Become a fan of Slashdot on Facebook

 



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 @02: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!
  • OSVDB (Score:5, Informative)

    by plcurechax (247883) on Tuesday April 20, 2004 @02: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. ...
  • Implementation issue (Score:5, Informative)

    by JohnGrahamCumming (684871) * <slashdot@jgc.PERIODorg minus punct> on Tuesday April 20, 2004 @02: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.

  • More FUD? (Score:2, Informative)

    by darthcamaro (735685) * on Tuesday April 20, 2004 @02:21PM (#8920499)
    O.k so how will this affect anyone other than major ISP's that can really do anything about it? Seeing at it affects BGP

    The Border Gateway Protocol (BGP) is judged to be potentially most affected by this vulnerability.

    Run IPSEC the advisory says..o.k so what else is new? IPv4 is inhernetly insecure, we all know that - that's why there is such a thing as packet sniffing, DoS attacks and all the other crap that net admins gotta deal with each and every day.
  • by Zondar (32904) on Tuesday April 20, 2004 @02:23PM (#8920518)
    Yep, that's the issue. I submitted too, but :(.

    Anyway, the way I read it you basically run the TCP attack against a BGP peering router, causing it to drop one or more of it's peering relationships. Do that enough and you can cause the routes being advertised by that router (and also TO that router from the peering connections you're breaking) to be 'dampened' - a protective mechanism in BGP to prevent a flapping route from making all the peers recalculate their routes nonstop.

    It's kind of like one peer putting the other one's routes in "time-out" until he plays nice.
  • NYTIMES ARTICLE (Score:1, Informative)

    by Anonymous Coward on Tuesday April 20, 2004 @02:25PM (#8920560)
    A little more info...actually has a link to www.terrorist.net (im sure the feds love that...)

    The flaw affecting the Internet's "tranmission control protocol," or TCP, was discovered late last year by a computer researcher in Milwaukee, Paul ``Tony'' Watson, 36, who said he identified a method to reliably trick personal computers and routers into shutting down electronic conversations by resetting the machines remotely

    respect to the hometown hero in finding this...

    http://nytimes.com/aponline/technology/AP-Intern et -Threat.html
  • Re:Good (Score:5, Informative)

    by frenetic3 (166950) * <houston@a[ ].mit.edu ['lum' in gap]> on Tuesday April 20, 2004 @02: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
  • by forged (206127) on Tuesday April 20, 2004 @02: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 @02: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 @02: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 @02: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.
  • RFC3360 (Score:5, Informative)

    by RAMMS+EIN (578166) on Tuesday April 20, 2004 @02:31PM (#8920634) Homepage Journal
    For more information about what TCP resets are and why they can be harmful, see RFC3360 [faqs.org].
  • by sgifford (9982) <sgifford@suspectclass.com> on Tuesday April 20, 2004 @02:31PM (#8920636) Homepage Journal
    While you may not use BGP directly, your ISP almost certainly does, and probably their ISP too. It's also used in the Internet core for communication between ISPs. The reason a problem with BGP is a big deal is that it can drastically affect entire ISPs, essentially knocking them offline until their routers are upgraded.
  • by GPLDAN (732269) on Tuesday April 20, 2004 @02: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.
  • Re:Good (Score:2, Informative)

    by Anonymous Coward on Tuesday April 20, 2004 @02:32PM (#8920649)
    No. IPSEC is mandatory in IPv6: IPSEC is one of the three mitigations listed.
  • Re:OpenBSD is safe? (Score:5, Informative)

    by Jeremiah Cornelius (137) on Tuesday April 20, 2004 @02: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:Good (Score:1, Informative)

    by Anonymous Coward on Tuesday April 20, 2004 @02:32PM (#8920659)
    You're correct. The layers of the Internet were designed to be completely independent. That's why you get crazy (but still totally possible) protocols like IP over avian carrier.

    This is the authoritative answer to your question.
  • Slashdotted (Score:2, Informative)

    by MrRuslan (767128) on Tuesday April 20, 2004 @02:32PM (#8920663)
    What is Affected? The vulnerability described in this advisory affects implementations of the Transmission Control Protocol (TCP) that comply with the Internet Engineering Task Force's (IETF's) Requests For Comments (RFCs) for TCP, including RFC 793, the original specification, and RFC 1323, TCP Extensions for High Performance. TCP is a core network protocol used in the majority of networked computer systems today. Many vendors include support for this protocol in their products and may be impacted to varying degrees. Furthermore any network service or application that relies on a TCP connection will also be impacted, the severity depending primarily on the duration of the TCP session. Severity The impact of this vulnerability varies by vendor and application, but in some deployment scenarios it is rated critical. Please see the vendor section below for further information. Alternatively contact your vendor for product specific information. If exploited, the vulnerability could allow an attacker to create a Denial of Service condition against existing TCP connections, resulting in premature session termination. The resulting session termination will affect the application layer, the nature and severity of the effects being dependent on the application layer protocol. The primary dependency is on the duration of the TCP connection, with a further dependency on knowledge of the network (IP) addresses of the end points of the TCP connection. The Border Gateway Protocol (BGP) is judged to be potentially most affected by this vulnerability. BGP relies on a persistent TCP session between BGP peers. Resetting the connection can result in medium term unavailability due to the need to rebuild routing tables and route flapping. Route flapping may result in route dampening (suppression) if the route flaps occur frequently within a short time interval. The overall impact on BGP is likely to be moderate based on the likelihood of successful attack. If the TCP MD5 Signature Option and anti-spoofing measures are used then the impact will be low as these measures will successfully mitigate the vulnerability. There is a potential impact on other application protocols such as DNS (Domain Name System) and SSL (Secure Sockets Layer) in the case of zone transfers and ecommerce transactions respectively, but the duration of the sessions is relatively short and the sessions can be restarted without medium term unavailability problems. In the case of SSL it may be difficult to guess the source IP address. Data injection may be possible. However, this has not been demonstrated and appears to be problematic. Summary 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
  • by Jaywalk (94910) on Tuesday April 20, 2004 @02: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.
  • BGP is a big deal... (Score:3, Informative)

    by sterno (16320) on Tuesday April 20, 2004 @02:36PM (#8920721) Homepage
    Ummm... major ISP's. Tell me one person who's not connected to a major ISP in some fasion. If it only effects BGP, it effects all of us.
  • by hambonewilkins (739531) on Tuesday April 20, 2004 @02:36PM (#8920725)
    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.

  • by Anonymous Coward on Tuesday April 20, 2004 @02:40PM (#8920775)
    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.
  • by Ascaroth (629227) on Tuesday April 20, 2004 @02:41PM (#8920794)
    Here's a link to US-CERT's TA04-111A [us-cert.gov] on this topic.
  • Re:OpenBSD is safe? (Score:3, Informative)

    by paul_pick1 (540613) on Tuesday April 20, 2004 @02:43PM (#8920808)
    When someone exploits this and takes out 90% of the Internet's routers, you're screwed no matter what.

    Unless your business really doesn't care if most of the "internet's routers" are having trouble. My workplace can live very well with reduced internet access/functionality. When they get their troubles sorted out, we'll still be here (and be quite "un-screwed").

  • by costa9 (547892) on Tuesday April 20, 2004 @02:43PM (#8920814) Homepage Journal
    quote:"TCP also provides a number, called an acknowledgement number, that is used to indicate the sequence number of the next packet expected. The packets are reassembled by the receiving TCP implementation only if their sequence numbers fall within a range of the acknowledgement number (called a "window"). The acknowledgement number is not used in a RST packet because a reset does not expect a packet in return. (To be completely accurate, although the last statement is true for a RST packet without the ACK flag set, used to indicate that a TCP port is closed, a RST/ACK is used to terminate an active connection in the event of error. In a RST/ACK packet an acknowledgement number is included in the packet, although it is not checked by the receiving TCP implementation.)"

    Suppose the TCP Window size is 64K, then the probability of guessing valid ack number is 64K/2^32=1/64K

    It means if I spoof 65536 packets, I'll probably bring down a TCP link, if no router ingress filtering is involved.

    I guess the solution is also simple: for RST packet, restrict the receiving window size to be much smaller. Because larger window size is only for high speed data transfer and we do not restrict common packets, we are fine.

  • Re:Stupid (Score:4, Informative)

    by bwt (68845) on Tuesday April 20, 2004 @02:44PM (#8920825) Homepage
    What is new here is that you don't have to know the completely specified sequence number, but only something close enough to fit within a window. This reduces the search space and makes the attack more pragmatic.
  • Re:OpenBSD is safe? (Score:2, Informative)

    by binaryzone (773012) on Tuesday April 20, 2004 @02:46PM (#8920837)
    Mirror: http://www.freenshosting.net/niscc [freenshosting.net]
  • Re:Known issue (Score:3, Informative)

    by Mysticode (696150) on Tuesday April 20, 2004 @02:48PM (#8920868)
    The article doesn't say that Watson discovered the vulnerability but that he discovered a way that it could easily be taken advantage of. With 2^32 different sequence numbers it would take a while to try and find one within the window if the window is small enough however Watson has apparently found a way to guess a valid sequence number if as little as four tries. That's the issue here. Previously although it was technically possible, it wasn't a real concern because of the difficulty with guessing a valid sequence number.
  • Known and Old (Score:2, Informative)

    by spacerog (692065) <spacerogNO@SPAMspacerogue.net> on Tuesday April 20, 2004 @02:48PM (#8920869) Homepage Journal
    Not only is this a known issue, as others have posted, it is also rather old. The US Congress [senate.gov] was told about this same thing five years ago. This is just a new spin on the same idea. The net hasn't come crashing down in the last five years and I doubt that it will in the next five.

    See here [internetwk.com] and here [go.com].

    - Space Rogue

  • by jroysdon (201893) on Tuesday April 20, 2004 @02:51PM (#8920903) Homepage
    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 [cisco.com] .

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

    Or search CCO [cisco.com]:

    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.
  • by dre23 (703594) * <slashdot@andre.operations.net> on Tuesday April 20, 2004 @02:52PM (#8920933)
    BGP depends on IBGP (internal) as well in-between ASes (external). That means you could attack IBGP as long as it had a public IP, or if you had a route to it.

    Some BGP sessions would come back up automagically (some might require a manual reset (in Cisco IOS this is known as "clear ip bgp "). However, the attack could just bring them down again (every 4 minutes). BGP dampening would take effect depending on how it is configured upstream or downstream of your router(s). This would cause parts of the Internet to stay down for a long time (at least hours). Attackers could then concentrate on other targets during that time.

    OSPF and BGP are not comparable. They work together. Often, BGP requires OSPF (for building a table of valid next-hops) -- but once BGP is used -- there is generally no replacement for it. OSPF would carry routes from router addresses (point-to-point links), and BGP would carry customer and ISP routes. BGP on the Internet carries the necessary 130k routes to allow the Internet to work. OSPF can only carry about 10k routes, and it hurts to even do that. IOW, OSPF does not scale to large networks such as the Internet, but BGP does.

    There are many workarounds to this problem, most are identified in the advisory. People who lag behind the times could get hit [hard?] with this vulnerability, so it's always good to check and make sure your network is up to spec.
  • by JPriest (547211) on Tuesday April 20, 2004 @02: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 Anonymous Coward on Tuesday April 20, 2004 @02:55PM (#8920961)
    1) Read parent.
    2) Think about it.
    3) How many of you would notice if your box was down, then when you ssh'd into it because your boss was upset, would keep going inspite of the warning that the SSH key changed.

    Pwned!
  • by danimal (1712) on Tuesday April 20, 2004 @03:02PM (#8921082) Homepage
    dude, CanSecWest doesn't start until tomorrow. a month my butt. :P
  • by shostiru (708862) on Tuesday April 20, 2004 @03: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 Zondar (32904) on Tuesday April 20, 2004 @03:06PM (#8921144)
    iBGP is vulnerable to this as well, and very few of the networks I've worked on went to this level of filtering on their internal peering, just their external.

    Find a large network, determine it's topology, hope they're using iBGP for announcing the routes internally to the edge peering routers. Then it's a matter of finding which one to disrupt. Find the right one and a /16 drops out of your internal tables, just through knocking out an iBGP peer - never having had to touch the edge router. The route falls out of the edge router's table, and so he stops advertising it.

    Wait. Let it come back. Route gets advertised to external peer again.

    Repeat 3-4 times until the route is dampened by your victim's peers. Repeat 3-4 more times to get the default maximum 60 minute time-out.
  • Re:OpenBSD is safe? (Score:2, Informative)

    by ForsakenRegex (312284) on Tuesday April 20, 2004 @03:11PM (#8921228) Homepage
    I'd love to use OpenBSD. I've wanted to use it for years, but all my servers that mean anything to me are multi-processor boxes and the last time I checked OpenBSD still didn't support SMP.

    I didn't run out and check before writing this, so I apologize if things have changed since the last time I looked into OpenBSD.
  • by Floody (153869) on Tuesday April 20, 2004 @03: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.

  • Re:This is new?? (Score:5, Informative)

    by Geoff-with-a-G (762688) on Tuesday April 20, 2004 @03:17PM (#8921311)
    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.


  • Re:Good (Score:5, Informative)

    by silas_moeckel (234313) <silas AT dsminc-corp DOT com> on Tuesday April 20, 2004 @03:17PM (#8921320) Homepage
    LOL OK I happen to setup BGP router as part of my living so I might be able to shed some light on the subject. Standard security settings allready in place will stop this attack. OK Lets go for starters, BGP packets unless multihop should have a TTL of exactly 1 and come through a point to point interface. 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 same for any packets with the routers own address from comming in any interface. Thats basic router security. 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.

    This exploit along with many others could be made significatly harder to do if more ISP would just turn on anti spoofing rules. I cant think of a router that dosent support at least manual anti spoofing setups. The only time antispoofing might be a problem would be people that are utilizing multiple connections and trying to agrigate them together for outgoing bandwith.
  • Re:Good (Score:2, Informative)

    by jonadab (583620) on Tuesday April 20, 2004 @03:18PM (#8921335) Homepage Journal
    > I'm no expert, but wouldn't a security problem with TCP be completely
    > unrelated to IP?

    The problem stems from the fact that certain TCP state is too easy to guess,
    at least partly because TCP stuff is transmitted in the clear over IP. If
    you encrypt the traffic at the network (IP) layer, it will help a great deal.
    (No, I don't know whether IPv6 does this inherently, though of course it could
    be done with IPv6 just as easily as with IP.)
  • Re:This is new?? (Score:4, Informative)

    by the_quark (101253) on Tuesday April 20, 2004 @03:20PM (#8921355) Homepage
    I think the point is that it lets you perform this attack without being in the middle with a sniffer. The author figured out a way to significantly reduce the search space for the sequence number. Quoting from the article, "[Watson] noticed that the probability of guessing an acceptable sequence number is much higher than 1/2^32 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."

    Previously you had to have a packet sniffer in the middle to sniff the sequence and spoof it. Watson has pointed out a technique that allows you to guess the sequence in practical number of tries for connections that are long-lived (a few days).
  • by HTH NE1 (675604) on Tuesday April 20, 2004 @03:20PM (#8921369)
    Note: that's 1/2^32 (substitute your own favorite exponential syntax), not one in two hundred thirty-two.
  • by Anonymous Coward on Tuesday April 20, 2004 @03: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 Mateito (746185) on Tuesday April 20, 2004 @03:29PM (#8921492) Homepage
    > But if I understood it correctly, you can only
    > OSPF inside your own AS. Doesn't that mean, that
    > OSPF could never be considered a replacement for
    BGP?

    BGP is "an" exterior routing protocol, tho its more accurate to say that BGP is "the" exterior routing protocol

    OSPF won't scale anywhere near what is needed for the internet. The BGP routing tables have O(100000) routes, and those are summarized to hell and back.

    OSFP would so quickly fill up with external routes that your router would fall over quicker than a teenager at spring break.

  • by PureFiction (10256) on Tuesday April 20, 2004 @03: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 hambonewilkins (739531) on Tuesday April 20, 2004 @03:40PM (#8921664)
    Al Gore:During my service in the United States Congress, I took the initiative in creating the Internet. I took the initiative in moving forward a whole range of initiatives that have proven to be important to our country's economic growth and environmental protection, improvements in our educational system.

    Newt Gingrich, 9/1/00:Gore is the person who, in the Congress, most systematically worked to make sure that we got to an Internet.

    Al Gore and the Internet
    By Robert Kahn and Vinton Cerf

    Al Gore was the first political leader to recognize the importance of the Internet and to promote and support its development.

    No one person or even small group of persons exclusively "invented" the Internet. It is the result of many years of ongoing collaboration among people in government and the university community. But as the two people who designed the basic architecture and the core protocols that make the Internet work, we would like to acknowledge VP Gore's contributions as a Congressman, Senator and as Vice President. No other elected official, to our knowledge, has made a greater contribution over a longer period of time.

    Last year the Vice President made a straightforward statement on his role. He said: "During my service in the United States Congress I took the initiative in creating the Internet." We don't think, as some people have argued, that Gore intended to claim he "invented" the Internet. Moreover, there is no question in our minds that while serving as Senator, Gore's initiatives had a significant and beneficial effect on the still-evolving Internet. The fact of the matter is that Gore was talking about and promoting the Internet long before most people were listening. We feel it is timely to offer our perspective.

    As far back as the 1970s Congressman Gore promoted the idea of high speed telecommunications as an engine for both economic growth and the improvement of our educational system. He was the first elected official to grasp the potential of computer communications to have a broader impact than just improving the conduct of science and scholarship. Though easily forgotten, now, at the time this was an unproven and controversial concept. Our work on the Internet started in 1973 and was based on even earlier work that took place in the mid-late 1960s. But the Internet, as we know it today, was not deployed until 1983. When the Internet was still in the early stages of its deployment, Congressman Gore provided intellectual leadership by helping create the vision of the potential benefits of high speed computing and communication. As an example, he sponsored hearings on how advanced technologies might be put to use in areas like coordinating the response of government agencies to natural disasters and other crises.

    But, being blinded by ideology is so much MORE fun!

  • by jakedata (585566) on Tuesday April 20, 2004 @03: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 sharp-bang (311928) <sharp.bang.slashdot@NOSpAM.gmail.com> on Tuesday April 20, 2004 @03:48PM (#8921761) Homepage
    Here's the original quote from a CNN interview during the 2000 campaign:

    BLITZER: I want to get to some of the substance of domestic and international issues in a minute, but let's just wrap up a little bit of the politics right now.

    Why should Democrats, looking at the Democratic nomination process, support you instead of Bill Bradley, a friend of yours, a former colleague in the Senate? What do you have to bring to this that he doesn't necessarily bring to this process?

    GORE: Well, I will be offering -- I'll be offering my vision when my campaign begins. And it will be comprehensive and sweeping. And I hope that it will be compelling enough to draw people toward it. I feel that it will be.

    But it will emerge from my dialogue with the American people. I've traveled to every part of this country during the last six years. During my service in the United States Congress, I took the initiative in creating the Internet. I took the initiative in moving forward a whole range of initiatives that have proven to be important to our country's economic growth and environmental protection, improvements in our educational system.


    OK, this isn't the greatest phraseology, but the gist is that he supported the development of the Internet through legislative initiatives. If you doubt this, there's a nice summary [sethf.com] at Seth Finkelstein's website.

    Y'know, I saw this interview when it happened, and I certainly didn't come away with the impression that Al was grandstanding. (This said as an early Bradley supporter... I certainly don't agree with his implication that Bradley *didn't* produce important legislation.) I mean, it's not like he put on a flight suit and strutted around while US soldiers were getting blown to sh*t or anything.
  • Re:OpenBSD SMP (Score:5, Informative)

    by mi (197448) <slashdot-2014@virtual-estates.net> on Tuesday April 20, 2004 @03:48PM (#8921768) Homepage
    Combine that with the fact that almost all of the programs used on a modern UNIX-like system arn't CPU bound and it's easy to see why SMP took a back seat to more "interesting" issues.

    Wrong. Very wrong. Are you anaware of this field called "banking"? What about "financial trading"? These firms have huge portfolios and run and re-run various models on them. At night, the systems have to run various "end-of-day" scripts and reports, which take CPU-hours to complete. Most of this things run on Unix...

    There is also on-the-fly image manipulation, and the scene-rendering done by fleets of Unix machines. The more CPUs each such Unix machine can fit, the better.

    Then come databases -- depending on the queries (with joins and orderings), DB-servers can be CPU bound and appreciate multiple processors when available.

    What about PVM [ornl.gov]? What was it -- and similar packages both free and commercial -- written for? What about this proverbial "beowulf clusters"? Of course, it is much better to have several CPUs inside the box, rather than in separate machines.

    However there is a developer being paid to work full time writing SMP support for OpenBSD. He expects to have a working implementation by 3.6 or 3.7.

    Until which time, the OpenBSD zealots will continue to deny the issue exists or is of any importance. I see...

  • IPv6? (Score:2, Informative)

    by laurent420 (711504) on Tuesday April 20, 2004 @03:52PM (#8921816)
    Of everyone rambling about switching to udp/icmp/ipx/whatever, few if any have mentioned that IPv6 would be a solution to this issue. IPv6 has manditory IPSec so predicting anything but where each packet is going to/comming from will be quite difficult.

    happy 4/20 :>
  • by BusDriver (34906) <tim@muppetz.com> on Tuesday April 20, 2004 @03:52PM (#8921824) Homepage
    If you read the article it'll explain it for you, but basically:

    Routers from different AS's talk to each other using BGP4. This protocol uses TCP.

    The "exploit" uses spoofed packets, so the router will process them as if it came from their neighbour.

    So yes, while the router is mostly "shoveling packets", it learns the direction in which to shovel these packets via the exploitable method.

    If you want to disagree, feel free to let all the major tier 1 ISPs who have been busily implementing MD5 authentication on their BGP sessions know their wrong.
  • by {tele}machus_*1 (117577) * on Tuesday April 20, 2004 @03:53PM (#8921832) Journal
    Link here [nytimes.com] (soul reaving required).

    In the article Watson is quoted as saying that any hacker can figure out this exploit in five minutes from the vaguest explanation. If that's true, why reveal the exploit until someone has figured out how to completely patch it? Or has the fix already been figured out? I couldn't tell from the article.
  • by janoc (699997) on Tuesday April 20, 2004 @03: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
  • Re:OpenBSD is safe? (Score:4, Informative)

    by netwiz (33291) on Tuesday April 20, 2004 @04: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.
  • Re:OpenBSD is safe? (Score:3, Informative)

    by photon317 (208409) on Tuesday April 20, 2004 @04:15PM (#8922119)

    What it means is that OpenBSD's tcp stack by default has some of the neccesary protections to slow down or stop this attack, like randomized source ports, randomized TCP ISNs, etc.
  • by boomgopher (627124) on Tuesday April 20, 2004 @04:18PM (#8922166) Journal
    This is sort of on topic with your post. Here's a discussion and visualizations of various OS's TCP sequence numbers:

    Strange Attractors and TCP/IP Sequence Number Analysis [bindview.com]

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

    by lcde (575627) on Tuesday April 20, 2004 @04: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......


  • RFC 2385 (Score:5, Informative)

    by apankrat (314147) on Tuesday April 20, 2004 @04: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.

  • Old News... (Score:1, Informative)

    by Anonymous Coward on Tuesday April 20, 2004 @04:54PM (#8922590)
    I was at a Linux convention in Amarillo in 1999 held by the local Linux Users Group [alug.org] (which seems dead now). There were a couple of people there discussing this very item (though one person insisted that it was "in theory", but I got the feeling that he had an exploit working already)....
  • Nice try, but no. (Score:3, Informative)

    by mark-t (151149) <markt@lynx. b c .ca> on Tuesday April 20, 2004 @05:39PM (#8923044) Journal
    This would only work if there were one, and only one, route that packets would take when travelling from system A to system B. Although in general this is true because of the particular implementations that we have so far, it is in fact a specific design goal of IP to not assume that this is the case.

    Your solution causes anyone using multiple pipes to transmit at a higher speed to be stopped short and forced through one incoming interface, even though you might have actually been able to handle the traffic.

  • Re:BGP vulnerable (Score:3, Informative)

    by elvey (86546) on Tuesday April 20, 2004 @06:03PM (#8923269) Homepage
    Your'e lazy, not stupid.
    It's not MD5 applied higer up in the OSi stack thant TCP, it's a modification to TCP itself that uses MD5: http://www.ietf.org/rfc/rfc2385.txt
    Briefly, here's what the sender does: take the usual IP packet, add a secret key, and a checksum of the above, and send that. It's amazing that an electronic Pearl Harbor hasn't happened yet.
  • by spurious cowherd (104353) on Tuesday April 20, 2004 @06:08PM (#8923298)
    Here [cisco.com]

  • Re:Good (Score:2, Informative)

    by InvisibleCraterFunk (29222) on Tuesday April 20, 2004 @06:17PM (#8923380) Homepage
    "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 MD5 protection happens at the TCP layer. Each TCP segment is verified. TCP MD5 could be used for other things than BGP. So yes, TCP MD5 would mitigate the attack sufficiently for now.
  • by theLOUDroom (556455) on Tuesday April 20, 2004 @06:20PM (#8923412)
    (see subject)

    This attack is based on TCP accepting a RANGE of numbers. This range can be artifically widened using forged messages. As a result, it does not matter how good you RNG is, this exploit is about making it easy to search the entire space of possible numbers.

    Even if your RNG (Random Number Generator) was perfect, you could still be vulnerable to this attack.
  • Re:OpenBSD is safe? (Score:4, Informative)

    by Silvers (196372) on Tuesday April 20, 2004 @06:45PM (#8923580)
    If you are using MD5 encryption that is built into BGP4 that won't help you. That merely will stop route poisoning and such. As long as your underlying TCP/IP implementation isn't authenticating source/destination you can still get hosed.

  • Re:OpenBSD is safe? (Score:2, Informative)

    by Anonymous Coward on Tuesday April 20, 2004 @07:10PM (#8923797)
    The fact is, with IPv6 you can prevent man in the middle attacks like using encryption. Since the communication will be encrypted and both ends authenticated, any packet from a third party will simply be dropped by the IPv6 stack and won't even reach the TCP layer.
  • Re:OpenBSD is safe? (Score:2, Informative)

    by fox8118 (538985) on Tuesday April 20, 2004 @08:11PM (#8924278)
    Correct me if I am wrong, but Cisco posted the security advisories with some fixes on this subject.

    http://www.cisco.com/warp/public/707/cisco-sa-2004 0420-tcp-ios.shtml [cisco.com]

    and

    http://www.cisco.com/en/US/products/products_secur ity_advisory09186a008021ba2f.shtml [cisco.com]
  • Re:OpenBSD is safe? (Score:2, Informative)

    by moron brother (773174) on Wednesday April 21, 2004 @01:55AM (#8926284)
    Hold on a second. TCP is not a routing protocol! It is a supplement to routing protocols, such as BGP. I think what you meant was IPv4 and IPv6...right? well those are considerably different than TCP. IP is layer 3. That is, IP works in concert with TCP, but has nothing to do with sequence numbering and handshaking, which this vulnerability found. Implementation of IPv6 will do little against a vulnerability in TCP, since IP deals with end-to-end addressing. It's just switch from 32-bit to 128-bit addressing. I can get the IPv6 address, guess the appropriate sequence number, jump into that particular stream, and get connected just as usual. Trying to carry out this exploit tomorrow in the lab will be tons of fun. Cisco routers running BGP are fun to exploit..
  • The Exploit (Score:3, Informative)

    by Lumin Inverse (471513) on Wednesday April 21, 2004 @03:11AM (#8926553) Journal
    The following pseudo command will send an exploit packet:

    linverse@KOS-MOS:~/blackhat/hping2-linv erse$ hping2 [victim.ipaddy] --spoof
    [server.ipaddy] --rst --baseport [server.port] --destport [rand()%65536] --setseq
    [rand()%((2^32)-1)] --sign "TCP RST Attack"

    Each packet sent in this manor has a 1/2^32 chance of succeeding. You need to guess two (effectively) 16 bit numbers: the victim's unknown open port, and the tcp sequence number (within ~16 of its 32 bits, depending on the windowsize) This requires something on the order of 4 billion packets to have a reasonable expectation of closing the connection. There is really no way of knowing if or when a given connection is closed, unless you're taking down routers with it, or some othe observable scenario.

    I modified hping2 to spam a victim with these packets. Attempting to reset a local connection with a remote machine takes approximately 20 hours to send the requisite ~4 billion packets. Were these packets to actually travel over a network, it should slow things down significantly.

    If one had an army of zombies, then obviously the 20 hour figure can become a 20 minute, or even 20 second figure. But flooding a computer with 4 billion packets in 20 seconds will likely be at least as destructive as the actual payload, except perhaps in the case of major routers communicating over BGP.

    Interestingly enough, however, one can still cause massive damage without flooding a single router. Instead, have each of your thousands of zombies try to take down arbitrary routers (perhaps each one sends packets randomly to each known major router). This algorithm allows one to make huge amounts of guesses without saturating the connection to any given router.

    If my calculations are correct, then 10000 zombies armed with my exploit and a list of major routers could take them down at a rate of one per 7.2 seconds. At this point, we're talking about serious problems.

    Has anybody else done any field testing / analysis?
  • Re:OpenBSD is safe? (Score:2, Informative)

    by psmears (629712) on Wednesday April 21, 2004 @05:02AM (#8926892)
    Not true - the MD5 authentication in BGP4 makes use of a little-known TCP option to add an MD5 signature to each TCP packet (see RFC2385 [faqs.org]) - so the protection is at the TCP layer, and configuring MD5 auth for BGP will help :-)

    (In fact, as far as I know, the MD5 option was added to TCP specifically to get round this vulnerability in BGP!)

    Patrick

  • Re:OpenBSD is safe? (Score:2, Informative)

    by psmears (629712) on Wednesday April 21, 2004 @06:23AM (#8927135)
    I'm not sure how many do - this option isn't used for anything other than BGP, as far as I know, so TCP implementations on routers will tend to have it, but others don't...

    This feature is not very easy to use - both ends of the TCP connection need to know (and configure) a shared secret; this is the major reason why a lot of ISPs haven't set this up already - the router configuration is fairly trivial, what's complicated is co-ordinating with all the ISPs you peer with and arranging a different shared secret with each one (and then getting them to configure the option at exactly the same time that you do!)

What the world *really* needs is a good Automatic Bicycle Sharpener.

Working...