I got the Exhibition Plus package at the RSA conference, which gave me access to one of the talk tracks. Based primarily on this talk, I chose the developer’s track. I had hoped they were going to talk about the security model from a developer’s point of view, but instead they talked about the Security Development Lifecycle (SDL), they used in developing Vista. I had heard Mike Howard talk about the SDL process several years ago at the Security and Privacy Symposium, but it still was an interesting talk, and I gathered a few tidbits from it. There were two presenters. Mike Howard acted as the main presenter, and Jeffery Jones acted like the side kick feeding lines to Mike.
The idea of the SDL is to make security an essential part of the software development process. Everyone creates threat models. Everyone runs tools on their code before checkin. Security is no longer an afterthought. The speakers did not claim that bugs were now extinct. They acknowledged that there would always be bugs, but rather with SDL they eliminate the bugs they know how to eliminate. I heard from a colleague that Bill Gates in his keynote address made some silly comment about security bugs no longer being possible, so it is comforting anyway that people in charge of security have a more realistic view of things.
One big part of the SDL is threat modeling. I actually use part of the Microsoft thread modeling book when teaching Information Assurance. When designing a module, you understand the threats and create a formal model of how threats can co-opt your design. According to Howard, they developed 1400+ threat models in the course of writing Vista.
Two of the changes they introduced that had prehaps the biggest impact on bug count were not particularly technologically esoteric: banning unsafe functions and using an annotation language to help the compiler detect flaws. They banned over 120 functions such as strcpy and sprintf. This seems fairly straightforward, but evidently they dedicated a team to it just to deal with the millions of lines of existing code.
The added a Standard Annotation Language (SAL) to decorate the declarations of function calls, so it is clear how parameters to the calls are related, e.g. arg two is the length and arg three is the buffer. Evidently most of the Microsoft system headers are annotated. It wasn’t clear from the talk if this was just compile time analysis, or if it did runtime checking. It seems like it must do runtime checking to check buffer and length mismatches.
While Vista was under development, the security team would do root cause analysis on bugs found under XP and determine if the bugs would be an issue under Vista. According to the speaders, a root cause analysis of 63 buffer bugs showed that 82% were already fixed in Vista by a combination of function banning and SAL. 43% caught by SAL and 41% caught by removing functions.
Other security development techniques included fuzzing, integrity levels, and heap and stack protections. None of these are new techniques, but Microsoft is probably pushing these techniques to wider spread adoptions. Fuzzing is a means of input testing. You feed a variety of bad input to your project and see how it behaves. The speakers talked about it primarily with respect to fuzzing configuration files. For each file that a program uses, the developer must run it against a large number (didn’t write down the number) of randomly fuzzed versions.
Each process has a message integrity level associated with it. Presumably each file also has an integrity level associated with it. The ideal of integrity levels was promoted by Biba in the 70’s and has shown up in some trusted operating systems as a mandatory control. The idea is that a low integrity entity should not pass information to higher integrity entities. The example that the speakers gave was that IE should run at a low integrity level while other processes run at higher integrity levels. Thus even if malware takes over control in IE, it cannot harm the higher integrity processes. I have lots of questions about this technology, and it will take more than a cursory glance at MSDN to figure out what exactly this means. If this is in fact a mandatory control, this is a huge step, and potentially a quite error prone step. Trusted OS’s have traditionally been quite hard to use because the mandatory controls cause things to break in unexpected ways.
They also talked about the service hardening which seemed to me like one of the most imporant security features announced with vista. You can specify the privileges required when registring a service. You can also create a policy to describe the expected network behaviour of the service. This is defintely one of the areas I want to play with when I get Vista running again.
Vista includes all the heap and stack protections that have been floating around. Vista provides the Data Execution Protection (DEP, exposing of the no execute bit) that was introduced in XP SP2. By making the stack no-execute, you thwart a lot of exploits. However, the speakers noted that only system software is protected by DEP by default. A number of programs will break under DEP including IE and Sun JVM. Acrobat and Flash used to break, but newer versions will run with DEP enabled. A program such as a Java JIT that is creating a program to execute in data must use Virtual Protection calls to tell DEP that is ok to execute a subsegment of data. Though wouldn’t a savvy exploit add such a call too?
In Vista, the heap is cleaned up to make some of the heap exploits more difficult. The array of free lists is removed and canaries are added to detect corruptions.
Image randomization is added. At boot time one of 256 image memory layouts is selected. Plus when a program is executed the stack and heap bases are randomized.
All in all, it sounds like many smart people have been working Vista. While it may not be perfect, it sounds like they have made many security advances. I’ve been reading Peter Guttmann’s review of their DRM technology through and that makes me feel much less hopeful though.