Researchers at Black Hat Reveal Major Vista Security Issue

http://arstechnica.com/news.ars/post/20080811-the-sky-isnt-falling-a-look-at-a-new-vista-security-bypass.html said:

The sky isn't falling: a look at a new Vista security bypass

By Peter Bright | Published: August 11, 2008 - 07:30AM CT

One of the papers presented at the Black Hat USA 2008 security conference was an analysis a number of the protection mechanisms built into Windows Vista and Windows Server 2008 that are designed to make it harder to convert software bugs into security flaws. How to Impress Girls with Browser Memory Protection Bypasses, authored by security researchers Mark Dowd at IBM and Alexander Sotirov at VMware, presented a number of attacks against Vista's various security features in isolation, and then attacks that could disable multiple protections all together. Put together, the result is that Vista's mitigation mechanisms are circumvented, making buggy software exploitable.

The security features being bypassed are all intended to minimize the impact of buffer overflows. Buffer overflows are a particular kind of programming error that occur when a program attempts to store too much data in the buffer allocated for the data. This causes anything following the buffer to be overwritten. Buffer overflows are exploitable when it's possible to insert arbitrary executable code into a process and then make that code run. If an attacker can do this then the attacker has gained the ability to do whatever he likes to the victim's computer.

Mitigating against buffer overflows

This kind of flaw is quite a common one, especially in the programming languages C and C++. Many high-profile software flaws have been of this type, from the Morris worm of the 1980s to the Code Red worm of 2001, and more recently the animated cursor vulnerability. Although there are languages that make such flaws impossible—Java and .NET are both immune to such flaws—the unfortunate reality is that a large proportion of the software that we run (including our operating systems, web browsers, and browser plugins) don't use these safe languages, and so are susceptible to this ancient problem.

This is why Microsoft included a number of protection schemes in Vista to try to reduce the exploitability of buffer overflows. Although the operating system cannot prohibit such flaws (except by mandating the use of Java and .NET), it can make it less likely that an overflow can lead to arbitrary code execution. One of these protections was introduced in Windows XP Service Pack 2; Microsoft calls it Data Execution Protection, DEP. With DEP enabled each block of memory in a process must be explicitly marked "executable" before the processor can run any instructions stored in that block. This means that even if an attacker can write arbitrary code into a process, the processor isn't able to run that code. This effectively prevents any easy exploitation of buffer overflows.

