Algorithmic Complexity Attacks and the Linux Networking Code The Linux networking code makes extensive use of hash tables to implement caches to support packet classification. One of these caches, the routing cache, can be used to mount effective denial of service attacks, using an algorithmic complexity attack.The Linux Routing Cache The routing cache (or "dst cache") caches routing decisions for a traffic flow. A traffic flow consists of packets which have the same IPv4 source and destination address and the same TOS value in the IP header. These flows are unidirectional; for a two-way communication, two flows exist, one in each direction. Even if the cache is also called "dst cache" for historical reasons, the cache covers more than just destination addresses. When a packet arrives, the kernel must route it. The IP routing code checks for a suitable traffic flow and reuses the cached routing decisions, if possible. Otherwise, it makes a new routing decision and creates a new traffic flow, by updating the routing cache accordingly. This routing occurs on single-homed host with disabled IP forwarding as well as on full-table routers. The routing cache is implemented as a hash table, in a rather particular way. The bucket count is an integral power of two which is fixed on system boot and scaled according to the amount of physical RAM. The hash function is GF(2)-linear (which means that it is easy to find collisions). Collision chaining is used to store different entries which hash to the same bucket. A garbage collection mechanism ensures that the size of the cache stays below the configured maximum entry count. This entry count is scaled with available system memory, too. Note that there are additional hash tables in the networking code. For example, IP connection tracking adds an additional hash table (which uses a different, but still rather weak hash table).The Attack Our attack is targeted at a host and uses packets with carefully chosen source addresses and TOS values to trigger collisions in the lower bits of the routing cache hash function. (Note that these collisions have nothing to do with colliding packets on the wire.) As a result, all these packets create distinct flows which are stored in a linear list hooked to a single bucket to a hash table. In essence, this reduces the hash table to a linear list, and finding entries becomes extremely expensive when the list is very long. (This effect is detailed in the paper cited below.) The effectiveness of the attack depends significantly on the maximum size of routing cache. As described above, the default maximum size depends on the amount of physical RAM present in the machine. Therefore, machines with more RAM are more vulnerable if they operate in the default configuration. For example, we were able to freeze a machine with four gigabytes of RAM with a stream of about 400 packets per second. (The same machine remained unaffected when we used random source addresses instead of source addresses that lead to collisions in the hash function.) Of course, the hash function is extremely simple, but this is not source of the problem. Even though it is possible to find collisions by solving a rather small system of linear equations over the field of two elements, the main problem results from the fact that the attacker can determine the hash bucket for traffic flows (and send packets based on that information).Countermeasures Red Hat published a security advisory which includes a patch (see below) which changes the hash function to a non-linear, keyed hash function. While the the hash function is not cryptographically strong, it is certainly much more complicated (if not even impossible) for an attacker to trigger collisions. (As an additional protection, the key is changed every ten minutes.) In our experience, the patch, applied to stock Linux 2.4.20, works reasonably well in typical denial of service situations. If you cannot apply the patch and are confronted with an attack of this type, there are two options to protect machines: setting rate limits using iptables, or decreasing the routing cache size. Choosing suitable rate limits is very complicated, so it is not recommended. You can decrease the routing cache size using the /proc interface. (If the total size of the cache is reduced, the maximum length of a collision chain is reduced, too, and this particular attack is no longer possible.) As root, run the following commands:# echo 4096 > /proc/sys/net/ipv4/route/max_size# echo 2048 > /proc/sys/net/ipv4/route/gc_thresh# (On most systems, you can edit /etc/sysctl.conf to make these changes permanent.) However, note that this approach of decreasing the cache size has a severe impact on routing performance if the number of parallel flows processed by the machine exceeds the maximum routing cache size.Frequently Asked Questions * How significant is this problem? The Linux IP stack is not very robust against various types of denial of service attacks. As a result, this problem is unlikely to have any practical consequences. We recommend to apply the patch to fix this problem during routine maintenance and not to change the maximum routing cache size preventively because of the potential performance impact. * Are other vendors affected by the problem? At this time, we do not believe that Cisco IOS routers or machines running Solaris or one of the BSD variants are affected. However, only source code inspection can reveal if a product is affected, and vendors are encouraged to verify that their products are unaffected. Flow-based routing using hash tables is particularly prone to this vulnerability, and implementations of this principle should therefore be scrutinized. * Is exploit code available publicly? To our knowledge, this kind of attack is currently (May 2003) not in the wild, and no widely available attack tools support it. * Does this attack affect only affects routers? No, it is also relevant for hosts. The routing cache includes both source and destination addresses, and it is possible to spoof source addresses accordingly. However, routers are at somewhat greater risk because to attack them, you can choose the destination addresses in a way that trigger collisions which does not require root privileges (or special IP packet generation code) on the attacking host. * I've read that it is impossible to spoof source addresses on the current Internet, thanks to ingress filtering, so this attack is not a problem, right? While proper ingress (and egress) filtering is a standard practice to reduce source address spoofing, it isn't universally applied throughout the Internet. A lot of denial of service attacks still use spoofed source addresses and arrive at the intended victim. * Is it possible to use rate limits to counter the attack? It is possible, but not recommended. To protect machines which large amounts of memory in default configurations, ridiculously low rate limits would be required which would enable denial of service attacks on their own. Note that all rate limits which protect the routing cache have to be applied in the PREROUTING chain, as the standard INPUT chain is processed after a packet has already updated the routing cache. * Netfilter connection tracking uses a huge hash table as well. Is it affected? Yes, we believe that it is affected by the essentially same problem. The Red Hat patch corrects Netfilter connection tracking, too. * Will the Red Hat patch fix other performance issues with the routing cache? Unfortunately, the answer is no. We now have multiple reports that Linux routers break down according to the inefficiency of the routing cache under stress, at incredible low packet rates. These problems continue to exist and are likely to persist until the kernel developers eliminate the routing cache. * Why took it so long before this bug was fixed? Kernel developers were contacted at the beginning of April, when the issue was independently discovered in the Linux kernel, not in February, when the first technical report was written by Scott Crosby and Dan Wallach.References * Scott A. Crosby, Dan S. Wallach, Denial of Service via Algorithmic Complexity Attacks <http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/index.html> * Red Hat, Updated 2.4 kernel fixes security vulnerabilities and various bugs <https://rhn.redhat.com/errata/RHSA-2003-172.html> * The patch for Linux 2.4.20 that has been published by Red Hat <http://www.enyo.de/fw/security/notes/linux-2.4.20-nethashfix.patch> * Most current version of this document <http://www.enyo.de/fw/security/notes/linux-dst-cache-dos.html>
