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!
Just unplug your PC from the internet and wash your hands of it.. the whole thing feels holier than swiss cheese :(
This kind man responsible for finding this vulnerability is going to present this exploit at the security conference in Vancouver this Thursday. He then predicts "hackers will understand how to begin launching attacks 'within five minutes of walking out of that meeting.'" The article talks about how the government has been "fortifying" its networks against this, does that means they quickly rewrote the tcp protocol? I would love to know.
...will turn out to be nothi* [Carrier Lost]
let's all just start again
...
TCP2
SMTP2
POP32
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.
I'm removing support for TCP right now. Give me UDP or give me death!
Looks like someone left ISEXPLOITABLEFLAG = TRUE in the code.
The Blaster Master Fighting for Truth, Justice, and Evil Pie since 1979
I'll just switch to UDP.
-- Repeat with me: "There is no right to profits".
Move along, little to see here.
John.
A quick scan of the advisory gives me the impression that BGP-users are most vulnerable. Dunno how scared the rest of us should be.
I, for one, welcome our new Antichrist overlord.
First SYN!!!
As a web designer, taking advantage of this could get me off work faster than a snow storm. I don't know if I'm afraid or enthused. ;)
to switch over to IPX
Everyone cower under their tinfoil hats..
How can we blame this on Microsoft?
pssst, hey mods - it's a joke....
Dr. Peter Venkman: This city is headed for a disaster of biblical proportions.
Mayor: What do you mean, "biblical?"
Dr. Raymond Stantz: What he means is Old Testament, Mr. Mayor, real wrath-of-God type stuff. Fire and brimstone coming down from the sky. Rivers and seas boiling.
Dr. Egon Spengler: Forty years of darkness. Earthquakes, volcanoes...
Winston Zeddemore: The dead rising from the grave.
Dr. Peter Venkman: Human sacrifice, dogs and cats living together - mass hysteria.
"This isn't a study in computer science, its a study in human behavior"
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.
It seems to only be really a problem if you have long-lived TCP connections and easily guessed next-hops, which is why the announcement focuses on BGP. Looks like I'll be upgrading some router firmware tonight...
All's true that is mistrusted
...I'm running AmigaDOS.
you can exploit slow start too. was published last year for some conference. The paper is called "The Shrew vs. the Mice and the Elephants" and is by Aleksandar Kuzmanovic and Edward W. Knightly
I write code.
Your computer is broadcasting an IP address!
Seriously though, it doesn't look all that bad. (Nor does it look all that hard to do, but still..)
www.gotontheinter.net
Updated vaguely once a whenever, maybe once a whenever-and-a-half.
Tony had discovered this vulnerability about a year ago. Luckily it was first discovered by an intelligent and ethical IT security guy and not some unscrupulous hacker. He has quietly worked with vendors during that time helping them come up with a solution.
I, for one, welcome our new.. uh.. TCP exploiting overlords?
If this is Heaven I'm bailin out! I cant tolerate this ol tin-tub, so fulla trash and rats...
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
After all, he invented the internet, right?
This was bound to happen:
"The operation timed out attempting to connect to www.uniras.gov.uk"
oh, the irony,
--Stephen
Did you ever notice that *nix doesn't even cover Linux?
Hmm.. I'm using OpenBSD on my desktop as I type this. Seems like it has enough features to me. (not using KDE though, moved to lightweight Windowmaker..)
NISCC slashdotted so fast... what would happen in a real emergency??? when everybody really wants to know...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
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
This is really just trying to get someone's name out on the security sites. Currently, in a decent TCP/IP implementation, you have to know the source and destination IP's, the source and destination ports, and the sequence number. Now, some of those are fairly easy to determine, but others like the source port (assuming connecting to a server) and the sequence number are not. (BTW, I do realize that in some crappy implementations the source port is easy to guess, but whatever) You would need to be able to sniff the actual connection. And in all honesty, if you can sniff the connection, there are much easier ways to cause a DOS (for example, bringing down the interface).
Best slashdot comment
My Mac was so lacking in serious vulnerability, they had to threaten the whole dang internet just to get to me! Now I have TWO reasons not to download mp3s!!!
Yeah, I guess I'm funny like that.
... since TFA goes on to say the vulnerability explicitly affects "long-lived" TCP connections, not the POP3 / HTTP / SMTP that Joe User relies on. However, for businesses and security wonks this is a potentially big deal.
"I may be a fat nerd, Marge, but YOU have a gambling problem!!!"
i'm posting this over NetBEUI Protocol ;)
*sight*
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.
I'm sorry... how does cleaning spyware have anything to do with this article? Shaddup.
"Professor, without knowing precisely what the danger is, would you say it's time for our viewers to crack each other's heads open and feast on the goo inside?"
"Yes I would, Kent."
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.
I'm glad I stocked up on duct tape after they told us too. I have plenty to seal off my NICs.
Apparently terrorist.net's router has already been attacked.
"Watson, who runs the www.terrorist.net Web site, predicted that hackers will understand how to begin launching attacks 'within five minutes of walking out of that meeting.'"
He went on to say that you can expect to see the first Spam offering a software patch for $19.95 within 60 seconds of walking out of that meeting.
666-607: 6th floor apartment of the beast
affects everyone and everything
for some values of everyone and everything
I'll bet the first person to reply $10 that plan9 isn't affected.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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
Spoofed IP addresses? Predictable TCP sequence numbers? Hey, 1998 is calling - they want their security advisory back.
Oh god, you can spoof a reset into a TCP window. Oh god, some network hardware vendors have large windows and non-pseudorandom TCP sequence number prediction.
This only becomes a vulnerability when you run an application over TCP that does something catastrophic when it loses a connection. In this case, that would be unsecured BGP (or, if 1998 is calling, unsecured telnet).
People get paid to write papers about this shit? I need a beer.
BGB disruption. This is worse than you can even guess. I anticipate this will lead to effective phishing scams, and other things.
The danger is that by killing off the legiment routes to a host, somebody with a cracked router can then claim to have the legitament route to the host. Which of course, it doesn't. So, quite effective traffic redirection from the internet to a malitious web server.
This vulnerability relies in part on the problem that it is easy to send an IP packet with a false source address (IP spoofing).
What is the reason preventing IP carriers from implementing anti-spoofing filters ?
In some environments this is certainly difficult, but most carriers know if a source address of a packet leaving their network is valid or not and could just drop spoofed packets.
In practice there will certainly be difficulties, but I think such filtering is a necessary evil like anti-spam and anti-virus mechanisms.
Markus
The TCP (The Clippy Program) has grown beyond your control, soon he will spread through this network as he spread through Windows-sock
Never use naming conventions that resemble anything as insecure as Windows or Clippy for god's sake
for the 7th protocol! Aren't we supposed to be connected without electronics, then?
Those who have seen Serial Experiments Lain would get the joke. Those who don't, I feel sorry for you.
The big guys already knew about this.
The script kiddies just found out.
If you're a script kiddie and you try to exploit, you won't get anywhere, and you'll get arrested.
If you're a serious hacker, you won't do that.
If you're a serious cracker, you either already have done it, or you've moved on to another, juicier target, because there's no pride in going in after Yahoo! news stories.
So this is just a way for the FBI to track down script kiddies.
"Piter, too, is dead."
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
Is that you master?
L. Skywalker
In a quickly following press release, Bill Gates adds:
Wow. That uninterrupted block of text hit so hard it set off my browser's airbag!
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
This might prompt faster migration to IPv6. Especially if all IPv4 services are constantly attacked by this.
www.urinas.gov has the story. Is this meant as a joke?
Tech, life, family, faith: Give me a visit
I am a lonely man living on the Galapagos Island. I use TCP/IP over carrier pigeon to communicate with a Nigerian who has promised my great wealth in exchange for securing funds in the First Galapagos Bank, of which I am owner/ceo/clerk, and janitor.
/obscure humor (Does this make me a Galapagos Spammer?)
I suspect someone is interupting my data stream and keeping the replies and account numbers he has been sending me in regards to my money. This vulnerability proves my theory. I am in desperate need!! How can I prevent this!!
Anyone willing to help I will share my wealth with.
Is this similar or the same as this FreeBSD vulnerability? That one was fixed in 1998.
Please correct me if I got my facts wrong.
Probably should moderate as Troll as opposed to Offtopic.
For those who didn't read the article, this is a flaw in the protocol not necessarily the implimentation. The concern is over the network itself in addition to client systems. Exploiting this could lead to resetting routers and client systems essentially shutting down networks.
At my corporation, they run a product which listens for P2P software like Kazaa and exploits this vulnerability by sending a spoofed RST to shut down the service. I had to patch my TCP stack to check the ACK # in order to keep my FastTrack client leeching porn.
Sounds like IETF is zeroing in on these guy's business model. Good. The anti-P2P vendors will probably catch up by spoofing both numbers, but they will have to ensure that their RST beats the actual packet there, which is tricky.
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.
Hey, the 3 way handshake works for establishment, and it'd solve this problem if we implemented it for disconnections.
x wishes to close connection, y checks this by sending random bits and a check request, x sends these bits back to ensure that it really is x wishing to close it, and voila.
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.
Can we keep the public off the next Internet?
They really screwed things up on this one.
...but that last line from Bill Murray always has me PMSL. How on god's sweet earth did he manage to fall from grace and appear in Lost in Translation?
I love how a well respected security firm like Yahoo is the first to break the news. I figure at this rate, I should start watching the AOL personals page for analysis of the next worm outbreak...
Just block the packets that will have the evil bit set. After all, it was for cases like this it was introduced. Doh!
I can't believe where we're heading today, when so many developers sloppily seem to think "bah, just another useless standard we can ignore" when the standard in question is a very important one to follow!
Beware: In C++, your friends can see your privates!
See here and here.
- Space Rogue
funny shit
That's right. All your base.
Wasn't there some guy a year or so ago who made a map of all the critical infrastructure points in the U.S.A.?
I think he said there were less than a half dozen easily identified, poorly protected sites that you could blow up with fairly small explosives and totally trash the data and power grids. After all, the only way to be certain that data flow stops is to destroy the physical conduit, right?
If someone managed to even partially pull that off it would be both horrible and fascinating.
Perhaps this might be a good time to encourage everyone to move over to IPV6.
Does it go on forever?
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.
When I read this I had to laugh. It's an entire technical article on a "vuln" that has been known since the bsd4.4 days. Predictable ISN's are bad...enter windows. Tcp/ip stacks are not created equally, this is how nmap fingerprinting and p0f passive fingerprinting work. Anyone who has read tcp/ip illustrated by richard stevens would also be aware of this, btw that author is dead. If all the core internet routers were windows boxes this would be a big issue and the internet would have been DDoS'ed into extinction years ago. I would think that cisco routers ISN's aren't nearly that bad and in any case it's no where near as bad as the doomsayer(s) claim.
:(){
Maybe I missed something in the advisory, but this sounds like a good old TCP reset attack.....which is neither a new or novel concept. People have been doing this for ages with a sniffer and a packet generator.
Stars in the spiral arms of the Milky Way are spontaneously collapsing in on themselves, but we needn't worry because the Earth is not a star. SLEEP EASY PLANET EARTH FOR YOU HAVE NOTHING TO FEAR!
Please enlighten us as to how you connect to the magical world of the internet oh wise sage.
How practical is it to carry out an exploit based on this? From the way I read it, it seems you would have to guess a sequence number. There are 2^32 of them, so chances are you'll miss. Or am I not getting this right and can you simply sniff the packets, know what sequence number goes next, then use that?
Please correct me if I got my facts wrong.
I'm wondering if this issue will be used to further push IPv6? I assume this vulnerability isn't a problem with v6, but I continue to believe that until we control the spam problem, the additional IP space available under IPv6 will make the spam issue a zillion times worse.
In any case, you know how most of the agencies in the states deal with these problems. They ignore the warnings, wait for a "blackout", then award a multimillion dollar feasibility study to Halliburton. I can hardly wait.
From the article:
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.
I can also successfully steal your identitiy, if I know your full name, address, phone number (with area code), date of birth and social security number.
FLR
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.
It is indeed a problem with TCP but, it is in no way new. Many people have relied on this "vulnerabillity" for years. This is the technique that many firewalls implement in order to terminate undesirable sessions.
This vulnerabillity impacts the applications that are unable to handle session interruptions. BGP is such an appilication but, its impact on BGP is critical because this attack could seriously impeed BGP and since the internet backbone relies on BGP such an attack could covceivably shut down the internet. This is a known vulnerabillity in BGP, as you said, and it is surprising to me that BGP has not been modified to prevent this from happening.
By and large most applications will be able to deal with this and only minor annoyances such as DoS will occur.
As for earlier posts about OpenBSD being immune, I am very eager to hear how that is possible. No matter what the implementation, it is still possible to reset TCP sessions. This means that OpenBSD is still potentially vulnerable to DoS attacks.
Provided that BGP is modified to make it more fault tolerant, I can't see this problem with TCP being anything more than a short-lived niusance. I'm sure however that many people will try to use this as leverage to force IPv6 migration however, I believe that it too is vulnerable.
Too bad for you losers who use this TCP thing... you should be smart and use AOL, like me!
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!
Two routers on a border can control themselves enough to prevent these types of attacks. Each router would make sure they accept BGP packets for another router from only the interface connected to the other router. It would also preven inbound packets for the shared network (between routers) from entering the router on any other interface. In public peering topologies, all routers would need to make sure there's proper filtering for each and every peer session.
It's alot of work to do (if it's not done already), but that's why they pay high-end network engineer the big bucks. ISPs learned long ago to add filters to BGP sessions to avoid bad data from being passed nto one's network from a rogue ISP.
-ez
But would the black hats really do something to take down the whole net? They might have to leave their parents' basements and find something else to do until it's back up.
Right is wrong when left is right.
Certain Defcon regulars have known about this since 1998 or so. They were considerate enough to not release the information, but the release will hopefully spur the rapid deployment of IPsec.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
I read the paper, which is nothing more than a rehash of what every security person already knows about: tcp sequence guessing.
.02c
This issue erupted on the freebsd irc chat, and I had to kill it by posting this linkage: http://lcamtuf.coredump.cx/newtcp/
As you can see TCP sequncing is fairly random in most of the IP/TCP stacks out there in commercial use. The reasearch paper mentioned in the article only applies to the OS's in the above link that dont' have near true 32bit randomness.
The feasability of overcoming realtime 32 sequence guessing is insane, however non-zero. just my
It isn't a lie if you belive it.
http://www.freenshosting.net/niscc
US-CERT Technical Cyber Security Alert TA04-111A -- Vulnerabilities in TCP
.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Technical Cyber Security Alert TA04-111A archive
Vulnerabilities in TCP
Original release date: April 20, 2004
Last revised: --
Source: US-CERT
Systems Affected
* Systems that rely on persistent TCP connections, for example
routers supporting BGP
Overview
Most implementations of the Border Gateway Protocol (BGP) rely on the
Transmission Control Protocol (TCP) to maintain persistent
unauthenticated network sessions. There is a vulnerability in TCP
which allows remote attackers to terminate network sessions. Sustained
exploitation of this vulnerability could lead to a denial of service
condition; in the case of BGP systems, portions of the Internet
community may be affected. Routing operations would recover quickly
after such attacks ended.
I. Description
In 2001, the CERT Coordination Center released CA-2001-09, describing
statistical weaknesses in various TCP/IP Initial Sequence generators.
In that document (),
it was noted by Tim Newsham:
[I]f a sequence number within the receive window is known, an
attacker can inject data into the session stream or terminate the
connection. If the ISN value is known and the number of bytes sent
already sent is known, an attacker can send a simple packet to
inject data or kill the session. If these values are not known
exactly, but an attacker can guess a suitable range of values, he
can send out a number of packets with different sequence numbers in
the range until one is accepted. The attacker need not send a
packet for every sequence number, but can send packets with
sequence numbers a window-size apart. If the appropriate range of
sequence numbers is covered, one of these packets will be accepted.
The total number of packets that needs to be sent is then given by
the range to be covered divided by the fraction of the window size
that is used as an increment.
Paul Watson has performed the statistical analysis of this attack
when the ISN is not known and has pointed out that such an attack
could be viable when specifically taking into account the TCP
Window size. He has also created a proof-of-concept tool
demonstrating the practicality of the attack. The National
Infrastructure Security Co-Ordination Centre (NISCC) has published
an advisory summarizing Paul Watson's analysis in "NISCC
Vulnerability Advisory 236929," available at
Since TCP is an insecure protocol, it is possible to inject
transport-layer packets into sessions between hosts given the right
preconditions. The TCP/IP Initial Sequence Number vulnerability
(http://www.kb.cert.org/vuls/id/498440) referenced in CA-2001-09 is
one example of how an attacker could inject TCP packets into a
session. If an attacker were to send a Reset (RST) packet for
example, they would cause the TCP session between two endpoints to
terminate without any further communication.
The Border Gateway Protocol (BGP) is used to exchange routing
information for the Internet and is primarily used by Internet
Service Providers (ISPs). For detailed information about BGP and
some tips for securing it, please see Cisco System's documentation
(
or Team Cymru (). A vulnerable situation
arises due to the fact that BGP relies on long-lived persistent TCP
sessions with larger window sizes to function. When a BGP session
is disrupted, the BGP application restarts and attempts to
re-establish a connection to its peers. This may result in a brief
loss of service until the fresh routing tables are c
I am pro-lifechoice.
There is a new Internet draft addressing this issue.
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.
Of course they will. However, I'd prefer to keep it at its present pace. What's needed is some sort of DRM applied to the patches to help resist reverse-engineering, which is how binary patches lead to exploits.
Now for OSS, it's a different matter. To begin with, you theoretically have fewer vulnerabilities shown to a network, and those that are aren't intuitively obvious. It's the intuitively obvious flaws like buffer overflows that most frequently have viruses written for them.
Now, I'm looking forward to the x86 extension that allows the OS to tag a portion of memory as non-executable. But that won't help if the "arbitrary code" is placed where an interpereter will read it, instead of being placed in a main codepath.
tasks(723) drafts(105) languages(484) examples(29106)
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.
EVERYONE is going to die!
Eventually.
Note to netadmins and sysadmins: block packets with source IPs that are not valid for the interface they came from! Geesh!
This is so weird. Yesterday I was just thinking about this: what if there was a vulnerability in the TCP/IP stack itself (allbeit in Linux), that'd be pretty devastating.
/.
Now I read about this on
Creepy.
Why?
It is absolutely immune to attacks orginating outside your local network.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Gotta love the lede on that Yahoo story:
Yeah, good to see we have our priorities straight...
The dog ate my
Pssst: nobody cares.
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...
You know your world is too small when...
According to Yahoo!, there is a critical flaw in TCP that affects everyone and everything.
uh, this has been around for quite a while. Dug Song implemented a variation of this, given the ability to read traffic and then bruteforcing the next tcp window. very powerful kiddie tool.
In Aug 1998, RFC 2385 came out with protection of BGP with MD5 signatures. Using MD5 sigs will defeat this attack.
This is a well known issue with well known solutions. If the infrastructure is at risk it is because ISPs haven't been doing their job and following best practices.
-weld
There is a new vulnerability that will cause every GM vehicle and cause your children to cry. Vandals can place 1 domestic house cat into the fan and cause the fan to stop and under some cases, cause the vehicle to overheat. This was previously written off as house cats are usually soft ans squishy and have little effect on the powerful fan but Joe Shmoe PHD realised that many house cats have colars that are pretty tough for the fan to digest. Car experts say this is a serious problem and will be dealt with in a serious manner. Suggested work around is to keep your cat tied in the house, and to drive a bicycle instead.
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.
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?
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.
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
Anyone who codes (sockets) or has a better appreciation and undestanding of TCP/IP implementations will know that TCP/IP stacks vary system to system in a WIDE way. Luckily the Intarweb is comprised of many types of systems and hopefully this will only work on specific ones. Standards aren't always followed and it isn't just Microsoft but many others.
Bleh if you grok nmap you already know what I'm talking about....that is how it -works- based on the inconsistencies between systems and versions.
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.
this is typical of all hackers to own terrorist websites! arrest this man before he steals your daughter!
Besides the fact that their little kitty bones could get into the works and actually stop the fan.
I'd say this is a real threat. We need to protect our SUV's from the mobs of 1337 haxor kitten terrorists! I propose bombing __insert country here__, under the guise of giving them democracy and freedom, and simultaniously pass some laws at home which take away some of our freedom.
Huh?
Who's dumb mod troll marking it "offtopic"?
My research on the vague news note lead to the following information:
Routers using BGP (Border Gateway Protocol) use
a technique called dampening to control amount a traffic a link generates.
Details:
When a link goes up or down, updates must be passed to any router using such link. Those updates bubble up if a link goes up and down to often causing unwanted high levels of traffic. A link gets dampened when it's activity (going up or down) is ignored for the reason mentioned above.
Exploit.
A false (link up/down) update message may get a healty linked damped by a router or group of routers halting all traffic through such link.
Of course, non of the above has to do anything w/
tcp protocol but a lot with Routing Protocols which are the very foundation of the Internet.
I may be not be on the right track.
Cheers.
- these are not the droids you are looking for -
Cause I'm using TCPv6
Not all of IPX, but at least the numbering scheme felt halfway thought out: full addresses were 80 bits long, comprised of 32 bits of network address and 48 bits of node addresss, the latter almost always being the device's MAC address (which is a delicious hack for ARP tables on ethernet networks).
/24 space for IPv4.
The 48 bit node address space would make it easy to have large single-subnet LANs without dealing with multiple subnets/NAT/routing, and the network portion of the address space is as large as the entire
The rest of IPX was kind of a kludge, but I liked the numbering system.
I wonder if this is a problem caused by parasitic computing, as describe in this slashdot article: http://slashdot.org/articles/01/08/29/199205.shtml
Man, it's scary that I can remember slashdot articles from 3 years ago.
As Bill Gates would say, it's not a vulnerability; it's a feature!
On vit, on code et puis on meurt.
All those comments and none of them mention the danger of monocultures. I guess unless the monoculture is Microsoft, it doesn't count.
How many people remember the Ping Of Death?
ping -l 65542 riaa_sniffing_machine.fubar.fu
You HBT YHL HAND
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...
The amount of TCP a router talks is strictly limited to admin, and that should be isolated via /etc/hosts.allow.
Is this from our pal Steve Gibson? This smells very doom-and-gloom like it came from his campsite.
Why is it funny that the DHS is involved? (US Dept. of Homeland Security for the non-US folks) -- Maybe you were joking? It's hard to tell.
But isn't this exactly the sort of thing that the DHS *should* be involved in? Working with the folks that run the Internet backbone to try to eliminate severe vulnerabilities before they are exploited. And the scale of this one is so large and consequences so great, that having the DHS help coordinate everything is probably quite useful.
I think this is a case where the DHS are the good guys. And there's probably lots more cases that we never hear about.
Thank you Mr. Obvious.
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.
How much do you bet that all the big media companies will use the word 'Terror' at some point if they cover this story.
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
Not true at all. People have been able to do this for years with tcpkill (another) and it does not require sniffing the ISN.
Ermm... ermm .... In Soviet Russia, ermm ...
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
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.
Screwing everything up with their crappy unsecure software.
Wait--everyone's vulnerable?
How can this be? This is Slashdot: it has to be Microsoft's fault.
Suicide terrorist kitties?
Al-Kitty?
Yes, that was corny, and no, I couldn't resist.
vi ~/.emacs
Not AGAIN!
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, JanCould you please re-post that in North Korean?
Even with checksums enabled, all you are doing is reducing the probability of an undetected error. I've seen corrupted packets with valid 8-bit checksums and 16-bit CRCs. They aren't common but they do happen.
Mea navis aericumbens anguillis abundat
This is the appropriate response to the script kiddie drivel.
According to Yahoo!, there is a critical flaw in TCP that affects everyone and everything.
Only one? There are numerous flaws in TCP that are pretty notable; read just about any book on network security and you'll hear all about it.
Am I the only one tired of the line:
[someword] anyone?
No, thank you /. user 10213.
oops I mean crow alder. raven. whatever. but she is so 1337 and she'll show us all the right way to do it. maybe if we are really nice to her and tell her how cool it is that a chick knows how to use linux she will sleep with us. oh please oh please oh please!
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
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
... NOT new.
Must be nothing important happened at Yahoo, today.
help me i've cloned myself and can't remember which one I am
...that when you remove TCP/IP from a Windows box, you actually make it completely 100% safe against all Internet hackers!
Tss. Juniper is full of it. It clearly is an implementation flaw, not a specification flaw. As pointed out in an earlier post RFC-793 allows for and recommends checking ACK numbers as well as SEQ numbers when validating a RST, but apparently not many implementations do so (though they still may have other preventive measures that rules out the brute-force-RST scenario).
For example to simplify if you make a phone call to someone and get cutoff you must redial and start from where you left off in the conversation. In this situation you would have to start the conversation all over again because when a tcp connection gets reset all data that has been transferred must be resent from the beginning.
I don't know quite how to respond to this without it being taken as a flame. Here's the best I can do. If you truly want OpenBSD to succeed as an operating system on a grand scale, you're going to need to stop excusing it's weaknesses and admit those shortcomings that are obviously bad. SMP support is absolutely required for any widespread success in the enterprise, as well as the other areas mentioned in another reply to this post. You need to understand this if you want to truly have a dialogue on why someone will/won't use OpenBSD.
"A man talking sense to himself is no madder than a man talking nonsense not to himself."
And that is one of the proposed solutions:
"Reduce the TCP window size (although this could increase traffic loss and subsequent retransmission)"
I see why reducing the window size reduces exposure to this vulnerability, but I fail to see why reducing the window size increases traffic loss? Shouldn't that be the other way round?
Internet Technology Vulnerable to Hackers
This is news?
Out here who took notice that this is more or less the same old hat trick of resetting connections that has been around
SINCE THE CREATION OF TCP/IP?
*Duh*
c'mon, script kiddys have been throwing packets to reset connections for years.
Same old trick, new aplication. Yes, now we all have the ability to throw a good fingerpoint at a vendor or two and say shame on them, and make some great BSD-is-safe-again! remarks.
Moving right along...The only people 'vulnerable' to this are people who don't configure routers/firewalls or BGP's properly to use hashing, or no-brainer spoof blocking at the forefront, etc.
And guess what that means? They should have paid closer attention in class. Darwin works in more places than just the gene pool.
My new top secret key -> C>N|KB
Also, setting up large windows is just asking for trouble. Ask Bill Gates!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
The risk was similar to Internet users "running naked through the jungle, which didn't matter until somebody released some tigers," said Paul Vixie of the Internet Systems Consortium Inc.
:)
Was the naked part necessary? I don't know about you, but it would matter to me if there were loose tigers near by, regardless if I was naked or not
Yahoo article
The risk was similar to Internet users "running naked through the jungle, which didn't matter until somebody released some tigers," said Paul Vixie of the Internet Systems Consortium Inc.
Warlord wrote about this in 2001.
e se t.txt
http://nologin.org/Downloads/Papers/tcp-brute-r
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
... be self defeating, a form of cyber suicide? If you had more than one person or group doing it, and some core routers starting misdirecting or dropping, that in turn would mean the injected code from the next group of exploiters might not have a chance to get through to the target router. What would be a critical number to be effected before serious degradation occurred, enough to the point that further exploits couldn't even start to be implemented? /me obvious don't know much, but still wondering
OpenBSD works great for me as a router, webserver, and mail server. Admittedly, I'm not running a huge corporate network here.
If it doesn't work for you, either use what does, or change it so it works. OpenBSD is just a tool, you should use the right one for the job.
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
From the advisory:
We told you not to deploy NAT because (among other reasons) it would break IPsec authenticated header (AH) mode. You did it anyway and told us we were pedantic academic pinheads.
You deserve what you get.
--
jhw
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)....
unfortunately zebra doesn't support MD5 on BGP. Now what? 'upgrade' to cisco?
AC
Posted from fe80::20a:95ff:fe78:97b8
I am not an "OpenBSD zelot"; I use OpenBSD on a few servers and hence am subscribed to the misc@ list. This was recently discussed so I thought I'd fill the poster in.
All of the software you mention, while important, isn't what's used on a majority of systems (and more importantly isn't what the developers use their systems for). Many many more systems operate web servers, routers, file servers, and mail servers: general work horse stuff. That's what OpenBSD likes to focus on (because that's what the developers use it for). Hence SMP isn't a huge priority. Most of the developers don't work on OpenBSD for a living; they just code to solve there own problems (which by necessity are in the domain of what they use the software for). If this happens to solve your problem too that's great; if it doesn't well you do have the code.
Furthermore, all of the software you mentioned is corner case, no where near common. How many bank computers and render farms are there compared to the number of web servers, mail servers, and routers?
As for databases, most databases are more in need of RAM and fast disks then CPU. Those that are CPU hogs are often poorly designed. For those that actually do need multiple CPUs, let me remind you that there is no such thing as an all-in-one-solves-every-problem-every-time tool: you proably don't want to use OpenBSD for that anyway.
None of this changes my claim that SMP is a (useful) hack to squeeze more performance out of today's technology for those who just can't wait (and are willing to pay through the nose).
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
I was wondering why 1/232 was touted as being super-unlikely. 1 in 2^32 is a lot less likely... :)
In practice, these attacks are quite tricky to perform, because they require good timing and quite a bit of skills
Well, they require a packet with the right sequence number to hit in the right time period.
Since there's a window of accepted sequence numbers, it really only requires a shitload of packets with likely numbers. Send enough good guesses and one will hit at the right time.
Like a race exploit, I don't think this requires 'good timing', I think it requires enough attempts to reduce the odds - many will fail, but one may succeed.
Code or be coded.
Actually, just a cursory examination of TFA shows that it's from Yahoo!'s Associated Press feed; I doubt if Yahoo! has an opinion on the matter. I'm sure a lot of folks will wind up reading the same article in the business section of their newspaper, or via Google News, or wherever they might read Associated Press articles.
I'm not flaming you specifically (the mis-attribution was in the article summary, after all), but Slashdot in general tends to be incredibly sloppy in getting attributions correct.
> If you truly want OpenBSD to succeed as an operating system on a grand scale,
I could care less and so could the developers. I hate to sound harsh but: "It works for me!" That's all I really care about. Whether or not you or anyone else uses the same OS as I do, doesn't really matter. I suggest you use what works and does the job need it to.
>those shortcomings that are obviously bad
How is not having SMP "obviously bad"? SMP complicates the kernel code path and introduces entire catagories of bugs, and exploits that just weren't there before. All of this, just to support a few special cases where you do actually need more CPU power on the same box (as opposed to more RAM, faster disks, a better designed program, etc).
Think about what you are saying for a minute: "I like how secure and stable and well documented this operating system is. It's so great! But I want to have these features that this other not so secure, stable, and well documented system has!"
OpenBSD isn't feature focused, it's focused on security, stability, and open licensing. The reason OpenBSD has the security and stability it does is because the developers focused on that instead of adding more buggy features. Furthermore when they do add features, they add stuff that helps them: e.g. IP source tracking in the firewall, BGP protocal, redundancy and failover support, etc. In my mind having this sort of stuff is far more important then SMP.
>You need to understand this...
No, I need to have a system that works and doesn't cause me any hassle. If OpenBSD isn't the tool for your job; use a different tool. You arn't going to hurt anyone's feelings.
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
Do you have the numbers? I don't...
Not only are there many of CPU-intensive machines in banks, the firms tend to pay a lot of money for them. It is, admittedly, a different market, but there are good reasons Crays, SunFires, and mere (and affordable) dual Intels and AMDs exist.
(I doubt, this is your claim, BTW :-) The entire concept of computer can be thought of as a "hack". I think, SMP is a perfectly legitimate direction of scaling -- sideways instead of upward. It is no more "hackish" than various new(er) buses, storage, memory implementations, and periferals.
Yes, the "classic" computers had one processor (hence the term Central PU), but it does not mean any derivations from that are hacks. Certainly, invention of keyboards (instead of switchboards), silicone chips (for processors and for memory), magnetic tapes and disks, are not "hacks", are they?
In Soviet Washington the swamp drains you.
Little Timmy has only just gotten over the Garbage_Grinder Feline_Overflow vulnerability. Perhaps my husband could have waited till after bed time to try the work around but we weren't told it was model specific. Damn these generic grinders.
It doesn't have SMP. But you know what it does have? Support for lots of crypto hardware! Lots and lots more than even Linux has. And that means SMP is not always so "obviously bad" after all. That and the fact that the majority of servers on the 'net are not SMP.
Really what these discussions are about is how someone thinks their needs are more important than everyone else's. That's why the flamewars never end. Cause nobody wants to admit their opinion isn't the valid one (cause there isn't one all-encompassing 100% valid opinion).
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'
Yep, sure, however, if you flood the network with your packets, it will be probably noticed soon. Also in order to flood the network, you need a fast connection to the attacked host, reducing the problem to the immediate neighborhood of the attacked host. That's why this attack is not very practical to perform and the impact on most normal mortals is low (except for the BGP issue, which could take out your upstream router)
The problem with BGP, which is mentioned in the original article, is that it has a particularly bad failure mode - when a BGP session goes down, it is very expensive to restart it. To top it off, BGP uses very long transmission windows (because it transfers lot of data and that is more efficient with longer windows) and that makes it easier to squeeze-in the spoofed packet. This is quite messy affair, when it happens.
However, if somebody attacks your favorite web site in this way, I doubt that you are even going to notice it, since http sessions are stateless and comparably cheap to establish.
So, I think this is just a big scare for nothing, it is mainly BGP issue for now. It affects just people who know how to fix it (and are fixing it right now) and the machines involved are relatively few. Unlike some Windows RPC exploit which unleashed a massive world-wide worm in few minutes.
Gentoo Stage 1 installs....
Really... I'm not trolling... I have a gentoo distcc build spread across 3 machines (one of which is SMP) building qt, KDE, openoffice.org, etc right now
Appletalk all the way baby. :-P
Uh... does this mean that it's not a bug, it's a feature?
Please. Let's make Bill happy.
This issue erupted on the freebsd irc chat, and I had to kill it by posting this linkage: http://lcamtuf.coredump.cx/newtcp/
.02c
If you really killed a discussion by posting that link it's a shame because that link isn't discussing the issue at hand.
The link you posted is about the randomness of actual sequence numbers. The exploit at hand is about the ability to the TCP protocol to accept a RANGE of sequence numbers and the ability to increase this range via forged packets.
When this exploit is working it doesn't matter how random your sequence numbers are. The exploit allows the entire range of acceptible windows to be searched in short order.
The feasability of overcoming realtime 32 sequence guessing is insane, however non-zero. just my
Please save your two cents and read some of the better informed posts here by people who understand the issue much better than I.
Life is too short to proofread.
Time flies like an arrow, fruit flies like a banana.
So regarding this specific attack, here is a quote from the paper about TCP sequence numbers:
...
a good TCP sequence number generator implementation currently provides enough security to protect against spoofing attacks, at least for the present time and in typical conditions. But increasing bandwidth and processor speed will eventually make brute force guessing of 32-bit ISNs feasible for the average attacker.
If you are using large windows in long lived TCP connections (BGP?) you have made a brute force denial of service (not insertion) a good bit easier for the attacker. Exactly how much easier depends on how large the window is set and how fat the network pipe is to the target system.
In the case of BGP, these servers are often configured with large windows, and have significant bandwidth: ripe for DoS'ing.
If only ISP's were required to do egress filtering
Worked for the 1st tier ISP, over 4 years ago. At that time it was generally understood that TCP traffic between two BGP peers can be compromised and must be protected by whatever means possible. We've used all the secure options available on cisco (if I remember correctly, that inclued MD5 signature).
(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.
"Al-Kitty?"
You're not mangling your Arabic-to-English transilteration enough. It would probably look more like "al Qiddy"
Wouldn't it become POP4?
- It's not the Macs I hate. It's Digg users. -
I'll agree that those systems exist for a reason, but there are cost with supporting them; and most systems sold are still UP.
There is only so much developer time in the day. There are other OSes that support SMP. Having OpenBSD support SMP, while it would be nice, isn't top priority because most of the developers and users don't need it and don't care. If it's that important to you, spend some of your money and pay one of the developers to work on it, or at least donate some hardware to inspire them.
I'd rather see more stuff like pf, BGP, CARP, W^X, and propolice then SMP.
>I doubt, this is your claim, BTW
Others have made it before; I didn't originate it; but in this context it was my base claim.
>SMP is a perfectly legitimate direction of scaling
I'll agree, but many of the people who use it just think they need it. Typically programs are more bound by memory bandwidth, network bandwidth, and disk speed.
As for the "hack" comment, SMP was hacked on to the i386 line of processors to squeeze extra performance out, it wasn't designed in like it was for other systems. Newer buses, storage, etc. all were added on as extensions, none of them required what basically amounts to a re-write of the entire OS, and a reworking of the underlying hardware. (although if you sum up all of those changes, then I guess the OS did almost get re-writen and the hardware changed compleately....)
BTW, what's with the SIG?
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
The discoverer of the practicability of the RST attack was Paul A. Watson ..
The re-discoverer rather - clicky clicky
Is that a half to the power of thirty two or the inverse of two to the power of thirty two?
Look out!
+1, Ominous
As most tech-savvy trade-rag readers will already know, some comments placed into article text represent the actual thoughts and need/desire for clarification on the part of the editors [N.B. "tech-savvy" can be perceived to be pejorative by those to whom the attribution cannot be described as being accurate, nor even of the same order - Ed.]
In light of this fact, I find it mildly amusing to see Ed Hall (nom de plume?-Ed.) sign this condemnation of attribution by editors as if he were an editor himself.
If intentional, that's a fine turn of phrase, and an excellent example of the kettle calling the pot black - nice job! <8^)
Redundancy is good; triple redundancy is twice as good! - Me.
Banyan Vines is making a comeback!
If I wrote for the auto industry and intentionally tried to scare the shit out of people Detroit would sue me off the map.
;).
Sue you off the map? Hell no, we'll just beat the crap out of you
Routers don't usually do a lot of TCP themselves, except SSH or telnet access for management, but the one big exception is the BGP protocol that routers use to connect to each other, primarily at the interfaces between carriers. The BGP sessions stay up for a long time, and killing them tells the router that it's no longer talking to its neighbor so it should go find a different route to get to that network, which is really really annoying. On the other hand, BGP has options to do more checking on BGP messages before accepting them, and carriers that do spoof-proofing to prevent their customers from forging packets have less risk, and carriers that block packets addressed to their routers accept from approved destinations are much safer.
Some customer connections to ISPs use BGP, especially if the customer uses multiple ISPs, though most are static - these could be subject to spoofing by somebody inside the customer's network, if they're not careful. (The customer could be an ISP, or they could be a regular customer with an employee who has next month's interesting virus.) So customers who don't want to get thrown off the net should probably be careful to do good firewalls to keep their own users from spoofing their connections.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
...major vendors confirmed yesterday that sending lots and lots of packets to a port could make that port unable to handle legitimate traffic! This is a critical vulnerability in every device, connection, and OS in use today!
/*Really, this is a very juvenile attack and doesn't reqire a PH.D to come up with. In fact you don't even really have to understand much networking at all to get this.
Ono!!
STOP THE FUD*/
does anyone else ever want to shoot all of those people who post some ass-hat comment and then say "I couldn't resist' and then tell them I couldn't resist?
no, it is two to the power of negative thirty two
It doesn't matter - they are equivalent.
What a long, strange trip it's been.
Reading through the comments, the scariest thing about this thread isn't the original article...
It's the comments posted by a fairly experienced bunch of geeks.
The misconceptions illustrated throughout this thread demonstrate how badly some aspects of the Internet, TCP and protocols are misunderstood by people who think they have a full working knowledge of these mechanisms. (Some posts...Other posts admittedly correct some errors)
It's because of these people who *think* they know what's going on while working in the industry that the true risk grows, because hostile hackers will always find a home in the huge gaps left by their ignorance.
Ignorance is more dangerous in the long run than apathy. Apathy can change.
Apologies that this post is slightly OT, but it's relevant to the theme.
GrpA
Enjoy science fiction? "Turing Evolved" - AI, Mecha, Androids and rail-gun battles. What more could you want?
Cats may be soft and squishy but one of the little bastards tore up a radiator, bent the fan and broke the water pump shaft on my car. The best part was cutting what was left of it out of the twisted mess of belts.
IANAE
That would be funny, yes. However, I've been signing posts/email/whatever with "-Ed" for longer than many slashdotters have been alive. I even sign handwritten letters that way. The time to start to worry is if I change it to add a period at the end...
Oh der... I can see that. /Slaps self.
Look out!
Quit thinking OBSD as something to replace the current enterprise OS. OBSD focuses on issues that many systems aren't as focused on. It works great for firewalls, and anything that you don't want someone to break into.
If you want to have SMP capability, and yet the security when you hook up that box on the Internet, perhaps you should consider use a smaller box with OBSD as a firewall for the SMP machine running something else, perhaps Linux or FreeBSD.
On the sidenote, I dislike the sentiment that people introduce buggy features - developeers want a feature to be implemented, but yet, we're all human and anything new are prone to bugs. It's not like OBSD developement team are perfect angels, they do make mistakes here and there, but due to their focus, OBSD has become much more secure and much more specialized towards that.
There is a simple solution - just use pair of any NON public IP addresses on both sides of BGP links. This addresses are not published (not propogated via BGP itself) and nobody is able to send packets to it besides BGP peer partener. Problem exists only for stupid IS staff.
From my daily reading it looked like the recent mailing regarding the Rose attack Which could affect nearly as many systems as this TCP vulnerability. With two vulnerabilities of this extent, and their relative quiet reception by the security community I don't think there will be much of a push to fix this problem, while the k1dd13s go to work acquiring proof of concepts.
omigod they completely overlooked the simplest of hacks, freezing the kitten first.
Nope.
And putting Al-Kitty through said fan will result in Al-Gore.
Yes, the impact quite definitely depends on the protocol.
... so it may not actually require a 'flood of packets', necessarily, perhaps just a bucket brigade, moving it into the realm of practicality (depending on protocol).
... but now I'm wondering if this is what was referred to.
As far as flooding the network with packets, the point of it is that the fact that you don't need to hit a specific sequence number, you just need one within the window
I vaguely remember reading something somewhere by one of the guys you'd always find stuff by, in security related searches (aleph1 or daemon9, I think, but my memory on this point is failing me) that said something to the effect that 'there's a condition that affects a routing protocol that could take down chunks of the net pretty quickly', I ran across this years ago, and I'm paraphrasing it
Code or be coded.
The local cell here in the states is known as Al Qitten.
I think 1/232 should read 1/2^32, the exponent must have been stripped somehow.
My appologies, I now see that someone else posted this before me.
What really makes this flaw interesting is the fact that the guy who apparently discovered it said he could do it in four tries or so. FOUR??? What kind of session could he possibly be jumping in on, and what was his test setup? I am hesitant to believe this guy had a couple concrete examples of this bug outside of a test environment.
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?
Just you then..?
...and he grinned, like a fox eating shit out of a wire brush.
No, everyone is not vulnerable to the recently published vulnerability in the TCP protocol that allows to shut down BGP routers. Because Cisco hardware is, stupid writers yell that the whole internet is vulnerable. Come on, Cisco is not the internet.
:
:
As stated by Theo de Raadt and Henning Brauer, OpenBSD is not vulnerable because (quoting Henning)
Even without TCP MD5, bgpd on OpenBSD is not affected, because: - we use random emphereal ports - we do not use insanely hughe window sizes as Cisco does - we require the RST sequence number to be right on the edge of the window
(quoting Theo)
That is right. If you have a Cisco, you can tear down BGP sessions by
spoofing:
64K of
SYN's or RST's sent to #.#.#.#:179 -> #.#.#.#:{1024,+512,+512,...}
The SYN and RST methods are different, but the end effect is that
a tiny little burst of packets will cause a flap.
OpenBSD (and I am sure other systems too) have for some time contained
partial countermeasures against these things.
OpenBSD has one other thing. The target port numbers have been random
for quite some time. Instead of the Unix/Windows way of
1024,1025,1026,... adding 1 to the port number each time a new local
socket is established... we have been doing random for quite some
time. That means a random selection between 1024 and 49151. This
makes both these attacks 48,000 times harder; unless you already know
the remote port number in question, you must now send 48,000 more
packets to effect a change.
We've made a few post-3.5 changes of our own, since we are
uncomfortable with the ACK-storm potention of the solutions being
proposed by the UK and Cisco people; in-the window SYN or RST's cause
ACK replies which are rate limited.
It will have the most impact on vendors who do BGP over poor TCP
stacks. In particular, Cisco.
Cisco has not been teaching engineers to block SYN's coming in; they
have only been teaching them to block SYN-ACK's from going out in
return. And... well, you'll see.
{{.sig}}
Well, they were also supposed to have Rightside PU, Leftside PU and in more advanced configurations Front and Back PUs. Topside and Bottomside PUs was considered but were found impractical as interfering with cooling.
It's called IPSEC, it's secure on the IP level up so TCP is encrypted over it. :)
Correct, for suitable levels of 'secure'. Schneier and Ferguson's evaluation of IPSec. It's no panacea... But nothing is
The best defence against this? Simply check for a stream of RST packets. They dont come in huge bundles with incrementing sequence numbers often. Detect that signature, block IP, sorted.
What would your preferred way of implementing this defence be? Is it easy to automate on linux (firewalls?)?
Posters recognized by their sig,
My translation program must be off ...
P. Diddy is a terroist?
It is intended to remind some more liberal-minded readers (and moderators), that merely labeling someone with a "neo-con" tag is not qualified as grounds for totally dismissing the person's opinion(s) :-)
In Soviet Washington the swamp drains you.
And if you do it in a repeating pattern you get an Al-Gore-Rhythm.
You're probably correct, proven in the lab and proven in the wild are two totally different things.
Despite myths to the contrary, IPv6 users don't have to have IPSec turned on all the time, even if it's technically mandated for IPv6 implementations.
Well, they require a packet with the right sequence number to hit in the right time period.
Since there's a window of accepted sequence numbers, it really only requires a shitload of packets with likely numbers. Send enough good guesses and one will hit at the right time.
Like a race exploit, I don't think this requires 'good timing', I think it requires enough attempts to reduce the odds - many will fail, but one may succeed.
It also requires knowledge of the source and destination port and IP address of the connection you want to attack (which usually means you have to be able to eavesdrop on the traffic - not something your average script kiddy on ADSL can do), and the ability to spoof source IP and port (and I can only hope that most ISPs today have enough clue to drop those packets).
So it is more in the league of 'cat might get stuck in the radiator of your SUV causing the engine to overheat and jam causing loss of steering and crashing into a tree' than 'the sky is falling'.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
PEBKAC. Whoops, I mean PEMDAS.
Parentheses, exponentiation, multiplication,
division, addition, subtraction.
Ben "You have your mind on computers, it seems."
Fortunately there are not groups of idiots who run around trying to put cats under the hoods of cars. There are, unfortunately, groups of idiots who think it's a great idea to crash as many computers as possible.
This amazes me that this actially made it this far. Yes if someone calls your car insurance company, tells them your name, address, phone numer, and socal security humber, they could have your policy changed or even dropped...
duh
> TCP ports are known
this is a real threat, but keep in mind that the client port is random in almost all applications.
--Brian
TCP MD5 Authentication for BGP should help cut down the chances at an attacker can reset a BGP connection.
--Brian
Actual text from an Economist science article on the Schroedinger cat-in-the-box experiment from around 1990,as best I can recall it:
"The only reason that countless milliions of cats have not been sacrificed on the altar of science is that actually doing the experiment would prove nothing..."
"The future's good and the present is nothing to sneeze at." - Roblimo's last
Exactly, they not only have to guess a sequential number within the window, but guess the client source port as well. Even if they do manage to send enough packets to RST the connection, most applications will simply reconnect.
Or have you run off of the road on the way back from the club... ;)
Something was published on the news aggregate www.dilby.com about this TCP Vulnerability. Dilby is my homepage because it provides the latest news story and I refreshed my homepage and an article appeared about it at the top in red, bold text.
When you clicked it, it expose lines of code. I kept refreshing and it continued to grow and grow. Ten minutes later, the link was removed and I forgot to copy and paste, but oh well.
It was at dilby.com NEWS AGENCY.
Lata,
BOB
IT Specialist
How the hell can this be modded as over rated? It was never rated to begin with outside of idiot moderators rating it over rated. Perhaps flamebait would have been the appropriate choice.
If we don't make light of everything, we are just stumbling in the dark - Blank