Digg this story   Add to del.icio.us   (page 1 of 2 ) next 
OpenBSD's network stack
Federico Biancuzzi, 2005-10-12

SecurityFocus interviews three OpenBSD developers about their network stack protection against DoS ICMP attacks, a short comparison with Linux' stack, and some thoughts on OpenBGPD.

On November 1st, OpenBSD 3.8 will be released. This is the first release that includes protections against some old and simple DoS attacks via ICMP. How do these protections work?

Fernando Gont: First of all, I'd like to make a comment on that of "old attacks." The attacks are old, but there have never been proposals on how to deal with them. So we are talking about old attacks which are still current. If you look at NISCC's or CERT/CC's vulnerability report, you'll see that virtually every vendor/system is affected by either all or some of these ICMP attacks. It's 2005, and most systems are still vulnerable to ICMP-based attacks. Scary, isn't it?

There are basically three different attacks that can be performed against TCP by means of ICMP: blind connection-reset attacks, blind throughput-reduction attacks, and blind-performance degrading attacks. There are general counter-measures that you can implement for ICMP-based attacks, and attack-specific ones. In OpenBSD, we implement both.

The general counter-measures are based on performing checks on the received ICMP messages. Basically, we check that the TCP sequence number contained in the ICMP payload corresponds to data already sent but not yet acknowledged. The rationale is obvious: if the TCP sequence number contained in the ICMP payload corresponds to data already sent but already acknowledged, then the error message must have been forged, caused by an old TCP segment, or corrupted, and thus should not be honored. If the TCP sequence number contained in the ICMP payload corresponds to data not yet sent, then the error message must have been forged, or corrupted, and thus should not be honored, either.

This is a general validation check for ICMP messages. However, it doesn't eliminate the vulnerabilities: it just requires more work (or luck) on the side of the attacker. Therefore, in OpenBSD we implement, in addition to this general validation check, attack-specific counter-measures that completely eliminate the vulnerabilities.

The blind throughput-reduction attack is performed by means of ICMP Source Quench messages. These messages were originally introduced for flow control and congestion control in IP networks. An attacker can use ICMP Source Quench messages to fool the attacked host into thinking the network is congested, and as a result, the attacked system will reduce the rate at which it is sending information. However, if you look at it carefully, TCP implements its own flow-control mechanism, and thus does not rely on ICMP Source Quench messages for performing flow-control. Also, ICMP Source Quench messages have been considered for a long time to be ineffective and unfair for controlling congestion. Thus, the counter-measure for the blind throughput-reduction attack is very simple: ignore ICMP Source Quench messages meant for TCP connections.

The blind performance-degrading attack is an attack against the Path-MTU Discovery mechanism implemented by TCP. Basically, an attacker will send a "fragmentation needed and DF bit set" ICMP error message that advertises a small Next-Hop MTU to the victim host, to fool it into thinking it is sending packets that are too large to be forwarded without fragmentation. As a result, the attacked system will reduce the size of the packets it sends, accordingly.

The counter-measure we implement for this attack works as follows. First, we keep track of the largest packet size that has so far been sent for this connection. If the Next-Hop MTU claimed by the ICMP error message is larger than that size, then we simply ignore the error message. Second, we keep track of the largest packet size that has so far been acknowledged for this connection (say, "maxsizeacked"). This allows us to divide Path-MTU Discovery into two phases: Initial Path-MTU Discovery, and Path-MTU Update. This two-phase separation allows us to quickly discover the Path-MTU for a fresh connection (and thus not affect interactive applications), while still being resistant to the discussed attack.

Whenever we receive an ICMP "fragmentation needed and DF bit set" (and provided it has passed all the general validation checks), we compare the advertised Next-Hop MTU with "maxsizeacked". If it's larger than "maxsizeacked", then it means we are in the Initial Path-MTU phase (that is, we are trying to find out the Path-MTU of this connection for the first time), and thus honor the ICMP message immediately. If the advertised Next-Hop MTU is smaller than "maxsizeacked", then it means we are in the Path-MTU Update phase, trying to change the assumed Path-MTU for this connection. In this phase, we should be much more cautious when processing ICMP messages. The error messages could be legitimate (and sent because the packets that correspond to the connection are now being forwarded through a different Internet path), or they could be part of an attack. If the error messages were legitimate, then the corresponding data (those claimed by the TCP sequence number contained in the ICMP payload) should have been dropped by the Internet router that sent the ICMP error message. Therefore, we wait for an RTO (TCP's retransmission timeout), and see if the corresponding data gets acknowledged. If the corresponding data times out, then it means the error message must be legitimate, and thus we honor it, updating the Path-MTU for the connection accordingly. If while we are waiting for a RTO those data get acknowledged, then it means our data are still getting to the remote system, and thus the ICMP error message must have been forged. Therefore, we simply drop the ICMP error message we had received.

