The Chicken Little contingent is on Defcon 1 it may seem. Break out your Kevlar helmets, everyone, because the sky is falling on Windows! At last week’s Black Hat conference in Las Vegas, researchers Alexander Sotirov and Mark Dowd presented a paper that outlined some new attack vectors they had discovered targeting some security features introduced in different versions of Windows XP and Windows Vista. It’s a fascinating paper, rich in technical detail and hewing to the Black Hat tradition of providing clues that others can follow to discover, exploit, and ultimately fix vulnerabilities in widely used computer code.
Unfortunately, most people who read about Sotirov and Dowd’s work didn’t bother to read the technical paper. Instead, they relied on quick summaries, most notably the one provided by SearchSecurity, which was picked up by Slashdot and our own Adrian Kingsley-Hughes. Alas, those stories are wildly inaccurate and hopelessly sensationalized.
The “rendered useless” quote is in the headline from SearchSecurity’s article, which breathlessly asserts:
“Researchers who have read the paper that Dowd and Sotirov wrote on the techniques say their work is a major breakthrough and there is little that Microsoft can do to address the problems.”
I’ll skip right over the implication in that first statement, that the author of the SearchSecurity article hadn’t yet read the paper and was instead relying on second- and third-hand accounts. As for the contention that “there is little that Microsoft can do,” maybe we should ask Sotirov and Dowd, who conclude their paper with this matter-of-fact statement:
“The authors expect these problems to be addressed in future releases of Windows and browser plug-ins shipped by third parties.”
The “rendered useless” meme was picked up by Adrian, who led off his story with this alarming oversimplification:
“So, in a stroke, two security researchers (Mark Dowd of IBM and Alexander Sotirov or VMware) at Black Hat have set browser security back 10 years and rendered Vista’s security have been rendered useless … [sic] I’m surprised that it took this long for the walls to come tumbling down, but I have to admit I didn’t expect all of them to come down at once like that!”
And then, three paragraphs later, he notes, “The sky isn’t falling in.”
OK, so which is it? One clue is that Adrian’s piece doesn’t include a single quote from the original paper. It has no discussion of the exploit techniques as described by the authors, nor does it include any commentary from the authors or from anyone who saw their talk in Las Vegas. Instead, it echoes the wording of the SearchSecurity article.
If you read the authors’ actual words, not the sensationalist and wildly inaccurate news accounts, you get a completely different story. Here’s how the authors describe the talk they gave at Black Hat, for example:
“Specifically, we will be discussing how rich browser functionality can be utilized to help lessen the impact of memory protections (and in some cases, completely negate them). Some of the techniques we will be discussing are known ones, whereas others are new approaches that we haven’t seen discussed in public forums before.”
Memory protection is one part of a comprehensive, multi-layered approach to security. Microsoft calls this approach “defence in depth,” and specifically makes the point that features like this will always be under attack and will eventually be defeated. If you don’t believe me, listen to Microsoft’s Michael Howard, security expert and author of Writing Secure Code, who predicted this back in 2006:
“There are two overarching goals at work – the first is to reduce the number of bugs in the code, and the second is to make it harder to reliably exploit any bugs that remain. … [W]e can do the very best we could possibly do, but Windows Vista will be in the market place for years and in that time, I can guarantee new attack techniques will be discovered, as will new bug types, and we can’t necessarily anticipate the future. Also, our tools are not perfect; we know they won’t find all vulnerable code. With that in mind, we must add other defences.”
So how does defence in depth work? Well, an attack has to start with code that exploits a system’s vulnerability, such as buffer overrun that allows an attacker’s code to execute on a target machine. The victim has to be induced to actually run that code (in this case, by visiting a booby-trapped web page). The example that Sotirov and Dowd use is the ANI cursor vulnerability, which was unveiled and patched in early 2007. The best defence against this type of vulnerability is to fix it before it’s released; the next layer of defence is to quickly patch vulnerabilities like this after they’re disclosed. Well-written antivirus software can identify and block specific exploits and can also detect and stop generic attacks. What Windows Vista adds to the mix is a set of memory protection features that make it more difficult for attackers to run code remotely. Note that I said “more difficult” not “impossible.”
The sensationalist stories about this paper start with the amateurish viewpoint that memory protection was designed to be an infallible security barrier. Security professionals inside and outside Microsoft know better. One of the biggest targets of the work by Sotirov and Dowd is Address Space Layout Randomization (ASLR). When Michael Howard first wrote about ASLR back in 2006, he specifically cautioned against thinking of it as a magic bullet:
“Windows Vista Beta 2 includes a new defence against buffer overrun exploits called address space layout randomization. Not only is it in Beta 2, it’s on by default too. Now before I continue, I want to level set ASLR. It is not a panacea, it is not a replacement for insecure code, but when used in conjunction with other technologies, which I will explain shortly, it is a useful defence because it makes Windows systems look “different” to malware, making automated attacks harder. ASLR is seen as just another defence, and it’s on by default in Windows Vista Beta 2. I think the latter point is important, we added ASLR pretty late in the game, but we decided that adding it to beta 2 and enabling it by default was important so we can understand how well it performs in the field. By this I mean what the compatibility implications are, and to give us time to fine tune ASLR before we finally release Windows Vista.
Ok, let’s assume that the attacker has the motivation, time, patience and expertise to bypass all these defences. There’s more!
A new defence for Windows Vista is Service hardening, it’s a broad subject, so I want to focus on just two parts of service hardening. The first is the ability to describe the privileges that a service requires, and the service control manager (SCM) will assign only those privileges to the process. … The exploit code runs with the same privileges as the host process, and reducing the privileges associated with the process means the exploit code can do less damage. Of course, there may very well be privilege elevation bugs in Windows Vista that we do not know about, but in my opinion it’s better to put up defences, rather than no defences at all.”
That’s the best summary I’ve read in a long time of the cat and mouse game that is modern computer security. Software developers do their best to design systems that have a solid baseline of security, and then they add features that make it more difficult for attackers to succeed in breaching the system. Attackers (black and white hats alike) poke and prod at those systems to find new vulnerabilities, which the software designers in turn have to deal with in current and future releases.
So, where is Windows 7 in all this? As Michael Howard noted in his ASLR announcement from early 2006, the ASLR feature was added fairly late in the development cycle to Windows Vista. Microsoft’s security team has been working with and refining ASLR for more than two years. The idea that they’ve been completely blindsided by the revelations in a single Black Hat paper and that they’ll have to scrap the entire architecture of the Windows platform is naive, to put it charitably.