November: the month of kernel bugs

A security researcher has proclaimed November to be the 'Month of Kernel Bugs' (MoKB) and is releasing one bug each day to highlight unreported issues with various kernels. The associated web site currently has six separate Linux bugs listed as well as bugs for MacOS, FreeBSD, Solaris and Windows. The project was first announced on the bugtraq mailing list along with a tool that can fuzz various Linux filesystems.

The Linux bugs described are all filesystem related; they were found using the fsfuzzer tool to generate various kinds of improperly formatted filesystem data and to feed it to the Linux filesystem code. This leads to various kinds of kernel problems, mostly crashes. Bugs have been found in several different filesystem types: ext2, ext3, iso9660, cramfs, and squashfs. The vulnerability found for cramfs actually exists in the zlib decompression code and could potentially lead to arbitrary code execution.

While these bugs are fairly serious, they are also fairly difficult to exploit. Other than iso9660, it is rare that a Linux user will mount a filesystem generated by some external, potentially malicious, entity. USB flash drives might provide a vector for exploiting some of these bugs, but users are hopefully savvy enough to be wary of mounting them if they do not know where they came from. Administrators may also remove the ability for regular users to mount filesystems, especially on sensitive machines such as servers.

Kernel bugs that allow arbitrary code execution are particularly serious because they can provide a way to completely take over the system. If an attacker can convince someone to mount a specially crafted cramfs image, they may be able to cause all manner of mayhem with that system. Attacks targeted at a specific person or company would seem to be the biggest concern as it would be somewhat difficult to use as a vector for a widespread infection; the logistics of distributing thousands of USB keychains to create a Linux botnet would be daunting. The money that could be earned by renting out the botnet, however, might be enough for some, especially if they could find a way to do it anonymously.

Two of the reported bugs against Windows wireless drivers would seem to be of little interest to Linux users, but, unfortunately, that is not the case. As mentioned here, Ndiswrapper is often used to provide Linux 'support' for many wireless adapters and, as Dave Jones points out, this makes Linux potentially vulnerable as well. It may be that the vendors release a fix promptly, but until they do, users of those drivers are vulnerable to attack. And, in any case, propagating a fix in a Windows network driver to a substantial portion of its users is not a simple thing to do.

The MoKB announcement mentions the possibility of 'silent fixes' of these problems; at least so far, that does not seem to be happening. Silent fixes are ones that fix a security problem, but in some way obfuscate the security implications of the fix (or, at least, are not accompanied by a security advisory). Proprietary vendors are well known for this kind of behavior, but one would hope open source developers are more, well, open about those kinds of things. The only fix that seems to have made its way into the kernel so far is for a an ext3/ext4 bug that was found prior to the MoKB. It was clearly described as a crash in the patch and the fsfuzzer tool was referenced. It did not specifically mention it as a security problem, but opinions differ on whether denial of service that is not caused externally should be considered a security issue.

While the fixes are not silent, they also do not seem to be very high on anyone's priority list, either. So far, there do not seem to be patches for any of the MoKB reported issues posted to the linux kernel mailing list. The zlib inflate issue, with its memory corruption potential, would seem like one that should be fixed relatively soon even if its exploit potential is low.

So far, MoKB has produced some interesting bugs, especially on other operating systems. We will be keeping an eye out for any others that might have a bigger impact on Linux users and for fixes going into the kernel. November is only half over.