The implication of this counter-measure is that in order to perform the blind performance-degrading attack, the attacker should be a "man in the middle," and should be not only lucky enough to hit the TCP window, but should also be able to selectively drop the packets that correspond to the attacked connection. This is so that either the data segments don't get to the remote endpoint, or the TCP acknowledgements sent by the remote end-point don't get [to] the attacked system. If an attacker were able to do this, he would have already DoS'ed the connection, and thus wouldn't have the need to perform the attack.

As for the blind connection-reset attack, BSD-derived implementations are not vulnerable to it. BSD-derived systems never abort established connections in response to ICMP messages. This has been the traditional BSD behavior for quite a long time.

Is there already any other OS that includes them?

Fernando Gont: OpenBSD has been the first operating system to implement a complete set of counter-measures for ICMP-based attacks. Following OpenBSD, NetBSD fortunately ported OpenBSD's counter-measures to their system.

Other systems have followed us, implementing only some of the OpenBSD counter-measures. Unfortunately, it seems they have failed to understand the importance of the counter-measure for the blind performance-degrading (PMTUD) attack. Some vendors/projects simply seem to think that the TCP sequence number check is enough to protect a system from this attack. Others simply wanted to see a working (and tested) implementation, and were not willing to take the lead. At the c2k5 Hackathon we implemented the counter-measure for the PMTUD attack, and tested it extensively. So there I think are no more excuses to vendors: they can follow us, or continue ignoring the problem.

What about Linux?

Fernando Gont: In the same way as BSD-derived systems, they were already treating the so-called ICMP "hard errors" as "soft errors," so they were not vulnerable to the ICMP-based blind connection-reset attack.

Linux had also been implementing the basic TCP sequence number check for several years.

When I published my IETF internet-draft "ICMP attacks against TCP," they removed support for ICMP Source Quench messages, as recommended in my draft. They were very responsive on this particular fix.

However, they have not yet implemented the full counter-measure for the PMTUD attack. They basically said they first wanted the counter-measure to be tested. So maybe that now that OpenBSD ships with this counter-measure, and that NetBSD has followed us, they will finally implement it.

The counter-measure for the PMTUD attack is particularly important. First, because those ICMP messages used for PMTUD are probably the only ones you cannot filter. Second, because even if you protect your TCP connections by means of the TCP MD5 option, or by means of IPSec, you still need the Path-MTU Discovery mechanism. And, at that point, PMTUD becomes "the weakest link in the chain".

There are scenarios in which IPSec-secured connections could get frozen by means of the PMTUD attack. If you count the number of bytes required for headers (IP+IPSec+TCP), along with the number of bytes required for IP and TCP options, and realize that the minimum IPv4 MTU is 68 (i.e., a "fragmentation needed and DF bit set" ICMP message can report a Next-Hop MTU as small as 68 bytes), you come to the conclusion that the attacked connection could become frozen, or the TCP/IP stack may end up behaving in some unexpected manner.

I must acknowledge that Alan Cox and David S. Miller read the draft, and took the time to provide feedback and contribute to make my internet-draft a better one. This is something I appreciate. Most other vendors/projects didn't care to provide feedback, or anything.

Story continued on Page 2 



Federico Biancuzzi is freelancer; in addition to SecurityFocus he also writes for ONLamp, LinuxDevCenter, and NewsForge.
    Digg this story   Add to del.icio.us   (page 1 of 2 ) next 
Comments Mode:
OpenBSD's network stack 2005-10-14
Anonymous (1 replies)
Re: OpenBSD's network stack 2005-10-14
Anonymous (1 replies)
Re: Re: OpenBSD's network stack 2005-10-15
Anonymous (1 replies)
OpenBSD's network stack 2005-10-14
Miguel Hernandez y Lopez
Ryan seems to be misinformed 2005-10-15
Anonymous (1 replies)
Re: Ryan seems to be misinformed 2005-10-19
Anonymous (2 replies)
Re: Re: Ryan seems to be misinformed 2005-10-20
Anonymous (1 replies)
Re: Re: Ryan seems to be misinformed 2005-10-22
Anonymous (1 replies)


 

Privacy Statement
Copyright 2010, SecurityFocus