tcp vulnerability? haven't seen anything on it here...

tcp vulnerability? haven't seen anything on it here...

[Chris Friesen]

There has been some discussion about this on the Debian and OpenBSD 
lists, but I haven't seen anything on it here.  I know my boss is going 
to hear about this and want more information, so where does Linux stand 
with regards to this?

http://www.uniras.gov.uk/vuls/2004/236929/index.htm


Thanks,

Chris

Re: tcp vulnerability? haven't seen anything on it here...

[Richard B. Johnson]

On Wed, 21 Apr 2004, Chris Friesen wrote:

>
> There has been some discussion about this on the Debian and OpenBSD
> lists, but I haven't seen anything on it here.  I know my boss is going
> to hear about this and want more information, so where does Linux stand
> with regards to this?
>
> http://www.uniras.gov.uk/vuls/2004/236929/index.htm
>
> Thanks,
>
> Chris

The vulnerabilities were discussed on US news reports as being
like somebody discovered they could disconnect your electricity
if they had some wire-cutters.

Those guys in the UK just don't have anything else to do! It
seems that they discovered that if you tap-into some network
physical media you could disrupt it! Since it has been taking
so long for IP/V6 to take hold, those proponents claim that
it will be a solution. Me-thinks it's a solution waiting for
a problem. The IP/V6 folks want to force (using government and
industry FUD) to discontinue IP/V4 as a "security risk!!!"

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: tcp vulnerability? haven't seen anything on it here...

[Chris Friesen]

Richard B. Johnson wrote:

> The vulnerabilities were discussed on US news reports as being
> like somebody discovered they could disconnect your electricity
> if they had some wire-cutters.
> 
> Those guys in the UK just don't have anything else to do! It
> seems that they discovered that if you tap-into some network
> physical media you could disrupt it!

The impression I got was that some equipment was much more vulnerable 
due to having a) massive windows, and b) using sequential source ports, 
making it much easier to guess even if you can't tap the line.

Chris

Re: tcp vulnerability? haven't seen anything on it here...

[Jörn Engel]

On Wed, 21 April 2004 12:25:27 -0400, Chris Friesen wrote:
> 
> The impression I got was that some equipment was much more vulnerable 
> due to having a) massive windows, and b) using sequential source ports, 
> making it much easier to guess even if you can't tap the line.

Heise.de made it appear, as if the only news was that with tcp
windows, the propability of guessing the right sequence number is not
1:2^32 but something smaller.  They said that 64k packets would be
enough, so guess what the window will be.

Obvious solution would be to use a small window, which would cost
performance.  Different solution would be to use a different window
size for reset, like, say, 1.  Not sure if that would still be
standard, though.

Jörn

-- 
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown

Re: tcp vulnerability? haven't seen anything on it here...

[David S. Miller]

On Wed, 21 Apr 2004 19:03:40 +0200
Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:

> Heise.de made it appear, as if the only news was that with tcp
> windows, the propability of guessing the right sequence number is not
> 1:2^32 but something smaller.  They said that 64k packets would be
> enough, so guess what the window will be.

Yes, that is their major discovery.  You need to guess the ports
and source/destination addresses as well, which is why I don't
consider this such a serious issue personally.

It is mitigated if timestamps are enabled, because that becomes
another number you have to guess.

It is mitigated also by randomized ephemeral port selection, which
OpenBSD implements and we could easily implement as well.

I'm very happy that OpenBSD checked in a fix for this a week or so
ago and took some of the thunder out of this bogusly hyped announcement.

Re: tcp vulnerability? haven't seen anything on it here...

[James Morris]

On Wed, 21 Apr 2004, David S. Miller wrote:

> On Wed, 21 Apr 2004 19:03:40 +0200
> Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:
> 
> > Heise.de made it appear, as if the only news was that with tcp
> > windows, the propability of guessing the right sequence number is not
> > 1:2^32 but something smaller.  They said that 64k packets would be
> > enough, so guess what the window will be.
> 
> Yes, that is their major discovery.  You need to guess the ports
> and source/destination addresses as well, which is why I don't
> consider this such a serious issue personally.
>
> It is mitigated if timestamps are enabled, because that becomes
> another number you have to guess.
> 
> It is mitigated also by randomized ephemeral port selection, which
> OpenBSD implements and we could easily implement as well.

What about the techniques mentioned in
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt ?

Curiously there is no mention of port guessing or timestamps there.


