Chapter 3: Buffer Overrun Defenses

Overview

Windows Vista adds several mitigations against buffer overruns and improves many of the defenses that were already in place in Windows XP SP2 and Windows Server 2003 SP1. Before we start discussing the new features, we need to make several important points. First, you still have to write solid code. As we said in Writing Secure Code, all of these defenses are like the seatbelts in your car–none of them are guaranteed to save you from your mistakes, and if you ever have to use them, you’re not having a good day (Howard and LeBlanc 2003)! Like the seat belts (and air bags, and antilock brakes, etc.), no one can guarantee that you’ll never have a bad day, but if you do, it’s always a good thing if you have something to help keep it from getting worse. Our friend Jon Pincus, a researcher in Microsoft Research, expresses this principle very well (Jon Pincus, personal communication):

For any given mitigation, or set of mitigations, a sufficiently complex attack can overcome the mitigations. For any given effective mitigation, there exists some set of attacks which are stopped completely.

If you come up with some completely contrived piece of attack code with a dozen different flaws that manages to execute arbitrary code despite all the defenses we added, you haven’t discovered anything new or exciting. However, if you take a careful look at what we’ve done and find room for improvement, please let us know–we’re always interested in making our platform more secure.

Figure 3-1 shows a graphic way to envision the problem.

Figure 3-1: Diagram showing effect of mitigations and code improvement.

Any piece of software will have between 5 and 50 defects per 1,000 lines of code (kloc, which is pronounced k-loc). How to properly count software defects has been the subject of much study and debate, and this book can’t possibly address the topic thoroughly enough. A good reference on the topic is “Bugs or Defects?” (Humphrey 1999). The numbers quoted here are reasonably close to those reported by various researchers. For example, Humphrey cites figures from three different projects from the Jet Propulsion Laboratory. Despite rigorous development practices, from 6.5 to 9 defects/kloc were found after the programs were compiled, unit tested and integration tested. An average developer with average development practices will make 50 to 100 mistakes/kloc, many of which may be caught by compiler warnings and testing. Code review, education, experience, and static analysis tools can drive the actual count to the lower portion of the range. Fuzzing, or better yet, targeted test harnesses to validate the code, will also drive down the defect count. Unfortunately, you aren’t likely to drive defects to zero for any nontrivial application, and the closer to zero defects you try to get, the more expensive the code becomes to create, so it might be best to just accept that there will be the occasional error.

Out of the defects that do exist in the code, some will be exploitable. Even the most trivial defenses can eliminate some attacks. For example, an off-by-one overwrite of a stack buffer used to be typically exploitable, but with the introduction of stack protection, these are now stopped. The techniques we discuss in this chapter are all efforts to ensure that some of the errors that escape us don’t result in an exploitable condition.

The second point we’d like to make is that Microsoft didn’t actually pioneer much of this, and this text does not claim that’s the case. What we are doing is delivering these features in an extremely widely used, general-purpose operating system while doing our best to maintain backward compatibility and good performance with an extremely wide range of applications.