|
http://lwn.net/Articles/296929/ Kernel security, year to date Earlier this year, your editor asked a high-profile kernel developer, in a public discussion at a conference, about the seemingly large number of kernel-related security bugs. Was the number of these vulnerabilities of concern, and what was being done about it? The answer that came back was that security issues aren't a huge concern, that most of the reported issues were obscure local exploits requiring the presence of specific hardware. Serious issues, like the vmsplice() vulnerability, are rare.More recently, as part of the panic associated with getting a talk together for the Linux Plumbers Conference, your editor decided to take a closer look at kernel vulnerabilities. It turns out that there are, in fact, quite a few of them. The vulnerabilities which have been given CVE numbers in 2008 (so far) are:
That is 41 CVE numbers (so far) for 2008 - not a small number. Fully 1/3 of these vulnerabilities were in the networking subsystem, which is scary: this is the most likely place to find remotely-exploitable problems in the kernel. It is true that sites not running SCTP or DCCP can forget about many of those, and IPv6 is responsible for a few of the rest, so most of those vulnerabilities were not a concern for most sites. Many of the remaining vulnerabilities were in the core kernel or in architecture-specific code. The number of vulnerabilities found in drivers - the part of the kernel which has long been sneered at as containing the worst code - is actually quite small. On the other hand, four of the CVE-listed vulnerabilities (the Xen, AppArmor, and utrace problems) were caused by out-of-tree code added by distributors. There is no way to know how many vulnerabilities were fixed without obtaining a CVE number - or without even realizing that a vulnerability existed in the first place. When a single program is responsible for this many vulnerabilities, it makes sense to ask why. The kernel, of course, is a very large program; more code means more bugs, some of which will have security implications. Beyond that, though, the kernel runs in a special, privileged environment. Flaws which would simply be fixed as just-another-crash in a normal application are denial-of-service vulnerabilities in the kernel - or worse. So a larger number of vulnerabilities in the kernel does not, by itself, imply that the kernel's code is worse than that of other programs; it only reflects the fact that the consequences of kernel bugs tend to be more severe. The discovery (and repair) of vulnerabilities does not necessarily imply that our current process is creating a lot of vulnerabilities; it could be that we are mostly fixing older problems. If the developers are fixing vulnerabilities more quickly than they are adding more, life should be good in the long run. The vulnerabilities in the list above vary from those which are very old (affecting 2.4 kernels too) to some which are very new (the UVC driver was added in 2.6.26). Some of them are in code which, while being intended for the mainline, has not yet been merged. It is probably impossible to say whether security problems are being fixed more quickly than they are being created, but one thing is clear: all of that code flowing into the mainline is bringing a certain number of security problems with it. For that reason, it is a little discouraging that there is little work being done in the kernel community with the explicit goal of improving the security of the kernel. Few patches are reviewed with security issues in mind; the vmsplice() vulnerability, as one example, was a clear failure of the review process. There are undoubtedly many people who are doing fuzz testing and such - some of them are even the good guys - but much of the formal testing going on seems aimed more at API conformance than at security verification. There must be more work going on behind the scenes, but it is still hard to avoid a sense of a certain amount of complacency with regard to security issues. As a community, we take pride in the security of our system. But one vulnerability per week is not the most inspiring security record. It would be good to find a way to do better than that. Better tools must be a part of the solution, but more thorough code review is also needed. There still is no substitute for a pair of eyeballs looking for ways in which new code might be subverted. Asking for more security-oriented review seems ambitious when code review is already one of the biggest bottlenecks in the development process. But the alternative would appear to be to continue to add to our collection of CVE numbers. Page editor: Jonathan Corbet |
