Monday, January 17, 2005

Most of it can be stopped now

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.

Race/non-tmpfiles:  1
Lack of environment checks:  2
Integer Overflows:  5
Bad malformed data handling:  7
Buffer Overflows: 27
Race/tmpfiles: 11
Generic/Design:  5
Kernel (generic):  5
Kernel (BV):  1

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.

2 Comments:

Blogger wow power leveling said...

Why was there no follow on bankruptcy then? The bailout of AIG FP went to (wow power leveling) hedge funds that bound credit swaps on Lehman failing or others betting on rating (wow power leveling) declines. AIG has drained over 100 billion from the government. Which had to go to those who bet on failures and downgrades. Many of whom (power leveling)were hedge funds. I-banks that had offsetting swaps needed the money from the AIG bailout or they would have been caught. Its an (wow powerleveling) insiders game and it takes just a little bit too much time for most people to think (wow gold) through where the AIG 100 billion bailout money went to, hedge funds and players, many of whom hire from the top ranks of DOJ, Fed, Treasury, CAOBO
wow goldwow goldwow goldwow gold CAOBO

9:53 PM  
Blogger office said...

The Tax Return Crack-Up<4>
Realizing he might have dug himself in there,Microsoft Office 2010the general emphasized that Office 2010he had spent some time as a junior Office 2007officer working "very closely Microsoft Officewith the Israeli air force" and that heMicrosoft Office 2007had found that "more cosmopolitan,Office 2007 key liberal version of the Israeli population" Office 2007 downloadto be just chock full Office 2007 Professionalof that sort of "goodwill" necessary Windows 7to give a bunch of land back Microsoft outlook 2010to the Palestinians.

4:13 AM  

Post a Comment

<< Home