Unfortunately, security researchers are a clever lot; they discovered ways by which DEP could be defeated, for example by passing control not to their own executable code, but instead to one of the system DLLs loaded into the process and getting that to do their dirty work. Vista therefore introduced several mechanisms to try to reduce the impact of these DEP bypasses. One of these is Address Space Layout Randomization, which randomly organizes the location of the system DLLs so that an attacker no longer knows where they are. Vista also inserts extra checks into the operating system code to detect that certain kinds of overflow have occurred and crash the program (although crashing might seem a bad thing to do, it's safer than continuing to run after a buffer overflow).

It is these extra mechanisms that the paper at Black Hat attacks. Dowd and Sotirov describe several different techniques for bypassing Windows' protections that can be used to reinstate the exploitability of buffer overflows. One of the key mechanisms used is the fact that the protections are not always applied. Internet Explorer 7 and Firefox 2 both opt out of DEP, and many third-party libraries such as the Flash plugin opt out of ASLR (and other protection mechanisms). Plugins can also do things that can deliberately defeat the OS's countermeasures; Java, for example, marks all of its memory as executable, meaning that a Java applet can place into memory executable code that's immune to DEP protection. The final trick is to use scripting or plugins to file large amounts of memory with the malicious executable code, so that even when ASLR is in effect, an attacker can still be sure that the malicious code is where he needs it to be. Together, these techniques allow all of the protections found in Vista to be defeated.

Chicken Little runs amok

This is certainly unfortunate. The great thing about these protection mechanisms is that they provided a degree of safety even when applications contained bugs. That will no longer be the case, at least for web browsers (programs that do not support third-party plugins (or apply more stringent checks to those plugins) might continue to benefit from the protections). Unfortunate, yes, but not—as was reported in the immediate aftermath of the presentation—evidence that Vista's security is useless, nor does this work constitute a major security issue. And it's not game over, either. Sensationalism sells, and there's no news like bad news, but sometimes—particularly when covering security issues—it would be nice to see accuracy and level-headedness instead. Alarmism helps no one. Responsible vulnerability disclosure is a big concern in the security industry; it would be good to see it coupled with responsible reporting.

The work done by Dowd and Sotirov focuses on making buffer overflows that were previously not exploitable on Vista exploitable. These are buffer overflows that would be exploitable on Windows XP anyway; after all, there's no need to defeat ASLR if an OS does not have ASLR at all. Furthermore, these attacks are specifically on the buffer overflow protections; they do not circumvent the IE Protected Mode sandbox, nor Vista's (in)famous UAC restrictions. DEP, ASLR, and the other mitigation features in Vista are unlikely to ever be unbreakable, especially in an application like a web browser that can run both scripts and plugins of an attacker's choosing. Rather, their purpose is to make exploitation more difficult. Microsoft has a solution for those wanting to make it impossible—use .NET. These protections are there for when that's not an option, to reduce—but not eliminate—the vulnerability caused by such programming errors. Even with DEP and ASLR, the coding errors that result in buffer overflows still ought to be fixed; it is only through fixing the errors that the flaws can truly be eliminated.

Even with the attacks described in the paper, Vista has many worthwhile security improvements compared to XP. Internet Explorer on Vista runs in a highly restricted environment, so that even when it is running malicious code it cannot harm the system. Stories suggesting that Vista's security is now irredeemably broken are far off the mark; the truth is merely that some of its automatic security protection is less effective than it was before.

What Microsoft will do in response remains to be seen. Some of the specific featurs of the attacks can be resolved by Microsoft itself—preventing IE plugins from opting out of the protection schemes, by improving the way that .NET interacts with the protection, and by making Windows default to enabling all the protection schemes—and others can be minimized by third parties—by writing plugins that enable with all the security mechanisms, by being more careful with executable memory, and so on. Longer term, a switch to 64-bit programs might allow considerably more randomization to be applied; while making large allocations is enough to fill up a 32-bit program's memory (which allows attackers to defeat randomization) the same is not true of 64-bit processes—they're simply too big.

Click to expand...

http://blogs.zdnet.com/Bott/?p=512 said:

Windows security rendered useless? Uh, not exactly
Ed Bott’s Microsoft Report | ZDNet.com

Update 11-August, 6:00PM: Don’t miss my exclusive follow-up interview with researcher Alexander Sotirov, who says “The sky is not falling and the flaws are not unfixable.”

Oh dear. The Chicken Little contingent is out in full force. 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 plugins 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 “defense 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 defenses.

​

So how does defense in depth work? Well, an attack has to start with code that exploits a system 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 defense against this type of vulnerability is to fix it before it’s released; the next layer of defense 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 otherwise. 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 defense 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 defense because it makes Windows systems look “different” to malware, making automated attacks harder.
[…]
ASLR is seen as just another defense, 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 defenses. There’s more!
A new defense 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 defenses, rather than no defenses 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.

Update: Peter Bright at Ars Technica has an excellent post on the same subject, hitting many of the same themes::

Sensationalism sells, and there’s no news like bad news, but sometimes—particularly when covering security issues—it would be nice to see accuracy and level-headedness instead. Alarmism helps no one. Responsible vulnerability disclosure is a big concern in the security industry; it would be good to see it coupled with responsible reporting.
The work done by Dowd and Sotirov focuses on making buffer overflows that were previously not exploitable on Vista exploitable. These are buffer overflows that would be exploitable on Windows XP anyway; after all, there’s no need to defeat ASLR if an OS does not have ASLR at all. Furthermore, these attacks are specifically on the buffer overflow protections; they do not circumvent the IE Protected Mode sandbox, nor Vista’s (in)famous UAC restrictions. DEP, ASLR, and the other mitigation features in Vista are unlikely to ever be unbreakable, especially in an application like a web browser that can run both scripts and plugins of an attacker’s choosing. Rather, their purpose is to make exploitation more difficult.
​

Go read the whole thing.

Click to expand...

http://blogs.zdnet.com/Bott/?p=513 said:

This afternoon, I received the following e-mail from Alex Sotirov and am reprinting it with his permission:

Alexander Sotirov said:

Thanks for your blog post about our research. I was horrified by the lack of understanding displayed by the tech press when they covered the paper Mark and I presented at BlackHat. You rightly point out that the sky is not falling and the flaws are not unfixable. In fact, the next versions of Flash and Java will contain specific measures that limit the impact of the techniques we presented. We expect Microsoft to follow suit as well.

Click to expand...

Click to expand...