Slashdot Mirror
TCP Vulnerability Published
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 just hit the misc@openbsd mail list:It sounds (again) like proactive security auditting saves the day!
http://www.osvdb.org/displayvuln.php?osvdb_id=4030
...
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.
Move along, little to see here.
John.
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.
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.
A little more info...actually has a link to www.terrorist.net (im sure the feds love that...)
n et -Threat.html
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-Inter
As frightening as this "vulnerability" sounds, this is nothing really new; other TCP weaknesses are syn floods (not quite the same thing, but somewhat similar -- in fact, this vulnerability might as well be called a "RST flood"), connection hijacking (by sniffing packets and sending spoofed packets with the correct sequence numbers), and so on. It's also an implementation issue that is largely caused by implementations having loose checking of TCP sequence and ack numbers, or accepting too large of a window of sequence numbers.
I wouldn't say TCP is broken or that some other solution would be much better; it would be tough to design a transport protocol that is still simple (and doesnt use CPU burning hashing/encryption techniques) that wouldn't have these sorts of vulnerabilities (especially since it's so easy to spoof IP packets); calling this vulnerability severe is like screaming that highways are fundamentally unsafe because someone could point their car the wrong way and start smashing into oncoming traffic.
-fren
"Where are we going, and why am I in this handbasket?"
Service providers on the other hands, must protect their routers because the BGP protocol used to distribute Internet routes between them, massively uses TCP. And when routes go missing, it is hundreds if not thousands of routes to your favourite places that go unreacheable.
The problem in the case of BGP is made worse by dampening, i.e. keeping the flapping routes out of the routing table for a certain amount of time (up to several hours). BGP routes dampening is not always configured. A determined attacker with this knowlege would be able to knock large portions of the Internet offline for hours.
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.
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 on it in 1989).
3.2.1.4. TCP RST/FIN/FIN-ACK
For more information about what TCP resets are and why they can be harmful, see RFC3360.
Please correct me if I got my facts wrong.
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.
My Web Page
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.
No. IPSEC is mandatory in IPv6: IPSEC is one of the three mitigations listed.
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.
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
- 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, 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.===== Murphy's Law is recursive. =====
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.
This sig has been temporarily disconnected or is no longer in service
Real quote.
God Bless America. Why? Did it sneeze?
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.
Here's a link to US-CERT's TA04-111A on this topic.
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.
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.
See here and here.
- Space Rogue
As they state, there is a simple solution: TCP MD5 Signature Option with BGP. Any ISP worth their salt will already be doing it. The rest will learn the hard way.
.
This has been supported in Cisco IOS way back since ~1998 in IOS 11.2
Read the BGP "Bible": Internet Routing Architectures or look at any best-practices guides which will state that TCP MD5 sigs should always be used with BGP.
Or search CCO:
router bgp 109
neighbor 145.2.2.2 password v61ne0qkel33&
It's just a single line that has to be added to both peer sides.
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.
IPv4 allocations for hobbyists? join the ipalloc-l mailing-list! www.operations.net/mailman/listinfo/ipalloc-l
The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set.
The packets need to have source and destination IP addresses that match the established connection as well as the same source and destination TCP ports.
The fact that TCP sessions can be reset by sending suitable RST and SYN packets is a design feature of TCP according to RFC 793, but a reset attack is only possible at all because the source IP address and TCP port can be forged or "spoofed".
Although denial of service using crafted TCP packets is a well known weakness of TCP, until recently it was believed that a successful denial of service attack was not achievable in practice. The reason for this is that the receiving TCP implementation checks the sequence number of the RST or SYN packet, which is a 32 bit number, giving a probability of 1/232 of guessing the sequence number correctly (assuming a random distribution).
The discoverer of the practicability of the RST attack was Paul A. Watson, who describes his research in his paper "Slipping In The Window: TCP Reset Attacks", presented at the CanSecWest 2004 conference. He noticed that the probability of guessing an acceptable sequence number is much higher than 1/232 because the receiving TCP implementation will accept any sequence number in a certain range (or "window") of the expected sequence number. The window makes TCP reset attacks practicable.
Any application protocol which relies on long term TCP connections and for which the source and destination IP addresses and TCP ports are known or can be easily guessed will be vulnerable to at least denial of service attacks
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
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!
dude, CanSecWest doesn't start until tomorrow. a month my butt. :P
A recently published I-D (here) claims 200 seconds is sufficient time for a broadband sub to successfully attack a TCP session, provided their ISP doesn't use egress filtering (and way too few do so).
This is rather serious. Whether you personally aren't susceptible is irrelevant if your upstreams are.
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.
/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.
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
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.
The UK National Infrastructure Security Co-Ordination Centre (NISCC) released a vulnerability advisory today on issues in the TCP protocol. Aka More info on vuln...
Looks like MD5 Can save your router...
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.
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.
No sir I dont like it.
> 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.)
Cut that out, or I will ship you to Norilsk in a box.
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).
Note: that's 1/2^32 (substitute your own favorite exponential syntax), not one in two hundred thirty-two.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
This came up on the linux-kernel mailing list two years ago during a thread on TCP MD5 stuff to avoid this very problem. Why is it just now making a splash?
This post from Alan Cox covers it nicely. Also see the rest of the thread.
> 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.
Norman Cook's Ode to Sl
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 is important.
This is old news.
For the insanely paranoid use a hardware entropy generator (TRNG) 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...
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!
God Bless America. Why? Did it sneeze?
Title: Juniper NetScreen Advisory 58784
t ao/co ntact.html
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/
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.
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 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.
#!
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? 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.
Until which time, the OpenBSD zealots will continue to deny the issue exists or is of any importance. I see...
In Soviet Washington the swamp drains you.
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
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.
Link here (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.
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, JanThis 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
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
There is RFC 2385 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.
3.243F6A8885A308D313
I was at a Linux convention in Amarillo in 1999 held by the local Linux Users Group (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)....
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.
File under 'M' for 'Manic ranting'
Time flies like an arrow, fruit flies like a banana.
"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.
(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.
Life is too short to proofread.
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?