To aid the Hardened Debian project, I wrote up an analysis of the Ubuntu Security Notice list. The results are nice to look at, and a blog on them is deserved. It appears that most USNs contain vulnerabilities which can be decreased to Denial-of-Service attacks, precluding any privilege escallation with simple crashes.
Below is a table aggregating the analysis of the first 60 USNs. Blue bars show vulnerabilities which trigger available protections if used for an exploit. Red bars show things that I don't yet know of anything that protects against them.
|Lack of environment checks:||2|
|Bad malformed data handling:||7|
The arrangement of the above graph is deliberate; it illustrates that security vulnerabilities are normal.
By using a combination of PaX, GrSecurity (which supplies PaX), and The IBM Stack Smash Protector, threats in approximately 81.7% of notices can be mitigated. This leaves us with 23.3% of the notices containing threats we can't mitigate. The 105% total stems from the fact that notices contain multiple vulnerabilities in some cases, often of different classes.
The most distressing thing I've encountered during this task was that there are an increasing number of kernel vulnerabilities. Up to USN #55-1, there were 5 kernel vulnerability notices total, accounting for 5.4% of notices. Between USN #55-1 and #60-1, the number of kernel vulnerability notices doubled. With the extra three kernel vulnerability notices, a smooth 10% of USNs now involve kernel exploits.
Kernel exploits, for the most part, cannot be protected against proactively. When they can, the protection involves detecting the attack and panicing the kernel, bringing the entire system down. This means that we can't rely on proactive security in the kernel, because the results aren't even remotely acceptable as a temporary fix. Unless there's extremely confidential information on site, an easy DoS to take down the system isn't much better than an intrusion, though marginally it may very well be.
The problem, however, is not that the only protection we can afford is wildly disruptive; but that we'll never be able to protect against all kernel bugs. This coupled with the accelerating rate of kernel security vulnerabilities creates a looming cloud of evil surrounding the Linux kernel. We must prevent bugs from happening.
The only way to fix kernel bugs is to audit the kernel, find them, and destroy them. Various audit projects exist; and they need to keep a portion of their focus on the Linux kernel and entering patches. It may be most prudent to devote a predetermined level of resources specifically to Linux kernel source code auditing.
This again ties into something I've blogged before. I had given reasons on switching to a new kernel development model, and even made a loose outline of a potential simple change to create an enterprise-ready development model based on the current model. I believe now that some change may be in order.
The change to my previous suggestions on a new model is quite simple. Upon release of a fresh Stable tree--for our example, let's say 2.8--the tree would be dubbed 2.8.0-audit0. An audit group would make a pass at all of the patches that have gone in between 2.6 and 2.x.0 and periodically release any security fixes they found to be needed. Once the audit pass was finished and the audit group was satisfied, 2.8.0-audit(a) would finally be released as 2.8.0.
This would delay an official x.y.0 release; however, the pre-audit releases would be for the most part Stable-ready, in the same sense that every 2.6 point release is considered "stable" now. Distributions and external audit groups would predictably chip in to accelerate the audit process as well. Adventurous desktop users and developers could get straight to work on the -audit0 release anyway.
The reason for using -audit rather than simply doing periodic point releases is that with point releases, it is not obvious when a single audit pass has finally been made. The audit may be finished in .1, .5, or .15, depending on how many bugs are found and how often they incur a new point release.
Many security issues can be handled now with technology we have available. I'm predicting that Ubuntu Linux will be rolling out a high-security distribution within a year; however, it could go longer than that. Still, the threat of kernel security vulnerabilities cannot be easily mitigated, and remains the most severe threat any system can face.