About

This page contains a single entry from the blog posted on March 26, 2007 1:09 PM.

The previous post in this blog was UK Online banking fraud increases from £23.2m in 2005 to £33.5m in 2006.

The next post in this blog is User registration and fake passports.

Many more can be found on the main index page or by looking through the archives.

« UK Online banking fraud increases from £23.2m in 2005 to £33.5m in 2006 | Main | User registration and fake passports »

Game over and verifiable operating systems

Joanna Rutkowska today published a VERY INTERESTING blog "The Game is Over". In it, she examines the challenges of determining "Verifiable Operating Systems". The bog is definitely worth a read.

She examines the current alternatives to determine if your operating system kernel has been compromised or not by a rootkit malware attack. She proposes three ways of doing this:

"1. One generic solution is to build in a prevention technology into the OS. That includes all the anti-exploitation mechanisms, like e.g. ASLR, Non Executable memory, Stack Guard/GS, and others, as well as some little design changes into OS, like e.g. implementation of least-privilege principle (think e.g. UAC in Vista) and some sort of kernel protection (e.g. securelevel in BSD, grsecurity on Linux, signed drivers in Vista, etc)."

"2. Another approach is to dramatically redesign the whole OS in such a way that all components (like e.g. drivers and serves) are compartmentalized, e.g. run as separate processes in usermode, and consequently are isolated not only from each other but also from the OS kernel (micro kernel). The idea here is that the most critical components, i.e. the micro kernel, is very small and can be easily verified. Example of such OS is Minix3 which is still under development though."

"3. Alternative approach to the above two, which does not require any dramatic changes into OS, is to make use of so called sound static code analyzers to verify all sensitive code in OS and applications. The soundness property assures that the analyzer has been mathematically proven not to miss even a single potential run time error, which includes e.g. unintentional execution flow modifications. The catch here is that soundness doesn’t mean that the analyzer doesn’t generate false positives. It’s actually mathematically proven that we can’t have such an ideal tool (i.e. with zero false positive rate), as the problem of analyzing all possible program execution paths is incomputable. Thus, the practical analyzers always consider some superset of all possible execution flows, which is easy to compute, yet may introduce some false alarms and the whole trick is how to choose that superset so that the number of false positives is minimal."

Read the blog. It's excellent thoughts on the subject from someone who has successfully shown how to penetrate the kernels with malware.

Guy
www.authenticationworld.com
guy.huntington@authenticationworld.com

TrackBack

TrackBack URL for this entry:
http://www.authenticationworld.com/cgi-bin/blog/mt-tb.cgi/164

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)