Hi there,
is there any weight to this new story on slashdot

http://it.slashdot.org/it/08/10/01/0127245.shtml
about a new attacker possible to break any tcp stack? Sounds rather

shady, so here I am, perhaps you guys have your ears closer to the ground
Regards

Most application protocols running on TCP are quite vulnerable to DoS,

but nobody has seemed to care so far...

On Wed, 01 Oct 2008 14:52:29 +0200
Seems possible.  Here: http://cr.yp.to/syncookies/archive

you will find the passage
"

   An attack would still need to know our random secret in order to

   spoof a connection without seeing any of our outgoing traffic.

   If an attacker can see our outgoing traffic, then they will be

   able to spoof a connection, but they could have done that anyway,

   even under the secure sequence number scheme we currently use.

"

and here: http://it.slashdot.org/it/08/10/01/0127245.shtml

"

Sockstress computes and stores so-called client-side SYN cookies and enables Lee and Louis to specify a destination port and IP address. The method allows them to complete the TCP handshake without having to store any values, which takes time and resources. "We can then say that we want to establish X number of TCP connections on that address and that we want to use this attack type, and it does it," Lee said.

"
we have the implication(?) that the exploit samples the target server

for a number of SYN cookies that will allow them to crack the 24-bit

'secret' hash that the server is using.  Once that is done, they

can then forge a large number of packets from random IP addressess

that look like correct client acks of the server's syn cookie.  
A server might counter by using a new secret hash for each session

request (leaving it open to a resource-hog attack) or use a sequential

mod of it's hash for each new request made...
Dhu

This is simply the naphta attack. They don't really need to "use syn

cookies". They could simply ACK any SYN/ACK they receive, and that's it.
The attack is not new, and they are not proposing any counter-measures.
It doesn't mean does this does not need attention... but they are not

making any new contribution to the issue.
Kind regards,
--

Fernando Gont

e-mail: fernando@gont.com.ar || fgont@acm.org

PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

On Wed, 01 Oct 2008 12:24:16 -0300
The impression I got is that they collect enough SYN cookies from

the server to crack the server's secret (24bit) and THEN they can

forge any number of acks to the server's syn cookie that contain

bogus ip/ports but with the correct sequence/hash.  If this is not

the case then it is nothing new.

According to a podcast I listened to, this is not what they try to

do. And even then, brute force attacks against SYN cookies have

already been discussed in the past. (although I agree that it usually

requires hard googling to spot the right documentation)
Kind regards,
--

Fernando Gont

e-mail: fernando@gont.com.ar || fgont@acm.org

PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

I listened to the podcast and got the idea that the socket is in

ESTABLISHED state (so after 3 way handshake) and they

mention that a packets PCB resources have timers, and that is what they

exploit.  Perhaps you establish the session and