- James
-- 
James Morris
<jmorris@redhat.com>

Re: tcp vulnerability? haven't seen anything on it here...

[Willy Tarreau]

On Wed, Apr 21, 2004 at 08:45:42PM -0400, James Morris wrote:
> On Wed, 21 Apr 2004, David S. Miller wrote:
> 
> > On Wed, 21 Apr 2004 19:03:40 +0200
> > Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:
> > 
> > > Heise.de made it appear, as if the only news was that with tcp
> > > windows, the propability of guessing the right sequence number is not
> > > 1:2^32 but something smaller.  They said that 64k packets would be
> > > enough, so guess what the window will be.
> > 
> > Yes, that is their major discovery.  You need to guess the ports
> > and source/destination addresses as well, which is why I don't
> > consider this such a serious issue personally.
> >
> > It is mitigated if timestamps are enabled, because that becomes
> > another number you have to guess.
> > 
> > It is mitigated also by randomized ephemeral port selection, which
> > OpenBSD implements and we could easily implement as well.
> 
> What about the techniques mentioned in
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt ?

They might break the net rather than fix it, they don't seem to consider
every aspect. Imagine installed stateful firewalls, NAT boxes, load balancers,
etc... All those boxes which won't speak RFCXXXX will block the return ACK
once they see the forward RST, and the server behind the firewall will keep
ESTABLISHED sessions for hours, days, ... or up to the session time-out
dictated by the application. RSTs are very common on the internet from dialup
networks because there are lots of people without any clue about networking,
who hang up their modem while they fill a form on a site or read a long page,
ignoring that their MSIE does HTTP keep-alive and has not yet closed the
session. Some also experiment hard lockups or BSODs during FTP transfers, ...
And when they release the line, someone else on the same ISP connects and
gets the same address. And what does he do with all the ACKs the server sends
him ? RST !

It seems that this RST is covered by their draft, but instead of enumerating
every possibility to get an RST and check how they can cover it, they focus
on changing the RFC, regardless of already deployed implementations. Well,
I'm already waiting for the fight between RFCxxxx compliant OSes vs RFCyyyy
with yyyy > xxxx. It will be a bit like rfc1337: an entry in /proc for us,
a sysctl for BSD users, ndd for solaris and a registry key for many others.

At least their draft needs to be validated in every condition, and consequences
must be evaluated, with perhaps work-arounds (eg: fall back to old behaviour
after a certain number of particular RSTs, ...).

> Curiously there is no mention of port guessing or timestamps there.

They don't even explain why RSTs are generated and why we need them.

Regards,
Willy

Re: tcp vulnerability? haven't seen anything on it here...

[Giuliano Pochini]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1055 bytes --]


On 21-Apr-2004 David S. Miller wrote:
> On Wed, 21 Apr 2004 19:03:40 +0200
> Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:
> 
>> Heise.de made it appear, as if the only news was that with tcp
>> windows, the propability of guessing the right sequence number is not
>> 1:2^32 but something smaller.  They said that 64k packets would be
>> enough, so guess what the window will be.
>
> Yes, that is their major discovery.  You need to guess the ports
> and source/destination addresses as well, which is why I don't
> consider this such a serious issue personally.

Yes, but it is possible, expecially for long sessions. Also,
data injections is also possible with the same method, because
the receiver accepts everything inside the window, which is
usually 64k. Out of curiosity: in case Linux receives two
packets relative to the same portion of the stream, does it
check if the overlapping data is the same ? It would add extra
security about data injection in case the data has not been
sent to userspace yet.


--
Giuliano.

Re: tcp vulnerability? haven't seen anything on it here...

[Richard B. Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1433 bytes --]

On Thu, 22 Apr 2004, Giuliano Pochini wrote:

>
> On 21-Apr-2004 David S. Miller wrote:
> > On Wed, 21 Apr 2004 19:03:40 +0200
> > Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:
> >
> >> Heise.de made it appear, as if the only news was that with tcp
> >> windows, the propability of guessing the right sequence number is not
> >> 1:2^32 but something smaller.  They said that 64k packets would be
> >> enough, so guess what the window will be.
> >
> > Yes, that is their major discovery.  You need to guess the ports
> > and source/destination addresses as well, which is why I don't
> > consider this such a serious issue personally.
>
> Yes, but it is possible, expecially for long sessions. Also,
> data injections is also possible with the same method, because
> the receiver accepts everything inside the window, which is
> usually 64k. Out of curiosity: in case Linux receives two
> packets relative to the same portion of the stream, does it
> check if the overlapping data is the same ? It would add extra
> security about data injection in case the data has not been
> sent to userspace yet.
>
>

