Vista Security - a reaction to an article on NeoWin

“Vista’s Security Rendered Completely Useless by New Exploit” read the headline on the Neowin site. That sounds big and scary, doesn’t it? Here is a link to the article http://www.neowin.net/news/main/08/08/08/vista39s-security-rendered-completely-useless-by-new-exploit

Let us have a look at what this is all about. The reality is rather different from the claims here. Mark Dowd (IBM) and Alexander Sotirov (VMware) wrote a white paper and gave a presentation at Blackhat (a well known convention for people involved in security, penetration testing and, well, let us be honest here, hacking) on how to exloit a particular vulnerability in Vista. I wasn’t at Blackhat this year so didn’t see the presentation but I have read the white paper and it is well written and scholarly. The paper has the title “Bypassing Browser Memory Protections” and the subtitle “Setting back browser security by 10 years”. I don’t agree with everything that they say but I think that it was an interesting read.

What they show is that a particular known and fixed vulnerability can be exploited on unpatched systems using a combination of techniques in a particular case. This is impressive but a very, very long way from showing that Vista Security is entirely broken. There are some particular reasons why I say that this is very different and I will explain my reasoning. Oh, I have to say that I will not be using any specialist knowledge of Microsoft operating system code and did not work on the particular vulnerability discussed. I am just working from the white paper. Anyway, on to why I disagree.

The first reason is that the Vista security model holds up fine even on the exploited system. The exploit is in the browser. The browser runs web content in restricted mode. What does this mean? It means that the code can only do a very few things. Yes, it is arbitrary code of the attackers choosing so that is good for the attacker but let us review what can be done in restricted mode. It is documented fully here http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx but let me save you some reading. Code running in protected mode can write to Temporary Internet Files or the Low folder of the user. It can also write to the HKEY_CURRENT_USER\Software\LowRegistry section of the registry and sent certain well defined Windows messages to other processes. These are messages believe to be very safe indeed. What does this mean in simple term? It means that you can display a message box but you can’t silently hook in a keylogger even if the user is an admin. Vista Security has limited the compromise rather nicely. Does that square with “”Vista’s Security Rendered Completely Useless by New Exploit”? No, not at all.

To come to the second reason, I would disagree that this is a a general case as the white paper claims. To be a little more specific:

1. In the exploited case, there was a overflow in a buffer that wasn’t being treated as a buffer. This was the ANI buffer overflow (CVE-2007-0038). This was patched by Microsoft in MS07-017 (K925902 to its friends). This was an odd case because there was no buffer as such used. A structure was overrun that hadn’t qualified for checking and where (according to the white paper) a user defined number of bytes could be written into a fixed length structure. The curious thing is that you would normally write code that expected to populate a fixed length structure to assume that the number of bytes to copy was the same as the length of the structure. This made it very different to the more usual buffer overrun cases that have been exploited before. There are additional safeguards (as Dowd and Sotirov discuss) that protect in the more usual case.

In their discussion of SEH chain validation, they say that you can bypass the validation by changing memory (in this case, a table of exception handler addresses) in some specific ways. This is a new feature in Vista and Server 2008 which normally stops attackers who have compromised the stack from overwriting the exception handler pointer. Anyway, they claim to have found a way of disabling this. To do that, you would need to be able to run custom code (in which case you have already won) or do a memory write where you controlled at least 2 registers and had a replacement SEH in executable memory. If you can load custom code and control multiple registers then you have already compromised the machine. I don’t see that they are adding much with this. This is pretty much special case stuff.

Their point about not all functions with buffers having stack cookies is a valid one but hardly news. As they point out, there was already a vulnerability known that exploited that. Unless they have some other similar unpatched vulnerability then this is an academic point only.

They make much of the ability to overwrite 4 bytes on the stack before the stack cookie is checked but with load addresses of modules randomised, that doesn’t help you very much. In the most common case, an exploit that allowed a stack write could let you change a value in the memory space of the process immediately before it was torn down for failing the stack cookie check. As they point out, heap exploits on Vista are pretty much impossible to use so stack overwrites are about all you have. I don’t see this as anything to get excited about…

…except if you overwrite the SEH list as they say. However, before this is of any use, you need to have injected some code for the SEH to point at and know where it is and then cause an exception that would be handled by that exception handler. So, for their compromise to be useful, the box already needs to have been controlled to the extent that you have have custom code loaded at a known location AND you have a buffer overrun AND you know where the SEH list is stored AND you need to know where in the list to write which is tricky because this is a linked list which you need to walk - which you can’t because all you have at this point is the ability to write 4 bytes of memory.

As they point out, Vista doesn’t use lookaside lists so heap unlinking attacks don’t work. Can we call this “Setting back browser security 10 years”? No, I don’t think we can in all fairness.

Yes, they are right to say that Java applets could be used for heap spraying but that is not in and of itself exploitable. Documents of all types can also be used. This is hardly new or operating system specific.

It also true that many third party applications are not ASLR aware but they are no more vulnerable than they were on any previous operating system. It also has very little to do with hacking the browser.

In short, it was an interesting read but the article as published could hardly be called an accurate representation of the facts to hand.

Until next time, Signing off

Mark Long, Digital Looking Glass Ltd.