Hi,
I am a graduate research student majoring in the field of
Computer Networking.As part of my research I have sorted out what FreeBSD has
done to overcome the TCP-RST vulnerability (by modifying the stack to accept
the RST packets only with the current + 1 sequence number and ignoring the
rest, even if their sequence numbers fall within the receiving window).
Could you kindly share your views regarding what Linux has done to its stack
to overcome this vulnerability as it will be of great help to my research.
Thanks,
Sai Prathap
On Fri, 25 Jun 2004 15:20:50 -0600
saiprathap <[email protected]> wrote:
> I am a graduate research student majoring in the field of
> Computer Networking.As part of my research I have sorted out what FreeBSD has
> done to overcome the TCP-RST vulnerability (by modifying the stack to accept
> the RST packets only with the current + 1 sequence number and ignoring the
> rest, even if their sequence numbers fall within the receiving window).
>
> Could you kindly share your views regarding what Linux has done to its stack
> to overcome this vulnerability as it will be of great help to my research.
We have done nothing, and there are no plans to implement any workaround
for this problem.
RFC2385 MD5 hashing support is going in soon, and for the application where
the vulnerability actually matters (BGP sessions between backbone routers)
MD5 clears that problem right up and they're all using MD5 protection already
anyways.
David S. Miller wrote:
>>Could you kindly share your views regarding what Linux has done to its stack
>>to overcome this vulnerability as it will be of great help to my research.
>
>
> We have done nothing, and there are no plans to implement any workaround
> for this problem.
>
> RFC2385 MD5 hashing support is going in soon, and for the application where
> the vulnerability actually matters (BGP sessions between backbone routers)
> MD5 clears that problem right up and they're all using MD5 protection already
> anyways.
Now you got me curious :-)
I have not seen anything conclusive on this yet. How sensitive is Linux
to the attack? Some say it deals with it better than others did before
they got "fixed", but with no hard evidence or a sensible explanation.
Lets assume you're on a FastEthernet pipe capable of delivering 144kpps.
How "hard" would it be to exploit it in such a scenario, given we know
the source port and approximate system time used on one of the ends?
Sure, on a FastEthernet your pipe is toast if someone really wants your
arse anyway, but you don't want connections over other pipes, or
internally, to die during such an attack.
--
Cheers,
Andr? Tomt
In article <[email protected]>,
David S. Miller <[email protected]> wrote:
>RFC2385 MD5 hashing support is going in soon, and for the application where
>the vulnerability actually matters (BGP sessions between backbone routers)
>MD5 clears that problem right up and they're all using MD5 protection already
>anyways.
MD5 protection on BGP sessions isn't very common yet. MD5 uses CPU,
and routers don't usually have much of that. Which means that now an
MD5 CPU attack is possible instead of a TCP RST attack.
The "TTL hack" solution is safer. Make sure sender uses a TTL
of 255, on the receiver discard all packets with a TTL < 255.
You can use iptables to implement that on a Linux box.
Mike.
On Mon, Jun 28, 2004 at 01:22:37PM +0000, Miquel van Smoorenburg wrote:
> The "TTL hack" solution is safer. Make sure sender uses a TTL of
> 255, on the receiver discard all packets with a TTL < 255. You can
> use iptables to implement that on a Linux box.
Breaks with eBGP multi-hop so you have to adjust as required there.
--cw
* Miquel van Smoorenburg:
> MD5 protection on BGP sessions isn't very common yet.
Well, there was quite some technology push recently. 8-)
> MD5 uses CPU, and routers don't usually have much of that. Which
> means that now an MD5 CPU attack is possible instead of a TCP RST
> attack.
Anything that is able to send packets to the CPU which runs the TCP
stack can take down your router. Core routers with 200 MHz MIPS CPUs
are still common. It really doesn't matter much if you have to do a
MD5 check or not, the CPU will be easy to overload. However, the TCP
MD5 option is a nice thing to have because you can enable it and avoid
discussions (just like you do it with antivirus software 8-/).
Part of the beauty of the TTL hack is that it actually works in
linecard CPUs or ASICs on some routing architectures, which takes the
load off the main CPU. For Linux, you can also drop the packets
before they hit the route cache, which might be become more important
in the future when the route cache is no longer used for forwarding.
On Mon, Jun 28, 2004 at 01:22:37PM +0000, Miquel van Smoorenburg wrote:
>
> MD5 protection on BGP sessions isn't very common yet.
The Cisco routers we deployed 3.5 years ago were already configured with MD5
enabled on BGP, this was on IOS 12.0 at this time. And I guess that Cisco
still has a good share amongst the BGP setups.
> MD5 uses CPU,
> and routers don't usually have much of that. Which means that now an
> MD5 CPU attack is possible instead of a TCP RST attack.
MD5 is not that much expensive. I even wonder if all those new routers
with VPN hardware acceleration, MD5 could not be computed in hardware
at nearly no cost.
> The "TTL hack" solution is safer. Make sure sender uses a TTL
> of 255, on the receiver discard all packets with a TTL < 255.
> You can use iptables to implement that on a Linux box.
This will not work in an eBGP multi-hop setup. However, you can often
still discard packets with a TTL < 252 or something like that, which
might imply a packet from outside the provider's area.
But the real problem is that the provider should do the anti-spoofing
himself and not accept BGP packets from the wrong NIC ! And it's relatively
easy to show them where they're bad.
Regards,
Willy
* Andre Tomt:
> I have not seen anything conclusive on this yet. How sensitive is
> Linux to the attack?
The original RST-based attack was against a mixed Cisco/Linux+Quagga
environment, IIRC. This combination is especially vulnerable if the
BGP connection is established in the right direction.
However, nobody has probably bothered to replicate that attack in the
lab. As published, the attack just doesn't work against Cisco/Cisco
peerings. Unfortunately, there is another that *might* actually work,
that's why there was so much fuss about it.
If you have some window checking bugs (like the BSDs had), it can be
quite worse, of course. But such issues are usually way overrated.
Most DoS potential remains unexploited anyway, and I don't think the
disruption from people frantically enabling the TCP MD5 option payed
off in the end.
* Willy Tarreau:
> On Mon, Jun 28, 2004 at 01:22:37PM +0000, Miquel van Smoorenburg wrote:
>>
>> MD5 protection on BGP sessions isn't very common yet.
>
> The Cisco routers we deployed 3.5 years ago were already configured with MD5
> enabled on BGP, this was on IOS 12.0 at this time. And I guess that Cisco
> still has a good share amongst the BGP setups.
Software deployed /= configured & enabled.
One of the main problems with the TCP MD5 option is that it requires a
password which has to be negotiated by the peers. This adds a
non-trivial management burdern.
> MD5 is not that much expensive. I even wonder if all those new routers
> with VPN hardware acceleration, MD5 could not be computed in hardware
> at nearly no cost.
If the packet is still handled by a real CPU (which is very likely the
case given the complexity of the protocols involved), it will still
overload.
> But the real problem is that the provider should do the
> anti-spoofing himself and not accept BGP packets from the wrong NIC
> ! And it's relatively easy to show them where they're bad.
In this case, the anti-spoofing has to happen at the other side, to
protect you. There is an anomaly in Cisco ACLs you could exploit to
implement this without too much management overhead, *but* filtering
on core routers still problematic.
However, experience tells us that there is little incentive for others
to invest some work to protect you, and that it doesn't happen in
general. 8-(
On Mon, Jun 28, 2004 at 01:22:37PM +0000, Miquel van Smoorenburg wrote:
> MD5 protection on BGP sessions isn't very common yet. MD5 uses CPU,
> and routers don't usually have much of that. Which means that now an
> MD5 CPU attack is possible instead of a TCP RST attack.
Not if the MD5 option is properly implemented - i.e. MD5 hash checking
is done AFTER the packet is considered valid in terms of "fitting"
sequence number.
> The "TTL hack" solution is safer. Make sure sender uses a TTL
> of 255, on the receiver discard all packets with a TTL < 255.
It's a hack, not a solution. A solution works always, not just in
some special cases (and given Cisco's implementation, even there
is a window which is "too wide open").
As this thread is fairly off-topic on lkml, I suggest moving it to
somewhere else... But then again, in the appropriate places, these
discussions have already taken place. :-)
Regards,
Daniel
At 01:05 AM 27/06/2004, David S. Miller wrote:
> > Could you kindly share your views regarding what Linux has done to its
> stack
> > to overcome this vulnerability as it will be of great help to my research.
>
>We have done nothing, and there are no plans to implement any workaround
>for this problem.
the vulnerabilities are real for any application/protocol which makes use
of long-duration TCP sessions.
the most common place that people have found the vulnerability to be of use
is in killing BGP sessions.
protocols which make use of long-held TCP sessions such as NFSv3, irc,
nntp, telnet, ssh, X11 et al are just as vulnerable.
cheers,
lincoln.
On Mon, 28 Jun 2004 21:26:07 +0200, Florian Weimer said:
> > The Cisco routers we deployed 3.5 years ago were already configured with MD
5
> > enabled on BGP, this was on IOS 12.0 at this time. And I guess that Cisco
> > still has a good share amongst the BGP setups.
>
> Software deployed /= configured & enabled.
>
> One of the main problems with the TCP MD5 option is that it requires a
> password which has to be negotiated by the peers. This adds a
> non-trivial management burdern.
The latest numbers I saw on the NANOG list estimated that only 30% to 40% of
core peerings were using MD5 even several weeks after the Great MD5-Fest...
> If the packet is still handled by a real CPU (which is very likely the
> case given the complexity of the protocols involved), it will still
> overload.
I am told that at least some versions of IOS got it Very Very Wrong - rather
than first checking the simple things like "is the source/dest addr/ports/seq
on the RST in bounds?" or "is a BGP packet?", it would check the MD5 *first* -
meaning you could swamp the real CPU by sending it a totally bogus stream of
allegedly MD5-signed traffic.. which of course would induce a route flap
when the CPU fell too far behind... ;)
* Valdis Kletnieks:
> The latest numbers I saw on the NANOG list estimated that only 30%
> to 40% of core peerings were using MD5 even several weeks after the
> Great MD5-Fest...
30% to 40% is extremely high. Are you sure these numbers are correct?
> I am told that at least some versions of IOS got it Very Very Wrong
> - rather than first checking the simple things like "is the
> source/dest addr/ports/seq on the RST in bounds?" or "is a BGP
> packet?", it would check the MD5 *first* - meaning you could swamp
> the real CPU by sending it a totally bogus stream of allegedly
> MD5-signed traffic..
I think the MD5 option is designed to be processed *before* semantic
analysis of the TCP header. This way, it will protect the router in
case of TCP header parsing bugs. So it's not "Very Very Wrong", just
a different trade-off.
* Lincoln Dale:
> the vulnerabilities are real for any application/protocol which makes
> use of long-duration TCP sessions.
... *and* which hasn't got fast recovery from connection loss.
For example, NNTP uses long-lived TCP connections, but it is NOT
vulnerable because restart is very cheap.
Given the other benefits of fast recovery, it's better to concentrate
on that than to tack something on the TCP stack which only solves a
tiny subset of the problems (which isn't even relevant in practice).
* Daniel Roesen:
> Not if the MD5 option is properly implemented - i.e. MD5 hash checking
> is done AFTER the packet is considered valid in terms of "fitting"
> sequence number.
In this case, you trade robustness against network load for robustness
against implementation errors. I'd rather not to have to make this
choice. 8-/
On Tue, 29 Jun 2004 23:22:56 +0200, Florian Weimer said:
> * Valdis Kletnieks:
>
> > The latest numbers I saw on the NANOG list estimated that only 30%
> > to 40% of core peerings were using MD5 even several weeks after the
> > Great MD5-Fest...
>
> 30% to 40% is extremely high. Are you sure these numbers are correct?
Well, here's the start of the thread...
http://www.merit.edu/mail.archives/nanog/2004-05/msg00144.html
Anywhere from 12% to 45% depending which methodology you believe in.. ;)
> I think the MD5 option is designed to be processed *before* semantic
> analysis of the TCP header. This way, it will protect the router in
> case of TCP header parsing bugs. So it's not "Very Very Wrong", just
> a different trade-off.
I saw several people who dropped hints that if it had an MD5 on it,
it got handed to the CPU for checking, without even bothering to verify
that the source IP was something you had an MD5 configured for.. "Hey, this
MD5 is borked! Good thing it's not from a host we talk to...." :)