send an HTTP request (pretend it's http) and never ACK the answer that

gets repeated based on the internal timers.  It seemed to me they say

that some stop repeating their content and just die. 
-p

I have just listened to the interview as well.
They said that they have looked at the source tree of Linux, at their

Timer code in the TCP stack. The Linux source code indeed have a

comment saying there are states that are bad and the Linux kernel

would try to avoid. So the sockstress program was written to work the

other way around, to try to get into that bad state as much as

possible, and it managed to bring down Linux systems.
They then run the same attack against a Windows machine, and it had

the same effect as well, so it really seem like a problem in the TCP

protocol.
In the article it is said that BSD are vulnerable as well, they didn't

mention if it was Free or Net or Open...
So I guess the question is if OpenBSD have such state in its TCP

stack, maybe a code auditing session (whenever it is done next, the

next Hackathon?) can look at something like that in the OpenBSD

kernel... or maybe the dev already saw this kind of problem and have

harden the TCP stack for OpenBSD?
--

This e-mail may be confidential. You may not copy, forward or use any

part. All disclaimers on the Internet are of zero legal effectiveness.

http://www.goldmark.org/jeff/stupid-disclaimers/

That would be Shalunov's netkill attack, which aims at exhausting

memory by tying it to both PCBs and socket send buffers.
--

Fernando Gont

e-mail: fernando@gont.com.ar || fgont@acm.org

PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

I looked this up on google, the URL for this attack is here:

http://shlang.com/netkill/ , I noticed it was a little bit

different from what I described because the state is in the FIN_WAIT_1

state on the remote machine, the TCP state

diagram in RFC 793 page 23 shows that a FIN is sent from the client's

close()  to the server to reach that state, so it differs.  If you have

a userland TCP/IP stack you can cease communication without the FIN

being sent.
I listened to the interview's first 5 minutes again and they mention

their own TCP/IP stack and that it was quite fast giving them a large

window; so large window, established state and userland TCP/IP stack is

their formula.
Here is the URL for the interview again the first 5 minutes are in

swedish so one can skip them:
mplayer -ss 5:0 http://debeveiligingsupdate.nl/audio/bevupd_0003.mp3
If the discoverers of this bug don't make their sockstress available to

OpenBSD then I have a userland TCP/IP stack for OpenBSD developers (mail

me), but it's only written to be a server, but I suspect it would be

easy to make it a client, just have to dust it off from my CVS as it's

quite old (2004 possibly).
Regards,
-p

I haven't checked yet, but isn't it included with Unicornscan

(www.unicornscan.org), the TCP/IP stack at least?
They originally released this back in 2004 and tried to demo it at

Toorcon 2004, but never quite got it working at that time.  They said

it compiled on OpenBSD then, but needed some testing and a maintainer.
I've tried to look for it since then and this is the first I've seen

it resurface.
--

bk

A little bit less vage info can be found here
http://tinyurl.com/3hv3kf
-- 
 Stephan A. Rickauer
 -----------------------------------------------------------

 Institute of Neuroinformatics         Tel  +41 44 635 30 50

 University / ETH Zurich               Sec  +41 44 635 30 52

 Winterthurerstrasse 190               Fax  +41 44 635 30 53

 CH-8057 Zurich                        Web    www.ini.uzh.ch

This article is mostly about exploiting SYN cookies to bring servers into

resource starvation. OpenBSD does not implement SYN cookies. We have a SYN

cache with a upper limit of open handshakes. Together with random initial

sequence numbers it is hard to finish the 3-way handshake without getting

the SYN/ACK from the server on OpenBSD systems.
I'm not too concerned about this "fundamental problem with TCP" but as

usual the mentioned article is less informative then the back side of my

breakfast cereals box.

On Wed, Oct 01, 2008 at 03:58:22PM +0200, Claudio Jeker wrote:

| On Wed, Oct 01, 2008 at 03:31:00PM +0200, Stephan A. Rickauer wrote:

| > On Wed, 2008-10-01 at 14:52 +0200, Leon Dippenaar wrote:

| > > Hi there,

| > >

| > > is there any weight to this new story on slashdot

| > > http://it.slashdot.org/it/08/10/01/0127245.shtml

| > >

| > > about a new attacker possible to break any tcp stack? Sounds rather

| > > shady, so here I am, perhaps you guys have your ears closer to the

ground

| >

| > A little bit less vage info can be found here

| >

| > http://tinyurl.com/3hv3kf

| >

|

| This article is mostly about exploiting SYN cookies to bring servers into

| resource starvation. OpenBSD does not implement SYN cookies. We have a SYN

| cache with a upper limit of open handshakes. Together with random initial

| sequence numbers it is hard to finish the 3-way handshake without getting

| the SYN/ACK from the server on OpenBSD systems.
So far, I've heard about issues with TCP *after* a session has been

established (ie, after the 3-way handshake). Somehow exploiting TCP

state timers to affect badness (DoS), maybe.
I agree with Claudio that very little is public so far (I don't eat

cereals, but I believe the same is true for my jar of peanutbutter).
For now, it's all *extremely* vague.
Cheers,
Paul 'WEiRD' de Weerd
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]

                 http://www.weirdnet.nl/
[demime 1.01d removed an attachment of type application/pgp-signature]

On Wed, 1 Oct 2008 15:58:22 +0200
It seems to me the "problem" is with SYN cookies.

On Wed, Oct 1, 2008 at 4:22 PM, Duncan Patton a Campbell
When I read the pseudo article, I had the impression that the server

does not have to implement SYN cookies. Their sockstress program uses

(client) SYN cookies to estabilish a lot of TCP connections with

minimal own resources...
Cheers,
Dries

On Wed, Oct 1, 2008 at 4:47 PM, Dries Schellekens
Some speculation by Fyodor:

http://insecure.org/stf/tcp-dos-attack-explained.html
Also check blog of one of the attack inventors:

http://blog.robertlee.name/
Cheers,
Dries

SYN cookies are only mentioned to boast about their high-performance tcp

flooder. Problem is that some systems 'became overly responsive', and

this is clearly an implementation issue.
"We noticed that certain systems would start resending certain packet

responses continuously until they were rebooted," Lee said.
Certain (buggy) systems resend certain (invalid/unneeded) responses, lo

and behold: tcp is broken forever. Phew.
-- 
./lxnt