DoS attack reveals (yet another) crack in net's core

Security experts say they have discovered a flaw in a core internet protocol that can be exploited to disrupt just about any device with a broadband connection, a finding that could have profound consequences for millions of people who depend on websites, mail servers, and network infrastructure. The bug in the transmission …

[Anonymous Coward]

Flaw?

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?

[Gordon Fecyk]

Death of the net predicted -- Film at 11

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

[combatwombat]

o luverly

yup, that's all we needed

[Bronek Kozicki]

What about IP6?

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.

[Anonymous Coward]

IPv6

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

[Anonymous Coward]

Probably involves SYN Cookies

SYN Cookies were introduced to defend against SYN Attacks, they have always been a bit controversial, but in the main have done well.

A guess is someone has found a flaw there, with a similar effect to a SYN Attack which leaves a system with half open connections making the SYN queue fill out until connections are dropped.

The SYN Cookie protects against that, but there are a few weaknesses, and those could be exploited (normally combination attack though).

It is worth bearing in mind that quite a few thought that SYN attacks were unavoidable, so if SYN cookies can be used to consumer resource it is back. As to IPv6 that will open a new kettle of vulnerabilities. And it is not like people go oohh I need this new feature, TCP is about creating a connection over a connectionless medium, having to do that without the SYN queue was a bit of a leap in the first place, SYN Cookies try to do it via transmission which at first glance looks more hazardous, though interesting idea.

Whilst most are claiming there is no known defence, it is possible to trace people doing SYN attacks, it does require help from each of the router maintainers so it is not easy, but it is possible. So, doubtful the Net is going away any time soon. It is a bit like roads cannot stop foreign tanks rolling down them, well I suppose you can mine the road, and setup checkpoints and you can do similar things on the net.

[Anonymous Coward]

sna

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.

[Destroy All Monsters]

Pchao!

"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.

[The Other Steve]

"it's the most serious thing I've heard of in a month or two."

Yeah, that just about sums it up for me. Yet another example of the recent "OMG! The internets are broken! The Sky is falling. WE'RE ALL GOING TO DIE!" hysteria that seems to have been rife this year. And yet so far, large scale network based disaster is conspicuous in absentia.

So forgive me if I : a) don't panic and b) peg this as yet another "vulnerability" "discovered" by "researchers" who have never read Phrack, never looked at the RFCs until they managed to break something in the lab, conspicuously failed to do the most basic lit search, and are now screaming blue murder to equipment manufacturers and the tech media so that their blog entries tomorrow can be titled "OMG! How my 133t hax0r sKillZ totally saved, like, the entire internets! True!".

Totally, like, underwhelming.

[Tim Brown]

Yawn

"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......

[Anonymous Coward]

Oh policing like that won't work

it is every man, LAN and host for themselves.

That's the only design that works, if you try and add other levels, those levels will get compromised and when they do it will be even worse.

Security is a process, that requires constant monitoring and adapting.

But to put things in perspective most traffic in the CyberSpace is legit and it is not like MeatSpace is not vulnerable to similar problems.

Take your toll house idea - break the toll house and that is a very large DDoS or a very big abuse of trust. Anarchy works it always has done, but it is survival of the fitest.

It is not so much allowing people to forge sender addresses, but more this is actually how the Net works it is connectionless, and that is its strength. The dynamic routing is another strength, this thing is designed to withstand war and still be operational albeit in a limited way.

You are not meant to blindly trust - SSL and perhaps beyond will have to be bought in as standard, and the problem there is the free browsers, that is where they make their cash, ironic really as the Net could be lot more secure if it weren't for the browser wars.

The Net will get tiered, and is already to a degree, but each tier introduces new vulnerabilities, so there will always be ways to disrupt, if people can be traced then that is about as much as you can hope for. It still ties up the attacker's machine a bit running an attack, and there is a risk associated so business as usual.

[Bronek Kozicki]

@Destroy All Monsters

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.