Has anybody checked to see what Linux does if it receives a
RST to the broadcast address? It would be a shame if all
connections were dropped!


Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: tcp vulnerability? haven't seen anything on it here...

[Willy Tarreau]

On Thu, Apr 22, 2004 at 07:35:54AM -0400, Richard B. Johnson wrote:
 
> Has anybody checked to see what Linux does if it receives a
> RST to the broadcast address? It would be a shame if all
> connections were dropped!

I don't see how this would be possible : a TCP packet is matched *only* if
it refers to a valid session. If you have no session established from/to the
broadcast address, there's no possibility that an RST targetted at this address
terminates anything, even if the ports are OK.

Cheers,
Willy

Re: tcp vulnerability? haven't seen anything on it here...

[Richard B. Johnson]

On Thu, 22 Apr 2004, Willy Tarreau wrote:

> On Thu, Apr 22, 2004 at 07:35:54AM -0400, Richard B. Johnson wrote:
>
> > Has anybody checked to see what Linux does if it receives a
> > RST to the broadcast address? It would be a shame if all
> > connections were dropped!
>
> I don't see how this would be possible : a TCP packet is matched *only* if
> it refers to a valid session. If you have no session established from/to the
> broadcast address, there's no possibility that an RST targetted at this
> address
> terminates anything, even if the ports are OK.
>
> Cheers,
> Willy
>

If course it's possible. Remember the trick to blue-screen W$, just
send a fragmented packet with a large length, then never send the
rest. There are lots of things that can happen when control
data goes to the broadcast address. Ping the broadcast address and
observe. If you have any W$/2000/prof machines on your network that
don't have service-pack 2 or later installed, just syn-flood the
broadcast address. So I  wonder how well the corner cases have been
checked. Of course you can't "connect" to a host using the broadcast
address, unless some code runs off the end of a switch statement
unchecked.

Hopefully invalid packets just get dropped on the floor. However,
history shows otherwise. Linux has a habit of loudly complaining
about invalid packets or protocol violations. The result being
a log full of messages leading to a full file-system. Fortunately
one can turn off many using the /proc/sys/net/ipv4 interface.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: tcp vulnerability? haven't seen anything on it here...

[Willy Tarreau]

Richard,

you are confusing several thinks, stateful vs stateless protocols. A ping
doesn't need a session on the remote host to be interpreted. A TCP segment
whose flags don't show a SYN need a session to be interpreted. Please note
that I'm not arguing that you won't crash a linux box with an RST addressed
to a broadcast address, I'm saying that there's absolutely no reason why
this should reset all connections, as you proposed it. Someone would have
had to code this explicitly, it cannot be a simple side effect.

Imagine that each packet which enters the system is presented to a hash
table containing the sessions, and that its session is looked for into
this hash table. You agree that in such code, there's no reason to find
anything that runs through all sessions and kill everyone, since this
code has no use there, and has no reason to be implemented on purpose !

Look at functions such as tcp_v4_lookup() in net/ipv4/tcp_ipv4.c for
example. When it reaches tcp_v4_lookup_established(), you find this :

        for(sk = head->chain; sk; sk = sk->next) {
                if(TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif))
                        goto hit; /* You sunk my battleship! */
        }

You cannot match more than once.

Cheers,
Willy


On Thu, Apr 22, 2004 at 09:42:58AM -0400, Richard B. Johnson wrote:
> On Thu, 22 Apr 2004, Willy Tarreau wrote:
> 
> > On Thu, Apr 22, 2004 at 07:35:54AM -0400, Richard B. Johnson wrote:
> >
> > > Has anybody checked to see what Linux does if it receives a
> > > RST to the broadcast address? It would be a shame if all
> > > connections were dropped!
> >
> > I don't see how this would be possible : a TCP packet is matched *only* if
> > it refers to a valid session. If you have no session established from/to the
> > broadcast address, there's no possibility that an RST targetted at this
> > address
> > terminates anything, even if the ports are OK.
> >
> > Cheers,
> > Willy
> >
> 
> If course it's possible. Remember the trick to blue-screen W$, just
> send a fragmented packet with a large length, then never send the
> rest. There are lots of things that can happen when control
> data goes to the broadcast address. Ping the broadcast address and
> observe. If you have any W$/2000/prof machines on your network that
> don't have service-pack 2 or later installed, just syn-flood the
> broadcast address. So I  wonder how well the corner cases have been
> checked. Of course you can't "connect" to a host using the broadcast
> address, unless some code runs off the end of a switch statement
> unchecked.
> 
> Hopefully invalid packets just get dropped on the floor. However,
> history shows otherwise. Linux has a habit of loudly complaining
> about invalid packets or protocol violations. The result being
> a log full of messages leading to a full file-system. Fortunately
> one can turn off many using the /proc/sys/net/ipv4 interface.
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
>             Note 96.31% of all statistics are fiction.
> 

