|
|
User Controls
|
New User
|
Login
|
Edit/View My Profile
|
|
|
|
ActiveMac
|
Articles
|
Forums
|
Links
|
News
|
News Search
|
Reviews
|
|
|
|
News Centers
|
Windows/Microsoft
|
DVD
|
ActiveHardware
|
Xbox
|
MaINTosh
|
News Search
|
|
|
|
ANet Chats
|
The Lobby
|
Special Events Room
|
Developer's Lounge
|
XBox Chat
|
|
|
|
FAQ's
|
Windows 98/98 SE
|
Windows 2000
|
Windows Me
|
Windows "Whistler" XP
|
Windows CE
|
Internet Explorer 6
|
Internet Explorer 5
|
Xbox
|
DirectX
|
DVD's
|
|
|
|
TopTechTips
|
Registry Tips
|
Windows 95/98
|
Windows 2000
|
Internet Explorer 4
|
Internet Explorer 5
|
Windows NT Tips
|
Program Tips
|
Easter Eggs
|
Hardware
|
DVD
|
|
|
|
Latest Reviews
|
Applications
|
Microsoft Windows XP Professional
|
Norton SystemWorks 2002
|
|
Hardware
|
Intel Personal Audio Player
3000
|
Microsoft Wireless IntelliMouse
Explorer
|
|
|
|
Site News/Info
|
About This Site
|
Affiliates
|
ANet Forums
|
Contact Us
|
Default Home Page
|
Link To Us
|
Links
|
Member Pages
|
Site Search
|
Awards
|
|
|
|
Credits
©1997/2004, Active Network. All
Rights Reserved.
Layout & Design by
Designer Dream. Content
written by the Active Network team. Please click
here for full terms of
use and restrictions or read our
Privacy Statement.
|
|
|
|
|
|
|
|
Time:
12:46 EST/17:46 GMT | News Source:
Washington Post |
Posted By: Robert Stein |
The U.S. Department of Homeland Security issued an alert Tuesday afternoon warning that the vulnerability could be used to "affect a large segment of the Internet community."
The exploit, identified by 36-year-old Milwaukee security researcher Paul Watson, could give hackers the ability to crash Internet routers -- the complex machines that direct most of the world's Web traffic.
The method that Watson identified takes advantage of an inherent design flaw in transmission control protocol (TCP) -- the language that all computers use to communicate on the Internet -- that could place ordinary computers at greater risk of attack.
|
|
#1 By
135 (208.186.90.168)
at
4/21/2004 1:26:22 PM
|
The Internet must be destroyed, so that we can rebuild it!
|
#2 By
931 (66.180.122.62)
at
4/21/2004 6:04:41 PM
|
this was known for a long time; it's important to address to the extent possible but it's not as big a deal as it's being pimped as. Hell I can think of many recent worms that actually represent a bigger risk then this.
|
#3 By
18033 (211.26.193.94)
at
4/21/2004 8:42:19 PM
|
How can a worm be a bigger risk? Please justify. The worms destroy servers and computers deemed to be the 'fringe' or 'outer edge' of the internet. They slow things down make sites unavailable via means of a DoS attack, and huge amounts of traffic is generated when they scan for other hosts to infect, causing major slowdowns for some poeple, but THIS tcp flaw could bring down the 'core' of the internet. In effect rather than these viruses/worms being pointed at a one or two sites, making them unavailable, this flaw could make thousands of sites/services unavailable all round the world.
In my mind this flaw is far more serious than any worms we have seen.
Thanks goodness it has been kept under wraps!
|
#4 By
12071 (203.185.215.149)
at
4/21/2004 9:10:35 PM
|
#3 Surely by now you realise that if you're after misinformation, misdirection and utterly blind ignorant FUD, Parkker's your man!
#1 "I am glad this flaw was kept quiet for as long as possible so that vendors could work on proper fixes."
This "flaw" (this is not a "flaw", it's a design feature, the "flaw" only exists because packets can be spoofed) has been known about for a long time, but let's look at it a bit more closely:
CERT published an advisory in May 2001 about this "flaw", which you can read for yourself here:
http://www.cert.org/advisories/CA-2001-09.html
Read the History section for a detailed account. However, in summary, in 1985 Bob Morris first identified potential security concerns with TCP (i.e. ability to spoof). In 1989, Steve Bellovin observed that spoofing could be adapted to attack client connections by simulating unavailable servers and proposed solutions for strengthening TCP ISN generators. In 1995, CERT published an advisory on these spoofing attacks (http://www.cert.org/advisories/CA-1995-01.html), that same year Laurent Joncheray described how an attacker could actively hijack a TCP connection. If the current sequence number is known exactly and an attacker's TCP packet sniffer and generator is located on the network path followed by the connection, victim TCP connections could be redirected. Later on it was found that the sequence number does not have to be exactly correct, it just needs to be within the current receive window!
You'll notice that OS' like OpenBSD and FreeBSD were extremely resilient to that sort of attack, and so was Linux which has used a variant of RFC1948 by default since 1996.
So what's changed between 2001 and now? Not a lot! In this particular circumstance they mention that BGP is at risk due to the fact that is uses such large receive window sizes (i.e. there's less guesses that you have to make). Note that RFC 2385 (Protection of BGP Sessions via the TCP MD5 Signature Option - http://ietf.org/rfc/rfc2385) has been out since August 1998!
[EDIT] Apologies shed2069, typo!
This post was edited by chris_kabuki on Wednesday, April 21, 2004 at 21:31.
|
#5 By
12071 (203.185.215.149)
at
4/21/2004 9:15:22 PM
|
I'll quote Theo de Raadt (think OpenBSD):
"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.
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......"
|
#6 By
18033 (211.26.193.94)
at
4/21/2004 9:20:24 PM
|
#5, Dont misquote me please.
|
#7 By
12071 (203.185.215.149)
at
4/21/2004 9:20:47 PM
|
#4 "Thanks goodness it has been kept under wraps!"
Stop listening to Parkker! It hasn't been "kept under wraps"! Read the CERT Advisory, this has been known about for a very long time, it just hasn't been exploited very often as it was thought to be too difficult to guess the correct sequence number, or because it wasn't worth the effort of trying to guess the correct sequence number (within the receive window) for a simple DoS attack when other DoS attacks were far simpler to accomplish.
|
#8 By
18033 (211.26.193.94)
at
4/21/2004 10:24:47 PM
|
#8, Much better. Thanks :-)
And yes from reading CERT advisory, its very clear this has been around for years. Thanks for the link!
This post was edited by shed2069 on Wednesday, April 21, 2004 at 23:26.
|
#9 By
12071 (203.185.215.149)
at
4/22/2004 12:24:43 AM
|
#10 "Yes and no."
It hasn't been kept under wraps.
"An attacker armed with a typical broadband connection could send all 260,000 possible attacks in less than 15 seconds."
Correct, as I mentioned and as Theo mentioned the issue is that it is clear that the accuracy with which you have to guess the sequence number decreases the larger your receive window is set to (Think RWIN size when you were trying to optimise this for your modem connection all those years ago - and you probably did something similar now with your adsl/cable modem). The reason why BGP is mentioned is that by default the receive window size is set to a very large number meaning that your guess just has to fall in within that range.
The solution which OpenBSD (and others) have used is to have smaller receive window sizes (ensuring that your guess has to be far more accurate - i.e. you will need a lot more guesses to find it), to randomly change the target port number, plus a few other tricks (as Theo mentions). As a result you need far more than 260,000 attempts and you will need to do those against all 48,000 ports (which are randomly changing). Note that if it does take you 15 seconds to send all the attacks (given you have enough bandwidth), you still need to be lucky enough to hit the right target port with the right sequence number guess, before all of that changes!
The result of this is that it is fairly much impossible to do this 'exploit' against an OpenBSD machine. Theo has tested this on an ethernet to show that OpenBSD is almost completely resilient to this form of attack. He says, however, that there are a few more additions which can be implemented to make it even harder.
|
#10 By
12071 (203.217.20.114)
at
4/22/2004 5:33:30 AM
|
#12 Imagine that, for once we agree on something!
The reason I mentioned OpenBSD (in particular) was to show that this isn't necessarily a 'flaw' in the TCP specification (as it was designed with the reset and sync commands the way they are) but more of a 'flaw' in the individual implementations of the TCP specification. Those based on the BSD TCP/IP stack are very resilient to this attack, others such as Cisco's are not.
And this vulnerability was not kept quiet, it's been known about since at least 1996. At that time however, it was thought to be harder to accomplish than it actually is. But it doesn't change the fact it's been known about since 1996! And the BSD's and Linux have been able to handle this since 1996, I don't know about the other OS' so I cannot say. So nothing was kept quiet, it's all been out in the open, the WAY IT SHOULD BE!
This post was edited by chris_kabuki on Thursday, April 22, 2004 at 05:36.
|
#11 By
12071 (203.185.215.149)
at
4/22/2004 8:40:19 PM
|
#14 No the methodology to "efficiently" exploit it was available in 1996 and 1998, the proof is in the fact that the BSD OS implemented those "methodologies" and hence when this particular "exploit" came out, the BSD's were resilient to it based on the fixes that went in all those years ago. The only thing added since was additional countermeasures to make it even harder, but that doesn't change the fact that it was already close to impossible to do against the BSD stack anyhow.
Just because you didn't hear about it doesn't mean it's been kept quiet. Nothing was kept quiet here, it's all been known about for a long time! Blame Cisco for not including all the appropriate countermeasures - they could have taken them directly from OpenBSD for free!
|
|
|
|
|