[BlueGreen]

On formal methods & systemically knackered systems

In a recent article wherein the OU claims that their cousework was b0rked deliberately, Andrew Orlowski said

"Formal Methods, which went out of fashion in the mid-1990s,..."

Well, they didn't really, it was just apparent that they were a tad oversold, like AI, so went back to doing non-amazing-but-still-useful things behind the scenes. Development continues (crypto being a fine example but certainly not the only one).

Well, here's why they are useful. Within reasonable assumptions it would be possible to analyse TCP (and other netty stuff) and make guarantees about certain things and possibly reveal weaknesses as well. Formal methods aren't dead; far from it.

FMs are imperfect but a whole lot better than building it then watching it fall down.

And yes, I'm aware that TCP etc. was developed with no expectation that systems built with it would grow so huge or important.

Sadly I expect to spend more time learning them in the coming years because of their evident (to me) importance. Sadly, because I don't much like maths...

[Antony Riley]

Another blatantly obvious attack ?

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.

[TimM]

It's all...

... 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).

;-)

[Bronek Kozicki]

@Oh policing like that won't work

You mentioned SSL "and beyond" - there is slight problem with encrypting, or even signing everything, and it is called CPU utilization. Client side can serve quite a few SSL connections, but server side - how many thousands connections before server is brought to its knees? Until SSL accelerators become "butter and bread" of web hosting business, this is not going to happen. Of course, cryptographic security on IP level and hardware accelerators embedded in lots and lots of IP ports might help, but this is not in sight either.

[Brian Miller]

Problem is in stack and API

"...the class of attack takes advantage of the way resources are allocated immediately after TCP-enabled devices complete the three-way handshake (syn, syn-ack, ack) that is required for two internet-connected devices to interact."

OK, this looks like a resource allocation issue. This sounds like the attack needs to initiate a connection, and then never drop it. The stack allocates buffers and all after the initialization is complete, but of course the attacker is starting a new connection. Down you go after this piles up for a bit, with lots of memory fragmentation. The computer's memory is so fragmented that nothing can grab a decent chunk of memory. Reboot time.

Part of this is in the TCP/IP stack, and part of it is in the stack's caller. Yeah, I can see the flaw. Three packets of doom.

[Igor Mozolevsky]

So...

... 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.

[Anonymous Coward]

@Igor Mozolevsky

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

[Christos Georgiou]

I am not sure, but…

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

[Tom Paine]

IPv6

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.

[Anonymous Coward]

How is this different than any other resource depletion DoS?

If I can exhaust your system's pagefile surely I can match the impact of this, and more...?? And I can, on many OSes, given ability to execute a few lines of code wot I wrote. If pagefiles are boring, pick another system-wide but not unlimited resource...

Is SELinux vulnerable?

Is Windows vulnerable?

Are SNA systems vulnerable?

Are DECnet systems vulnerable?

Etc.

"IPv6 ... larger address space requiring more memory to keep track of."

OSI did most of the IPv6 stuff ages ago (1980s, shortly before the first time that IPv6 was due to be "the next big thing"). The OSI code is more complex than IPv4 and requires more memory than IPv4 but the expansion in size and complexity certainly wasn't on the scale of the expansion of the address space vs IPv4 and DECnet IV; if the IPv6 code *does* end up more vulnerable simply because of that, it's even worse than I had feared.

[Robert Brockway]

Something isn't adding up

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).

[Michael Sutton]

I Know Something You Don't Know

http://research.zscaler.com/2008/10/i-know-something-you-dont-know.html

"I have no doubt that I'll be thoroughly impressed once details of the attack are finally released. It does however make me uncomfortable to know that the clock is ticking and we can only sit on the sidelines to wait and see if motivated attackers are able to beat vendors to the punch and exploit this vulnerability before it can be patched."

Michael Sutton

VP, Security Research

Zscaler

[Elrond Hubbard]

It has nothing to deal with SYN Cookies.

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...