A common thread with a lot of these more recent flaws is that they're firmly in the 'feature-not-a-bug' realm, i.e. the problem is down to something working exactly as intended, but that this can (potentially) lead to misuse (eg. shock - routing control protocols can be used to control routing!!).

As such there isn't really anything to fix.

Anyone have further details on this particular 'flaw' so it's more obvious if it's a design error or just something that can be abused but would never be worth changing?

Oh goody. Another infrastructure attack.

If TCP is so fragile that this exploit can push us to the brink of annihilation, and if the USA's e-conomy is so fragile that a few greedy naked short sellers can bring down Wal-Street, (heh heh now that's cute) um, Wall Street, and if Windows desktop PCs are still vulnerable to GDI exploits over a year after the fact, and if DNS is so fragile that Osama Bin Virus can impersonate whitehouse.gov, and if BGP is so weak that al-Qaeda can hijack huge amounts of network traffic...

..then it's TIME TO DISMANTLE THE INTERNET AS AN ABJECT FAILURE!!!!!!!1111oneone PERIOD!!!!!!11!!1

yup, that's all we needed

I long hoped that IP6 would replace IP4 and, with its security improvements, bring some of the exploits to stop. Of course, I might be wrong. But maybe, just maybe, IP6, being relatively "young" and not much popular (yet), even if vulnerable, might still be fixed - ie. certain features made optional or removed altogether, whilst reliance on them is not prelevant.

Is IPv6 vulnerable to this? If not, here's a big reason to migrate RSN

I guess the Big Wet Dream of a totally unregulated an anarchic internet is coming to an end.

As long as we allow users to spoof their sender addresses, we cannot lock out malicous people quickly (in case someone finds a logical flaw in TCP or something similar).

Also, on the borders to politically instable countries/regions, we need a kind of internet-toll-house, that enforces proper sender addresses. That is going to cost serious money, as we are talking about large routers doing Terabits/second of IP traffic.

"Ingress filtering" is also necessary if you want to protect an internet-based voting process from anarchists.

Let's drop TCP/IP and go back to IBM's SNA.

The annoyance of having to recalculate routing tables by hand, and rebooting almost every time an new PU or LU is linked to the network would be a minor overhead compared to the problems with TCP/IP.

"Is IPv6 vulnerable to this?"

Yo! Guys! If you remember introductory classes in networking, you know that the stack is:

Physical--->Ethernet (or something) ----> IPv4 or IPv6 ----> TCP or UDP -----> SMTP (or something)

So this has nothing to do with IPv6.

Venerable TCP has been in replacement discussion for some time now anyway, so I guess if absolutely needed, some TCP-NG will take its place.

"Lee said he and Outpost24 colleague Jack Louis discovered the bug in 2005, but decided to keep their finding secret while they tried to devise a solution. After largely hitting a wall, they decided to go public in hopes that a new infusion of ideas will finally get the problem fixed."

Hmm... call me cynical.... but I suspect they decided to go public to get a load of publicity for themselves. The truth is this 'news' story with a complete lack of any concrete facts simply serves to spread FUD. They've known about it for three years yet can't work out a solution?? Pleassse......

You do not know what this vulnerability exactly is, do you? Because, you, know, IP6 is just a new version of the same old IP protocol, with some new features added, and (just) some old features taken away. It might, or might not be susceptible to the same family of attacts. Right now, we are in the dark.

I'm guessing this is going to be like the DNS cache poisoning debacle.

Another attack which should be obvious to any security researcher with the most basic understanding of how tcp/ip stacks allocate resources and the tcp/ip protocol itself.

The only difficult part is why some researcher is able to make a name for themselves for shouting about it.

The penguin, because I want the old icon back, not some labotomised version of it. Equality for penguins damn it.

... a cunning ploy to use these threats as an excuse to re-write TCP and introduce an ID system on the net whereby all traffic is identifiable, trackable and monitored by those in power in the US and UK for the purposes of "preventing terrorism" (and other such bullshit).

;-)

... from the vague description this "attack" relies on the fact that the attacker is able to establish a proper connection? Any well written firewall policy ought to be able to detect rapid connections to a particular resource... and if you have a decent firewall, the firewall will handle the TCP handshake before handing off the connection to the internal hosts... Not really a problem if you have someone who knows what they're doing.

I was thinking along similar lines. Either firewalls or load balancers. I remember back in 1999 when I was playing with a certain breed of load balancer that they were able to protect against the SYN attacks then prevalent by detecting multiple connections in just the way as you describe and so never handed them off to the servers running behind them.

Regards

Neil

…does this have anything to do with send/receive windows and their buffers?

I strongly recommend taking the 30 mins needed to listen to the podcast interview, which goes into quite a lot of background details about how they stumbled over and then developed the attacks.

IPv6, they say, is much MORE vulnerable; presumably something to do with the larger address space requiring more memory to keep track of.

The SYN cookie connection appears to be a bit of a red herring; they are using CLIENT-SIDE SYN cookies to determine something about the status of the TCP state machine on the other end of the connection. It also apparently has to do with features concerned with packet loss, and timers - so that would be the back-off-and-retransmit, sliding window, PMTU-d and suchlike features, then, as a wild-assed guess? Oh yeah and they give a big fat clue about a particular comment in the Linux TCP stack source code...

Personally I think this will turn out to be an issue of the scale of the Kaminsky bug, rather than the somewhat underwhelming BGP issues, click-jacking and the like. Those inclined to be sceptical about the reality of the DNS vulnerability (and the potential for m4yh3m it enabled) obviously didn't try out the exploit or rack up the overtime testing and deploying patches on a live production infrastructure, like some of us did! Rather like Y2K... absence of evidence wasn't evidence of absence, it was evidence of a metric fuck-load of hard work being carried out behind the scenes.

I have a couple of concerns:

1) We have no details.

2) I can't find any corroborating discussion in places like Bugtraq. or Full Disclosure.

3) The problem (if it exists at all) sounds like one that would come from an implementational issue. Even if the DoS itself is fundamental to TCP, whether or not it is necessary to reboot to recover must be implementational.

It's worth noting that so many TCP stacks are based on the BSD Unix implementation that there have been previous problems which were implementational and yet impacted nearly all operating systems (eg, TCP sequence number prediction maybe 10 years ago).

After watching / listening / or reading to SecurityNow with Steve Gibson and Leo Laporte Episode #164 | 02 Oct 2008 | 97 min. Title (SockStress)...

It has nothing to deal with SYN Cookies.

The TCP three way handshake has already happened. Now the sender's (attacker's) end uses a TCP option called a Window. In that Window they tell the server that they (the attacker) has zero buffer space left.

They also made a video about it. This link may should work until a new Episode is recorded.

http://drop.io/twitarmybox/asset/sn-vd-164

(353 MB)

PS. At the time of this post: The transcripts are not posted yet online...