New tcp stack attack

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

New tcp stack attack

Leon Dippenaar
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

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Stephan A. Rickauer
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


--

 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

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

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

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.
--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Duncan Patton a Campbell
In reply to this post by Leon Dippenaar
On Wed, 01 Oct 2008 14:52:29 +0200
Leon Dippenaar <[hidden email]> 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
>
> Regards
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Duncan Patton a Campbell
In reply to this post by Claudio Jeker
On Wed, 1 Oct 2008 15:58:22 +0200
Claudio Jeker <[hidden email]> 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.
>

It seems to me the "problem" is with SYN cookies.

Dhu

> 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.
> --
> :wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Alexander Sabourenkov
Duncan Patton a Campbell wrote:
>
> It seems to me the "problem" is with SYN cookies.
>

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

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Paul de Weerd
In reply to this post by Claudio Jeker
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]

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Dries Schellekens-2
In reply to this post by Duncan Patton a Campbell
On Wed, Oct 1, 2008 at 4:22 PM, Duncan Patton a Campbell
<[hidden email]> wrote:

> It seems to me the "problem" is with SYN cookies.

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

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Fernando Gont-2
In reply to this post by Duncan Patton a Campbell
At 11:13 a.m. 01/10/2008, Duncan Patton a Campbell wrote:

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

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: [hidden email] || [hidden email]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Fernando Gont-2
In reply to this post by Dries Schellekens-2
At 11:47 a.m. 01/10/2008, Dries Schellekens wrote:

> > It seems to me the "problem" is with SYN cookies.
>
>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...

Yes. This is in an unnecessarily-expensive naphta attack.

Kind regards,

--
Fernando Gont
e-mail: [hidden email] || [hidden email]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Duncan Patton a Campbell
In reply to this post by Fernando Gont-2
On Wed, 01 Oct 2008 12:24:16 -0300
Fernando Gont <[hidden email]> wrote:

> At 11:13 a.m. 01/10/2008, Duncan Patton a Campbell wrote:
>
> >"
> >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.
> >"
>
> 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 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.  

Dhu


> 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: [hidden email] || [hidden email]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Jussi Peltola
In reply to this post by Leon Dippenaar
Most application protocols running on TCP are quite vulnerable to DoS,
but nobody has seemed to care so far...

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Fernando Gont-2
In reply to this post by Duncan Patton a Campbell
At 12:41 p.m. 01/10/2008, Duncan Patton a Campbell wrote:

> > 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 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: [hidden email] || [hidden email]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Peter J. Philipp-2
Fernando Gont wrote:

> 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: [hidden email] || [hidden email]
> 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

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Fernando Gont-2
At 01:56 p.m. 01/10/2008, Peter J. Philipp wrote:

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

That was just an example of the type of resources that could be exhausted.


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

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: [hidden email] || [hidden email]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Peter J. Philipp-2
Fernando Gont wrote:

> At 01:56 p.m. 01/10/2008, Peter J. Philipp wrote:
>
>> 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.
>
> That was just an example of the type of resources that could be
> exhausted.
>
>
>> 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.
>
> That would be Shalunov's netkill attack, which aims at exhausting
> memory by tying it to both PCBs and socket send buffers.
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

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Brian Keefer
On Oct 1, 2008, at 11:11 AM, Peter J. Philipp wrote:

> Fernando Gont wrote:
> 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).

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

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Sunnz
In reply to this post by Peter J. Philipp-2
2008/10/2 Peter J. Philipp <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|

Re: New tcp stack attack

Dries Schellekens-2
In reply to this post by Dries Schellekens-2
On Wed, Oct 1, 2008 at 4:47 PM, Dries Schellekens
<[hidden email]> wrote:

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

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