TCP-RST Vulnerability - Doubt

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

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]>,

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.

Breaks with eBGP multi-hop so you have to adjust as required there.

--cw

* Miquel van Smoorenburg:

Well, there was quite some technology push recently. 8-)

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.

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

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:

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:

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.

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.

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

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.

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

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.

5

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

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:

30% to 40% is extremely high. Are you sure these numbers are correct?

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:

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

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

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