Re: tcp vulnerability? haven't seen anything on it here...

[Richard B. Johnson]

On Thu, 22 Apr 2004, Willy Tarreau wrote:

> Richard,
>
> you are confusing several thinks, stateful vs stateless protocols. A ping
> doesn't need a session on the remote host to be interpreted. A TCP segment
> whose flags don't show a SYN need a session to be interpreted. Please note
> that I'm not arguing that you won't crash a linux box with an RST addressed
> to a broadcast address, I'm saying that there's absolutely no reason why
> this should reset all connections, as you proposed it. Someone would have
> had to code this explicitly, it cannot be a simple side effect.
>
> Imagine that each packet which enters the system is presented to a hash
> table containing the sessions, and that its session is looked for into
> this hash table. You agree that in such code, there's no reason to find
> anything that runs through all sessions and kill everyone, since this
> code has no use there, and has no reason to be implemented on purpose !
>
> Look at functions such as tcp_v4_lookup() in net/ipv4/tcp_ipv4.c for
> example. When it reaches tcp_v4_lookup_established(), you find this :
>
>         for(sk = head->chain; sk; sk = sk->next) {
>                 if(TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif))
>                         goto hit; /* You sunk my battleship! */
>         }
>
> You cannot match more than once.

[SNIPPED...]

So you are sure an attacker will fire only one bullet?

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: tcp vulnerability? haven't seen anything on it here...

[Willy Tarreau]

On Thu, Apr 22, 2004 at 04:25:19PM -0400, Richard B. Johnson wrote:
> On Thu, 22 Apr 2004, Willy Tarreau wrote:
> 
> > Richard,
> >
> > you are confusing several thinks, stateful vs stateless protocols. A ping
> > doesn't need a session on the remote host to be interpreted. A TCP segment
> > whose flags don't show a SYN need a session to be interpreted. Please note
> > that I'm not arguing that you won't crash a linux box with an RST addressed
> > to a broadcast address, I'm saying that there's absolutely no reason why
> > this should reset all connections, as you proposed it. Someone would have
> > had to code this explicitly, it cannot be a simple side effect.
> >
> > Imagine that each packet which enters the system is presented to a hash
> > table containing the sessions, and that its session is looked for into
> > this hash table. You agree that in such code, there's no reason to find
> > anything that runs through all sessions and kill everyone, since this
> > code has no use there, and has no reason to be implemented on purpose !
> >
> > Look at functions such as tcp_v4_lookup() in net/ipv4/tcp_ipv4.c for
> > example. When it reaches tcp_v4_lookup_established(), you find this :
> >
> >         for(sk = head->chain; sk; sk = sk->next) {
> >                 if(TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif))
> >                         goto hit; /* You sunk my battleship! */
> >         }
> >
> > You cannot match more than once.
> 
> [SNIPPED...]
> 
> So you are sure an attacker will fire only one bullet?

I don't see where you want to go. An attacker will have to fire at least
one "bullet" per port, per sequence number block and per timestamp if any.
That's the basis of the protocol. You were asking if *one* packet sent
to a broadcast address could reset *every* TCP connections, David showed
you that broadcasts were dropped, and I showed you that you need as many
packets as possible combinations to shoot all connections. That's all.

And BTW, do you think that such a "serious" vulnerability wouldn't have
been demonstrated on live sites if it was so obvious ? Don't worry, we
still have a few years in front of us before home networks are fast enough
to scan such large ranges in a matter of days.

Cheers,
Willy

Re: tcp vulnerability? haven't seen anything on it here...

[David S. Miller]

On Thu, 22 Apr 2004 07:35:54 -0400 (EDT)
"Richard B. Johnson" <root@chaos.analogic.com> wrote:

> Has anybody checked to see what Linux does if it receives a
> RST to the broadcast address? It would be a shame if all
> connections were dropped!

