deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE
 ·Verizon FIOS
 ·Comcast Workplace
 ·DSL EXTREME
|  sockstress
I don't know whether to be afraid or laugh.
This article and a few other blurps (also with zero technical details) via google mention this DOS that appears to just fill up state tables. The more listening services, the more easily this would be able to incite denial of service conditions.
The two authors (founders?) gave a talk a while back and I guess are planning another talk soon.
I guess something to keep an eye out for. Without details, I don't see how this would lead to a permanent DOS situation or deadlock (which is implied in one of the articles), since it sounds like they are just completing the 3-way handshake as many times as possible to fill a state table.
Does anyone have any thoughts on what they might be doing that's unique?
--
He who is not contented with what he has, would not be contented with what he would like to have. -Socrates |
|
Steve Gibson
@cogentco.com
thumbs down from:
Cabal 
| It's a problem.
In their audio interview they gave away all the information any good low-level hacker would need to re-create their attack tools.
I produce a weekly podcast called "Security Now!" with Leo Laporte and this week's podcast will be about this new problem. I'm recording the podcast live with Leo in one hour (at 11:00 pst »twitlive.tv) where you could watch it, and it will be edited and published officially tomorrow - Thursday October 2nd.
Steve. |
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE | Thank you Steve, I've tuned in. Appreciate it. |
|
swhx7
Premium
join:2006-07-23
Elbonia
·RoadRunner Cable
| reply to deblin
sockstress is the attack tool the discoverers made for proof-of-concept.
This article has more information: »searchsecurity.techtarget.com/ne···,00.html
And this Slashdot post has an explanation...
said by rtfa-troll :
What's happening in this attack is that the client side (the attacker) is using their own syn cookies to store information about connections on your server (instead of in their own memory). This allows them to handle more connections than otherwise. Unfortunately there is nothing you can do to stop this. They are using required behavior of the TCP stack for their information storage.
and possible (imperfect) workarounds.
BTW, this is that rare beast, an actual internet security problem. Most defects called "internet" problems are really defects in the endpoint software, such as Windows. This one is in the pipes. |
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE
·Verizon FIOS
·Comcast Workplace
·DSL EXTREME
| reply to Steve Gibson
Steve, as was mentioned on the show, there has been discussion about this on the OpenBSD misc mailing list here:
»kerneltrap.org/mailarchive/openb···/3468514
--
He who is not contented with what he has, would not be contented with what he would like to have. -Socrates |
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE
·Verizon FIOS
·Comcast Workplace
·DSL EXTREME
| reply to swhx7
If you listen to the mp3 linked on slashdot article, they say the client syn cookies are not the attack, they just make it more efficient (use less resources). So the cookies are not really important, other than they allow them to avoid resource starvation on the sending side.
From what I can tell, they accidentally triggered some resource starvation scenario during their large scale network scanning. Once they realized they'd caused some sort of resource starvation scenario, looked through the Linux kernel's tcp stack implementation and crafted a sequence of packets to put it into this bad state.
It's not just a single exploit, any resource used by the tcp stack without proper resource limits is a potential victim. timers are the one thing they mention frequently. I guess if there are a finite number of timers available for an entire sub-system or the entire kernel and you consume them all, bad things will happen (tm).
I guess they just happened to find a scenario that affects all tcp stacks.
--
He who is not contented with what he has, would not be contented with what he would like to have. -Socrates |
|
Steve Gibson
@cogentco.com
| reply to deblin
Deblin,
Thanks for the OpenBSD link. I'll read the thread with interest.
It might make sense for the other BSD's to grab OpenBSD's stack if it's sufficiently transportable. Today's stacks are quite complex and hardening the stack is not something one does in a hurry. (And there might be some urgency behind this.)
Steve. |
|
Steve Gibson
@cogentco.com
| reply to deblin
Hmmmmm. Those OpenBSD guys don't seem to be on the correct trail in that thread. I was hoping that they would have picked up on what this is probably about, but so far they don't seem to have. They seem a bit defensive about the strength of their stack, which is fine and understandable, so long as they also keep an open mind about the possibility that a new attack may have been found.
Steve. |
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE
·Verizon FIOS
·Comcast Workplace
·DSL EXTREME
| said by Steve Gibson :
Hmmmmm. Those OpenBSD guys don't seem to be on the correct trail in that thread. I was hoping that they would have picked up on what this is probably about, but so far they don't seem to have. They seem a bit defensive about the strength of their stack, which is fine and understandable, so long as they also keep an open mind about the possibility that a new attack may have been found.
Steve.
Agreed, they don't quite get it. In fact, if I am correct in my understanding here, I'd say without close scrutiny of tcp stack ABC, you won't know if any resource limits pose problems. I think in general, the resources used by tcp sockets are not well policed, at least it would seem that way. All one has to do is backtrace the code to see if there is a code path that would lead either to an endless cycle or which would be easily exploited to string the connection along.
I'm not sure how much of the tcp stack code OpenBSD/NetBSD/FreeBSD share, off hand.
--
He who is not contented with what he has, would not be contented with what he would like to have. -Socrates |
|
swhx7
Premium
join:2006-07-23
Elbonia | reply to deblin
Fyodor of nmap writes about it here: »insecure.org/stf/tcp-dos-attack-···ned.html |
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE
·Verizon FIOS
·Comcast Workplace
·DSL EXTREME
| Nice read there. Robert Lee responded on his blog:
»blog.robertlee.name/2008/10/conj···ml#links
He doesn't deny that it's not just a tweaked version of what's been around for nearly a decade...
--
He who is not contented with what he has, would not be contented with what he would like to have. -Socrates |
|
Steve Gibson
@cogentco.com
| Deblin,
I spent more than an hour on the phone with both Robert & Jack yesterday afternoon. By mutual agreement the bulk of our conversation was off-the-record and not for public rebroadcast. But I now have a much better understanding of who they are and what they intended. I'll be making a statement to that effect at the top of next week's Security Now! podcast.
Steve. |
|
