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
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.
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
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
> 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.
IETF released the following draft with possible fixes:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
cheers,
- Fabian
On Wed, 21 Apr 2004 19:03:40 +0200
J?rn Engel <[email protected]> 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.
On Wed, 21 Apr 2004 19:27:01 +0200
"Fabian Uebersax" <[email protected]> wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
Anyone who recommends responding to a RST packet, does not
understand TCP very well.
"David S. Miller" <[email protected]> writes:
> On Wed, 21 Apr 2004 19:27:01 +0200
> "Fabian Uebersax" <[email protected]> wrote:
>
>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
>
> Anyone who recommends responding to a RST packet, does not
> understand TCP very well.
This was my thought as well. Surely you don't want to deploy such a
drastic change to the TCP state engine after just so little
investigation.
In the confined environment of BGP peerings, the risks can be
controlled (RSTs are typically rate-limited on the receiving end
anyway, for example). On the net as a whole, you have to be
compatible with all implementations ever written. If some
implementation replied to the ACK cookie with another RST with an
suitable sequence number, there might be a few issues.
(BTW, TCP connections used for BGP typically have port numbers from a
very small set. So there is no additional randomness from that which
offers any additional protection.)
--
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.
Hi,
On Wed, Apr 21, 2004 at 11:39:26PM +0200, Florian Weimer wrote:
> "David S. Miller" <[email protected]> writes:
>
> > On Wed, 21 Apr 2004 19:27:01 +0200
> > "Fabian Uebersax" <[email protected]> wrote:
> >
> >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
> >
> > Anyone who recommends responding to a RST packet, does not
> > understand TCP very well.
This might quickly lead to very funny loops :-) I don't think that they have
taken into account every situation (dynamic IP re-assignment to someone else
during established session, address translation, sequence randomization a la
openbsd or ippersonality, ...). I even have the feeling that they don't
distinguish between SYN and SYN/ACK...
This "vulnerability" as they call it has nothing new: around 1996, I've
played with a tool named "juggernaut" which exploited this TCP feature to
close sessions. It was designed as a hacking tool, but revealed very useful
to close never-ending sessions on HTTP proxies :-) Some time later, another
one came out too. What is new IMHO is that windows are scaling up and this
article reminds us that we should not confuse a 32 bits sequence number
with a session cookie. I read somewhere that on 10GbE, sequence numbers
are rotating so fast (overflow every 3 seconds) that you are forced to
use timestamps if you don't want to risk to merge late segments. In this
case, the timestamp adds another 32 bits "random" (can we have a per-session
random offset added to timestamps ?).
> This was my thought as well. Surely you don't want to deploy such a
> drastic change to the TCP state engine after just so little
> investigation.
Why? It makes your TCP harder with a 100% money-back warranty :-)
> In the confined environment of BGP peerings, the risks can be
> controlled (RSTs are typically rate-limited on the receiving end
> anyway, for example). On the net as a whole, you have to be
> compatible with all implementations ever written. If some
> implementation replied to the ACK cookie with another RST with an
> suitable sequence number, there might be a few issues.
Well, I hope that some script kiddies will at least try to scan the net
for such crappy border routers if there are some ISP out there stupid
enough to accept spoofed BGP packets. At least, we'll see them (or their
customers) disappear from the net for a few minutes and we will know why ;
They'll get what they deserve ! We all expect a minimum of security on
such access points.
> (BTW, TCP connections used for BGP typically have port numbers from a
> very small set. So there is no additional randomness from that which
> offers any additional protection.)
That's what I was discussing with a collegue of mine. I was wondering if
a cisco always uses the same ports (or nearly the same) after a reboot,
in which case the source port range to be swept would be reduced.
Regards,
Willy
On Wed, 21 Apr 2004, David S. Miller wrote:
> On Wed, 21 Apr 2004 19:03:40 +0200
> J?rn Engel <[email protected]> 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
<[email protected]>
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 <[email protected]> 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
On 21-Apr-2004 David S. Miller wrote:
> On Wed, 21 Apr 2004 19:03:40 +0200
> J?rn Engel <[email protected]> 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.
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 <[email protected]> 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.
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
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
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.
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.
jamal <[email protected]> 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.
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.
>
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 <[email protected]> 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
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
On Thu, 2004-04-22 at 10:37, [email protected] 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
> > > 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
[email protected] 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
On Thu, 22 Apr 2004, Chris Friesen wrote:
> [email protected] 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
[email protected] 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
On Thu, 22 Apr 2004 07:35:54 -0400 (EDT)
"Richard B. Johnson" <[email protected]> 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".
On Wed, 2004-04-21 at 13:20, David S. Miller wrote:
> On Wed, 21 Apr 2004 19:03:40 +0200
> J?rn Engel <[email protected]> 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.
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.
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
Horst von Brand <[email protected]> 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.
On Wed, 21 Apr 2004, David S. Miller wrote:
> On Wed, 21 Apr 2004 19:03:40 +0200
> J?rn Engel <[email protected]> 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
[email protected] 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.
jamal <[email protected]> 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.
> 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
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, [email protected] 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
>
>