int tcp_v4_rcv(struct sk_buff *skb)
{
 ...
	if (skb->pkt_type != PACKET_HOST)
		goto discard_it;

Packets which are multicast or broadcast do not get marked
as "PACKET_HOST".

Re: tcp vulnerability? haven't seen anything on it here...

[jamal]

On Thu, 2004-04-22 at 04:23, Giuliano Pochini wrote:

> Yes, but it is possible, expecially for long sessions. 

In other words, 80% or more of internet traffic would not be affected
still using http1.0 would not be affected.
And for something like a huge download to just regular joe, this is more
of a nuisance assuming some kiddie has access between you and the
server.
OTOH, long lived BGP sessions are affected assuming you are going across
hostile path to your peer.

So whats all this ado about nothing? Local media made it appear we are
all about to die.

Is anyone working on some fix?

cheers,
jamal

Re: tcp vulnerability? haven't seen anything on it here...

[Giuliano Pochini]

On Thu, 22 Apr 2004, jamal wrote:

> On Thu, 2004-04-22 at 04:23, Giuliano Pochini wrote:
>
> > Yes, but it is possible, expecially for long sessions.
>
> In other words, 80% or more of internet traffic would not be affected
> still using http1.0 would not be affected.
> And for something like a huge download to just regular joe, this is more
> of a nuisance assuming some kiddie has access between you and the
> server.

No, TCP/IP is 100% vulnerable to the man-in-the-middle attach. There is no
cure for that. Some devices or softwares called "firewall" are designed to
cut or to modify connections. :)
This vulnerability is about external attacks.


--
Giuliano.

Re: tcp vulnerability? haven't seen anything on it here...

[jamal]

On Thu, 2004-04-22 at 09:46, Giuliano Pochini wrote:
> On Thu, 22 Apr 2004, jamal wrote:
> 
> > On Thu, 2004-04-22 at 04:23, Giuliano Pochini wrote:
> >
> > > Yes, but it is possible, expecially for long sessions.
> >
> > In other words, 80% or more of internet traffic would not be affected
> > still using http1.0 would not be affected.
> > And for something like a huge download to just regular joe, this is more
> > of a nuisance assuming some kiddie has access between you and the
> > server.
> 
> No, TCP/IP is 100% vulnerable to the man-in-the-middle attach.
>  There is no cure for that. 

Unless its a private network with locked vaults for the pipes, any
network is vulnerable.
I am not trying to downplay the relevance of this; all i am saying
is it may a little overhyped with the media being involved. Its
infact harder to create this attack compared to a simple SYN attack.

