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.
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
How can we blame this on Microsoft?
pssst, hey mods - it's a joke....
Yep, that's the issue. I submitted too, but :(.
Anyway, the way I read it you basically run the TCP attack against a BGP peering router, causing it to drop one or more of it's peering relationships. Do that enough and you can cause the routes being advertised by that router (and also TO that router from the peering connections you're breaking) to be 'dampened' - a protective mechanism in BGP to prevent a flapping route from making all the peers recalculate their routes nonstop.
It's kind of like one peer putting the other one's routes in "time-out" until he plays nice.
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.
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...
Winston Zeddemore: Tell him about the Twinky.
-G
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
Well, that means our home PCs aren't likely to get exploited by this. However, if our ISP's router gets exploited, we're knocked offline and our PC isn't as useful as it used to be.
The threat here is a DOS aimed at a few things that we don't want to see go down.
... 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'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.
While you may not use BGP directly, your ISP almost certainly does, and probably their ISP too. It's also used in the Internet core for communication between ISPs. The reason a problem with BGP is a big deal is that it can drastically affect entire ISPs, essentially knocking them offline until their routers are upgraded.
My Web Page
The article is being presented at CanSecWest, and is called "Slipping in the Window" by Paul A. Watson. I have two friends at CanSecWest, I've asked them to attend and report back what the feeling is.
NANOG members are talking about it, and several regional Tier-1 players have already issued customer notifications.
This exploit goes up against TCP connections that have been established for long periods of time. i.e. not web connections. The most prevalent would be BGP peer connections, which can be up for days on end easily. Without having read details, or the paper itself, by forging packets of BGP peers with adjusted window sizes, you can cause a router to reset (possibly hang, depending on IOS or JunoOS version, not sure about this) it's BGP peer connection. If you were doing eBGP and had your own AS, a directed attack against your gateway routers could force flapping, which would cause route dampening, and lead to denial of service.
What you need to do, is contact your ISP if you are an enterprise network admin, and establish MD5 authentication on your BGP sessions. Check with Cisco or Juniper and find out if your code will drop non-MD5 BGP packets directed at it. An ACL won't do, the attacker would forge the src-ip of a known peer.
This is a completely non-trivial attack to coordinate. You need to know the IP address of the BGP peer of a customer, or the route reflector, and then get the IP address right in an attempt to bypass ACLs and get the BGP session to hang. eBGP multihop means that IP could be any number of routers, and unless you have inside info, you don't know what it is.
Potentially, looking glasses could be used to mount attacks at NAPs or other peering points, but again, I think the major players will be ready for it very shortly, and will spend most of today (if they are any good) coordinating with legal teams to slam the shit out of any forged sessions they see, and start cooperating to run traces with other providers.
If I could editorialize one moment, none of this would be an issue if providers took better care to implement anti-spoofing techniques. Forged src-ip addresses are the bane of security. Most of these attacks don't care about 2-way communcations, they just want to reset connections. Spoofed src-ip lets them do that. Rant off.
O.k so how will this affect anyone other than major ISP's that can really do anything about it?
So I guess it wouldn't affect anyone at all if it a couple backbones that depend on BGP to get packets from point A to point B just dropped off the Internet.
Nope, that won't affect anyone at all.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
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.
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
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
Real quote.
God Bless America. Why? Did it sneeze?
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.
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.
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.
What is new here is that you don't have to know the completely specified sequence number, but only something close enough to fit within a window. This reduces the search space and makes the attack more pragmatic.
See here and here.
- Space Rogue
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.
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.
BGP depends on IBGP (internal) as well in-between ASes (external). That means you could attack IBGP as long as it had a public IP, or if you had a route to it.
Some BGP sessions would come back up automagically (some might require a manual reset (in Cisco IOS this is known as "clear ip bgp "). However, the attack could just bring them down again (every 4 minutes). BGP dampening would take effect depending on how it is configured upstream or downstream of your router(s). This would cause parts of the Internet to stay down for a long time (at least hours). Attackers could then concentrate on other targets during that time.
OSPF and BGP are not comparable. They work together. Often, BGP requires OSPF (for building a table of valid next-hops) -- but once BGP is used -- there is generally no replacement for it. OSPF would carry routes from router addresses (point-to-point links), and BGP would carry customer and ISP routes. BGP on the Internet carries the necessary 130k routes to allow the Internet to work. OSPF can only carry about 10k routes, and it hurts to even do that. IOW, OSPF does not scale to large networks such as the Internet, but BGP does.
There are many workarounds to this problem, most are identified in the advisory. People who lag behind the times could get hit [hard?] with this vulnerability, so it's always good to check and make sure your network is up to spec.
IPv4 allocations for hobbyists? join the ipalloc-l mailing-list! www.operations.net/mailman/listinfo/ipalloc-l
The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set.
The packets need to have source and destination IP addresses that match the established connection as well as the same source and destination TCP ports.
The fact that TCP sessions can be reset by sending suitable RST and SYN packets is a design feature of TCP according to RFC 793, but a reset attack is only possible at all because the source IP address and TCP port can be forged or "spoofed".
Although denial of service using crafted TCP packets is a well known weakness of TCP, until recently it was believed that a successful denial of service attack was not achievable in practice. The reason for this is that the receiving TCP implementation checks the sequence number of the RST or SYN packet, which is a 32 bit number, giving a probability of 1/232 of guessing the sequence number correctly (assuming a random distribution).
The discoverer of the practicability of the RST attack was Paul A. Watson, who describes his research in his paper "Slipping In The Window: TCP Reset Attacks", presented at the CanSecWest 2004 conference. He noticed that the probability of guessing an acceptable sequence number is much higher than 1/232 because the receiving TCP implementation will accept any sequence number in a certain range (or "window") of the expected sequence number. The window makes TCP reset attacks practicable.
Any application protocol which relies on long term TCP connections and for which the source and destination IP addresses and TCP ports are known or can be easily guessed will be vulnerable to at least denial of service attacks
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
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.
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!
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.
There is a new Internet draft addressing this issue.
He made a sweeping claim that he "took the initiative in creating the Internet" that was clearly intended to be taken as it was, and just as clearly intended to be deniable if called on it.
It's not a "myth" that he did this, nor anything to be proud of, if you're a Gore-ite ... I notice Gore-ites sure get uncomfortable about it.
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.
Note to netadmins and sysadmins: block packets with source IPs that are not valid for the interface they came from! Geesh!
iBGP is vulnerable to this as well, and very few of the networks I've worked on went to this level of filtering on their internal peering, just their external.
/16 drops out of your internal tables, just through knocking out an iBGP peer - never having had to touch the edge router. The route falls out of the edge router's table, and so he stops advertising it.
Find a large network, determine it's topology, hope they're using iBGP for announcing the routes internally to the edge peering routers. Then it's a matter of finding which one to disrupt. Find the right one and a
Wait. Let it come back. Route gets advertised to external peer again.
Repeat 3-4 times until the route is dampened by your victim's peers. Repeat 3-4 more times to get the default maximum 60 minute time-out.
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...
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)
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.
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?
> But if I understood it correctly, you can only
> OSPF inside your own AS. Doesn't that mean, that
> OSPF could never be considered a replacement for
BGP?
BGP is "an" exterior routing protocol, tho its more accurate to say that BGP is "the" exterior routing protocol
OSPF won't scale anywhere near what is needed for the internet. The BGP routing tables have O(100000) routes, and those are summarized to hell and back.
OSFP would so quickly fill up with external routes that your router would fall over quicker than a teenager at spring break.
Norman Cook's Ode to Sl
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 -
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.
Gore took the initiative in creating the Internet by taking the initiative to support the legislation required to get it going.
And just how, exactly, did he do that? He wasn't even in Congress at that time. IIRC he was in college, or high school, or something.
nothing in his statement could be properly construed to imply such
Look it up. He clearly implied that he was present at the creation of the Internet, and actively made it happen -- which is clearly a falsehood.
Yes, he apparently DID do some things to help the Internet while in Congress -- for which he deserves credit -- but the Internet already existed; he sure as hell didn't 'invent' it.
And it has nothing to do with which team (Bush v. Gore) you were rooting for. Everyone SHOULD be able to rationally sort out the facts regardless of ideology. Of course, the Gore people still have trouble being rational, but that's another thread....
In times of universal deceit, telling the truth gets you modded -1 Troll
Guessing a port and IP is fairly easy. Guessing the sequence number is not. This is why making sure that TCP initial sequence numbers are random is important.
This is old news.
For the insanely paranoid use a hardware entropy generator (TRNG) for choosing ISN's.
There are all sorts of attacks against network protocols when poor random number sources are used. This is but one example...
Newt Gingrich, 9/1/00:Gore is the person who, in the Congress, most systematically worked to make sure that we got to an Internet.
Al Gore and the Internet
By Robert Kahn and Vinton Cerf
Al Gore was the first political leader to recognize the importance of the Internet and to promote and support its development.
No one person or even small group of persons exclusively "invented" the Internet. It is the result of many years of ongoing collaboration among people in government and the university community. But as the two people who designed the basic architecture and the core protocols that make the Internet work, we would like to acknowledge VP Gore's contributions as a Congressman, Senator and as Vice President. No other elected official, to our knowledge, has made a greater contribution over a longer period of time.
Last year the Vice President made a straightforward statement on his role. He said: "During my service in the United States Congress I took the initiative in creating the Internet." We don't think, as some people have argued, that Gore intended to claim he "invented" the Internet. Moreover, there is no question in our minds that while serving as Senator, Gore's initiatives had a significant and beneficial effect on the still-evolving Internet. The fact of the matter is that Gore was talking about and promoting the Internet long before most people were listening. We feel it is timely to offer our perspective.
As far back as the 1970s Congressman Gore promoted the idea of high speed telecommunications as an engine for both economic growth and the improvement of our educational system. He was the first elected official to grasp the potential of computer communications to have a broader impact than just improving the conduct of science and scholarship. Though easily forgotten, now, at the time this was an unproven and controversial concept. Our work on the Internet started in 1973 and was based on even earlier work that took place in the mid-late 1960s. But the Internet, as we know it today, was not deployed until 1983. When the Internet was still in the early stages of its deployment, Congressman Gore provided intellectual leadership by helping create the vision of the potential benefits of high speed computing and communication. As an example, he sponsored hearings on how advanced technologies might be put to use in areas like coordinating the response of government agencies to natural disasters and other crises.
But, being blinded by ideology is so much MORE fun!
God Bless America. Why? Did it sneeze?
Title: Juniper NetScreen Advisory 58784
t ao/co ntact.html
Date: 21 April 2004
Version: 1
Impact:
A design flaw in the RFC specification of TCP may allow a blind attacker to successfully close a TCP connection.
Affected Products:
Juniper NetScreen Firewalls (all versions)
NISCC Reference: Vul/236929
http://www.uniras.gov.uk/vuls/2004/236929/tcp.htm
Max Risk: Medium
Summary:
A blind attacker with limited knowledge of a TCP connection may be able to successfully brute force the TCP Sequence number space and thereby cause a connection endpoint or firewall stateful filter to process a spoofed RST packet and close the connection.
Details:
The TCP Sequence number is one of the mechanisms that TCP uses to prevent a third party from inserting forged packets into the data-stream between two other hosts. While such an attack has always been known to be theoretically possible against TCP, it is was believed that the range of over four billion possible TCP Sequence numbers was large enough to prevent a successful attack. However, recently such an attack has been proven to be feasible in certain situations.
Specifically, if two hosts are known to talk to each other on a regular basis and/or for long periods of time over known port(s) then it may be possible for an attacker to brute force the TCP Sequence number space and successfully inject a forged packet into the connection and possibly disrupt communications. Certain connections, such as BGP4, which are long lived between two devices are especially vulnerable.
While all TCP connections are potentially vulnerable, NetScreen believes that NetScreen firewalls running BGP4 or with TCP Syn-Check enabled are likely to be vulnerable in practice. Other protocols such as SSH, HTTP and SMTP which usually have shorter connection times are less vulnerable.
Recommended Actions:
NetScreen firewall customers should do one or more of the following:
1) Configure Anti-Spoof protection as appropriate.
2) Use secure protocols such as ssh, HTTPS, BGP4 w/ MD5 Authentication
and IPSec which are more resistant to attack.
3) Limit management to dedicated and/or internal interfaces
4) Upgrade to ScreenOS 5.0r6 which enhances the stateful firewall
functionality to protect devices on the network.
Patch Availability:
ScreenOS version 5.0r6 is currently available for Juniper NetScreen firewalls.
How to get ScreenOS:
Customers with a valid product warranty or a support contract may download the software from the Juniper NetScreen CSO web portal:
http://www.juniper.net/support/
For all other customers, including those with expired support contracts, please call your regional Juniper NetScreen TAC center at one of the numbers listed in:
http://www.juniper.net/support/nscn_support/
Select option 2 from the telephone menu and be sure to select the correct product from the phone tree. Once connected with an engineer state that you are calling in regards to a Security Advisory and provide the title of this notice as evidence of your entitlement to the specified release.
As with any new software installation, NetScreen customers planning to upgrade to any version of ScreenOS should carefully read the release notes and other relevant documentation before beginning any upgrade.
Here's the original quote from a CNN interview during the 2000 campaign:
BLITZER: I want to get to some of the substance of domestic and international issues in a minute, but let's just wrap up a little bit of the politics right now.
Why should Democrats, looking at the Democratic nomination process, support you instead of Bill Bradley, a friend of yours, a former colleague in the Senate? What do you have to bring to this that he doesn't necessarily bring to this process?
GORE: Well, I will be offering -- I'll be offering my vision when my campaign begins. And it will be comprehensive and sweeping. And I hope that it will be compelling enough to draw people toward it. I feel that it will be.
But it will emerge from my dialogue with the American people. I've traveled to every part of this country during the last six years. During my service in the United States Congress, I took the initiative in creating the Internet. I took the initiative in moving forward a whole range of initiatives that have proven to be important to our country's economic growth and environmental protection, improvements in our educational system.
OK, this isn't the greatest phraseology, but the gist is that he supported the development of the Internet through legislative initiatives. If you doubt this, there's a nice summary at Seth Finkelstein's website.
Y'know, I saw this interview when it happened, and I certainly didn't come away with the impression that Al was grandstanding. (This said as an early Bradley supporter... I certainly don't agree with his implication that Bradley *didn't* produce important legislation.) I mean, it's not like he put on a flight suit and strutted around while US soldiers were getting blown to sh*t or anything.
#!
Wrong. Very wrong. Are you anaware of this field called "banking"? What about "financial trading"? These firms have huge portfolios and run and re-run various models on them. At night, the systems have to run various "end-of-day" scripts and reports, which take CPU-hours to complete. Most of this things run on Unix...
There is also on-the-fly image manipulation, and the scene-rendering done by fleets of Unix machines. The more CPUs each such Unix machine can fit, the better.
Then come databases -- depending on the queries (with joins and orderings), DB-servers can be CPU bound and appreciate multiple processors when available.
What about PVM? What was it -- and similar packages both free and commercial -- written for? What about this proverbial "beowulf clusters"? Of course, it is much better to have several CPUs inside the box, rather than in separate machines.
Until which time, the OpenBSD zealots will continue to deny the issue exists or is of any importance. I see...
In Soviet Washington the swamp drains you.
Of everyone rambling about switching to udp/icmp/ipx/whatever, few if any have mentioned that IPv6 would be a solution to this issue. IPv6 has manditory IPSec so predicting anything but where each packet is going to/comming from will be quite difficult.
:>
happy 4/20
If you read the article it'll explain it for you, but basically:
Routers from different AS's talk to each other using BGP4. This protocol uses TCP.
The "exploit" uses spoofed packets, so the router will process them as if it came from their neighbour.
So yes, while the router is mostly "shoveling packets", it learns the direction in which to shovel these packets via the exploitable method.
If you want to disagree, feel free to let all the major tier 1 ISPs who have been busily implementing MD5 authentication on their BGP sessions know their wrong.
Link here (soul reaving required).
In the article Watson is quoted as saying that any hacker can figure out this exploit in five minutes from the vaguest explanation. If that's true, why reveal the exploit until someone has figured out how to completely patch it? Or has the fix already been figured out? I couldn't tell from the article.
Suicide terrorist kitties?
Al-Kitty?
Yes, that was corny, and no, I couldn't resist.
vi ~/.emacs
Actually, this is just a variation on an old attack with sequence number guessing. Some OSes have a very poor generator for these numbers (even though the vulnerability is known for ages) and it is possible to exploit it. Probably the most famous attack of this sort was Mitnick's break-in into Shimomura's machine ten years ago.
In practice, these attacks are quite tricky to perform, because they require good timing and quite a bit of skills, so they are quite rare. It is far easier to just exploit some common buffer overflow than this.
The impact could be not only DOS (by resetting the connection), but you can do also packet injection with potential for total system compromise. However, if the protocol used is encrypted (in Shimomura's case it wasn't, if I am not mistaken, Mitnick attacked rsh or rlogin), then the DOS is probably the worst thing that could happen to you. The encryption will reject the bogus packets, if properly implemented.
So, keep calm - this was here since at least 80-ties and there isn't much that you can do against it, except to use encryption. You can only hope, that your system vendor will decide to make their TCP stack less vulnerable (not likely to happen, since many systems still ship with the crappy sequence number generator!). Full fix is not possible anyway, unless you want to break the protocol.
Regards, JanThis is sort of on topic with your post. Here's a discussion and visualizations of various OS's TCP sequence numbers:
Strange Attractors and TCP/IP Sequence Number Analysis
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
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).
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."
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
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
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
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 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)
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.
This is a good point - is this attack still possible in IPv6? If not, could this be the killer event that make the switch seem like a good idea to all the companies that have been refusing to change.
(if the hack is still possible in IP6, then I can only ask *why*??, since the basic principles of the flaw have been known for a long time)
(Spudley Strikes Again!)
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.
Please. Let's make Bill happy.
Time flies like an arrow, fruit flies like a banana.
(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"
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
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?
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?
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...
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.
And putting Al-Kitty through said fan will result in Al-Gore.
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?
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}}