Adam Osuchowski and Tomasz Dubinski have sent out an advisory
regarding a new vulnerability in
the 2.6 netfilter subsystem. Netfilter, being the Linux firewalling code,
inspects network packets and makes decisions on which ones to pass on. Use
of netfilter is supposed to increase security, so it is always discouraging
when the opposite happens. Fortunately, the number of sites vulnerable to
this particular bug should be fairly small.
TCP packets can contain an "options" field within the header. This field
allows TCP implementations to change how the protocol works; options can be
used to turn on features like selective acknowledgments, change how
checksumming is done, and so on. Each option has a simple format:
||'Length' bytes of data
Multiple options can be packed into the field; an option number of zero
terminates the list.
If netfilter is asked to filter packets based on the contents of the TCP
options field, it goes into a loop stepping through each option present in a
packet. Unfortunately, it treats the length byte as a signed quantity; the
result is that, with an option number greater than 128, netfilter's index
into the options field can be pushed backward, and the code can end up in
an infinite loop. That tends to slow packet delivery somewhat.
The fix is straightforward: declare the options array as unsigned.
The good news is that, in all likelihood, very few firewalls filter on the
TCP options field, and, of those, most have probably not yet been upgraded
to 2.6. The bad news is that there are almost certainly many other bugs in
the kernel (and elsewhere) caused by confusion between signed and unsigned
types. These vulnerabilities can be hard to find without detailed, tedious
auditing. And some of them, certainly, will have a larger impact than this
to post comments)