On Thu, 2004-04-22 at 09:58, Florian Weimer wrote:
jamal <hadi@cyberus.ca> writes:
> 
> > OTOH, long lived BGP sessions are affected assuming you are going across
> > hostile path to your peer.
> 
> Hostile path is not required.  Not at all. 8-(
> 
> 

Unless i misunderstood:
You need someone/thing to see about 64K packets within a single flow
to make the predicition so the attack is succesful. Sure to have access to
such capability is to be in a hostile path, no? ;-> 


> And it's not BGP specific.  You might be able to use this attack to
> split IRC networks, too.  However, it's a bit harder in this case
> because IRC servers usually use more random source ports.

Any long lived flow with close to fixed ports. FTP from kernel.org could
be vulnerable - get a better client and its just becomes a nuisance.
80% of the internet traffic is still TCP/HTTP1.0 which is very 
short lived (there could be changes lately - these are numbers from 
a while back) i.e you wont see more than 8 packets i.e it is highly unlikely 
your traffic there is affected even if you used fixed ports.

cheers,
jamal

Re: tcp vulnerability? haven't seen anything on it here...

[alex]

On 22 Apr 2004, jamal wrote:

> Unless its a private network with locked vaults for the pipes, any
> network is vulnerable. I am not trying to downplay the relevance of
> this; all i am saying is it may a little overhyped with the media being
> involved. Its infact harder to create this attack compared to a simple
> SYN attack.
Not quite. With a SYN you have to respond with exactly the same sequence 
number as attacking host in order to establish connection. With RST, your 
sequence number needs to be +- rwin in order to kill the connection. That 
significantly reduces search space.

> Unless i misunderstood: You need someone/thing to see about 64K packets
> within a single flow to make the predicition so the attack is succesful.
> Sure to have access to such capability is to be in a hostile path, no?
> ;->
No, you do not need to see any packet. 

> > And it's not BGP specific.  You might be able to use this attack to
> > split IRC networks, too.  However, it's a bit harder in this case
> > because IRC servers usually use more random source ports.
> 
> Any long lived flow with close to fixed ports. FTP from kernel.org could
> be vulnerable - get a better client and its just becomes a nuisance. 80%
> of the internet traffic is still TCP/HTTP1.0 which is very short lived
> (there could be changes lately - these are numbers from a while back)
> i.e you wont see more than 8 packets i.e it is highly unlikely your
> traffic there is affected even if you used fixed ports.
Inter-provider BGP is long-lived with close to fixed ports, which is why 
it has caused quite a stir.

Nevertheless, number of packets to kill the session is still *large* 
(under "best-case" for attacker, you need to send 2^30 packets)...

-alex

Re: tcp vulnerability? haven't seen anything on it here...

[jamal]

On Thu, 2004-04-22 at 10:37, alex@pilosoft.com wrote:
> On 22 Apr 2004, jamal wrote:
> > Its infact harder to create this attack compared to a simple
> > SYN attack.
> Not quite. 

I meant a SYN Flood attack is a much trivial attack than this
but the media may have gotten used to it by now.

> > Unless i misunderstood: You need someone/thing to see about 64K packets
> > within a single flow to make the predicition so the attack is succesful.
> > Sure to have access to such capability is to be in a hostile path, no?
> > ;->
> No, you do not need to see any packet. 
> 

Ok, so i misunderstood then. How do you predict the sequences without
seeing any packet?
Is there any URL to mentioned paper?

> Inter-provider BGP is long-lived with close to fixed ports, which is why 
> it has caused quite a stir.

Makes sense. What would be the overall effect though? Route flaps?

> Nevertheless, number of packets to kill the session is still *large* 
> (under "best-case" for attacker, you need to send 2^30 packets)...

;->

cheers,
jamal

Re: tcp vulnerability? haven't seen anything on it here...

[alex]

> > > Unless i misunderstood: You need someone/thing to see about 64K
> > > packets within a single flow to make the predicition so the attack
> > > is succesful. Sure to have access to such capability is to be in a
> > > hostile path, no? ;->
> > No, you do not need to see any packet.
> > 
> 
> Ok, so i misunderstood then. How do you predict the sequences without
> seeing any packet? Is there any URL to mentioned paper?
You don't - just brute-force the tcp 4-tuple and sequence number. The
attack relies on the fact that you don't have to match sequence number
exactly, which cuts down on the search-space. (If total search space is
2^32, rwin is 16k, effective attack search space is 2^32/16k). Multiplied 
by number of ephemeral ports, it becomes *feasible* but still not very 
likely.

> > Inter-provider BGP is long-lived with close to fixed ports, which is
> > why it has caused quite a stir.
> 
> Makes sense. What would be the overall effect though? Route flaps?
Yep.

> > Nevertheless, number of packets to kill the session is still *large*
> > (under "best-case" for attacker, you need to send 2^30 packets)...

-alex

Re: tcp vulnerability? haven't seen anything on it here...

[Horst von Brand]

alex@pilosoft.com said:
> > > > Unless i misunderstood: You need someone/thing to see about 64K
> > > > packets within a single flow to make the predicition so the attack
> > > > is succesful. Sure to have access to such capability is to be in a
> > > > hostile path, no? ;->
> > > No, you do not need to see any packet.

> > Ok, so i misunderstood then. How do you predict the sequences without
> > seeing any packet? Is there any URL to mentioned paper?

> You don't - just brute-force the tcp 4-tuple and sequence number. The
> attack relies on the fact that you don't have to match sequence number
> exactly, which cuts down on the search-space. (If total search space is
> 2^32, rwin is 16k, effective attack search space is 2^32/16k). Multiplied 
> by number of ephemeral ports, it becomes *feasible* but still not very 
> likely.

If everybody (or at least the bigger knots) filters spoofed traffic, this
ceases to be a problem. And that solves a shipload of other problems, so...

If the cracker has access to the connection between routers (quite unlikely
for BGP), there is other, lower-hanging, fun to be had... and in that case
they can just read the exact data from the stream, no guessing needed at
all. And no protection possible either AFAICS.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: tcp vulnerability? haven't seen anything on it here...

[Florian Weimer]

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

> If everybody (or at least the bigger knots) filters spoofed traffic,
> this ceases to be a problem. And that solves a shipload of other
> problems, so...

There isn't much incentive to deploy filters so that other people
don't suffer.  So it takes a long time until it's almost universally
implemented.  (We catch less backscatter from DDoS attacks than a few
years ago, so the situation may actually be improving.)

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk,
tiscali.cz, tiscali.it, voila.fr.

Re: tcp vulnerability? haven't seen anything on it here...

[Chris Friesen]

alex@pilosoft.com wrote:

> Nevertheless, number of packets to kill the session is still *large* 
> (under "best-case" for attacker, you need to send 2^30 packets)...

I though the whole point of this vulnerability was that you "only" needed to send 64K packets, not 2^30.

Chris

Re: tcp vulnerability? haven't seen anything on it here...

[alex]

On Thu, 22 Apr 2004, Chris Friesen wrote:

> alex@pilosoft.com wrote:
> 
> > Nevertheless, number of packets to kill the session is still *large*
> > (under "best-case" for attacker, you need to send 2^30 packets)...
> 
> I though the whole point of this vulnerability was that you "only"
> needed to send 64K packets, not 2^30.
64k packets if rwin is 64k and if you know ports on both sides.

If rwin is 16k (default on many routers) and you need to scan all
ephemeral ports, its 256k packets * number of ephemeral ports.

One router vendor has 4000 ephemeral ports maximum, resulting in 256k*4000 
= ~1 billion packets.


-alex

Re: tcp vulnerability? haven't seen anything on it here...

[Florian Weimer]

alex@pilosoft.com writes:

> Not quite. With a SYN you have to respond with exactly the same sequence 
> number as attacking host in order to establish connection. With RST, your 
> sequence number needs to be +- rwin in order to kill the connection. That 
> significantly reduces search space.

Don't forget that you can tear down a connection by sending a SYN in
the correct window as well.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk,
tiscali.cz, tiscali.it, voila.fr.

Re: tcp vulnerability? haven't seen anything on it here...

[Florian Weimer]

jamal <hadi@cyberus.ca> writes:

> OTOH, long lived BGP sessions are affected assuming you are going across
> hostile path to your peer.

Hostile path is not required.  Not at all. 8-(

And it's not BGP specific.  You might be able to use this attack to
split IRC networks, too.  However, it's a bit harder in this case
because IRC servers usually use more random source ports.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk,
tiscali.cz, tiscali.it, voila.fr.

Re: tcp vulnerability? haven't seen anything on it here...

[Florian Weimer]

jamal <hadi@cyberus.ca> writes:

> OTOH, long lived BGP sessions are affected assuming you are going across
> hostile path to your peer.

Jamal, please forget that "hostile path to your peer" part.  It's just
wrong.

You are entitled to your opinion that this isssue is being overhyped
(I tend to share it, at least until some evidence shows up that
there's also a 4.4BSD-like RST bug), but please try to understand the
issue before making any judgement.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk,
tiscali.cz, tiscali.it, voila.fr.

Re: tcp vulnerability? haven't seen anything on it here...

[alex]

> And for something like a huge download to just regular joe, this is more
> of a nuisance assuming some kiddie has access between you and the
> server. OTOH, long lived BGP sessions are affected assuming you are
> going across hostile path to your peer.
Again - no hostile path necessary. Attack is brute-force and does not rely 
on MITM.

> So whats all this ado about nothing? Local media made it appear we are
> all about to die.
Pretty much.
> 
> Is anyone working on some fix?
In networking world, there was a craze of enabling TCP-MD5 for BGP
sessions reacting to this attack. There is alternative solution, "TTL
hack", relying that most BGP sessions are between directly-connected 
routers, so if connection originator sets TTL to 255 and receiver verifies 
that TTL on incoming packet is 255, you can be reasonably certain that the 
packet was sent by someone directly connected to you. ;)

-alex

Re: tcp vulnerability? haven't seen anything on it here...

[jamal]

Clarification:
I think the latency of my earlier email introduced by probably netdev is
creating a lot of "hostile" responses to me ;-> I feel like i am in
hostile path here ;->
I sent that email a long time ago, seems like netdev or my ISP decided
to deliver it now and reordered the delivery. This has happened to me a 
few times before with netdev thats why i prefer to cc people whenever i
can (worst case they receive more than one message)
Consider that message obsolete. I know you can create this problem via
brute force as you explained in your later email (that showed up
yesterday).

cheers,
jamal

On Fri, 2004-04-23 at 10:15, alex@pilosoft.com wrote:
> > And for something like a huge download to just regular joe, this is more
> > of a nuisance assuming some kiddie has access between you and the
> > server. OTOH, long lived BGP sessions are affected assuming you are
> > going across hostile path to your peer.
> Again - no hostile path necessary. Attack is brute-force and does not rely 
> on MITM.
> 
> > So whats all this ado about nothing? Local media made it appear we are
> > all about to die.
> Pretty much.
> > 
> > Is anyone working on some fix?
> In networking world, there was a craze of enabling TCP-MD5 for BGP
> sessions reacting to this attack. There is alternative solution, "TTL
> hack", relying that most BGP sessions are between directly-connected 
> routers, so if connection originator sets TTL to 255 and receiver verifies 
> that TTL on incoming packet is 255, you can be reasonably certain that the 
> packet was sent by someone directly connected to you. ;)
> 
> -alex
> 
> 

Re: tcp vulnerability? haven't seen anything on it here...

[Ranjeet Shetye]

On Wed, 2004-04-21 at 13:20, David S. Miller wrote:
> On Wed, 21 Apr 2004 19:03:40 +0200
> Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:
> 
> > Heise.de made it appear, as if the only news was that with tcp
> > windows, the propability of guessing the right sequence number is not
> > 1:2^32 but something smaller.  They said that 64k packets would be
> > enough, so guess what the window will be.
> 
> Yes, that is their major discovery.  You need to guess the ports
> and source/destination addresses as well, which is why I don't
> consider this such a serious issue personally.
> 
> It is mitigated if timestamps are enabled, because that becomes
> another number you have to guess.
> 
> It is mitigated also by randomized ephemeral port selection, which
> OpenBSD implements and we could easily implement as well.
> 
> I'm very happy that OpenBSD checked in a fix for this a week or so
> ago and took some of the thunder out of this bogusly hyped announcement.

(Not the same issue, but interesting still, and its related)

Isn't this (http://www.lowth.com/cutter/) an application on the same
lines ? (but from the perspective of a person ON one of the two endpoint
machines, rather than a remote third party).

QUOTE

There is a feature of the TCP/IP protocol that we could use to good
effect here :- If a packet (other than an RST) is received on a
connection that has the wrong sequence number, then the host responds by
sending a corrective "ACK" packet back. This "ACK" reply is designed to
put the sequence numbers at both ends back into step - and allows the
protocol to retransmit packets that got lost. This is very nice for our
needs - if the firewall sends a packet that is "correct" in all respects
except for the sequence number, then the host very helpfully tells us
what should have been used. We can then use this information to build
the RST packet that will abort the connection.

END OF QUOTE

thanks,

-- 

Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
Ranjeet dot Shetye2 at Zultys dot com
http://www.zultys.com/
 
The views, opinions, and judgements expressed in this message are solely
those of the author. The message contents have not been reviewed or
approved by Zultys.

Re: tcp vulnerability? haven't seen anything on it here...

[Sridhar Samudrala]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1530 bytes --]

On Wed, 21 Apr 2004, David S. Miller wrote:

> On Wed, 21 Apr 2004 19:03:40 +0200
> Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:
>
> > Heise.de made it appear, as if the only news was that with tcp
> > windows, the propability of guessing the right sequence number is not
> > 1:2^32 but something smaller.  They said that 64k packets would be
> > enough, so guess what the window will be.
>
> Yes, that is their major discovery.  You need to guess the ports
> and source/destination addresses as well, which is why I don't
> consider this such a serious issue personally.
>
> It is mitigated if timestamps are enabled, because that becomes
> another number you have to guess.

I am not sure if enabling timestamps will help.
>From RFC1323,
  It is recommended that RST segments NOT carry timestamps, and that RST
  segments be acceptable regardless of their timestamp. Old duplicate RST
  segments should be exceedingly unlikely, and their cleanup function should
  take precedence over timestamps.

It looks like linux follows this recommendataion.
tcp_input.c: tcp_rcv_established()
        if (tcp_fast_parse_options(skb, th, tp) && tp->saw_tstamp &&
            tcp_paws_discard(tp, skb)) {
                if (!th->rst) {
                        NET_INC_STATS_BH(PAWSEstabRejected);
                        tcp_send_dupack(sk, skb);
                        goto discard;
                }
                /* Reset is accepted even if it did not pass PAWS. */
        }

Thanks
Sridhar