Tuesday, 13 December 2011

The Curious Case of VirtualAlloc, ASLR and an SDL

So Address Space Layout Randomization (ASLR) is becoming increasingly common way on multiple platforms to not resolve security issues but frustrate exploitation. While doing a bit of further research into ASLR on Microsoft Windows 7 one weekend we tripped across some behaviour that was a revelation to us. The revelation was that VirtualAlloc is not subject to ASLR on Windows, this is unlike HeapAlloc and malloc. This fact is surprising considering that:
  • This behaviour is not documented on MSDN
  • This API is not on the Microsoft banned API list
  • Vendors can use VirtualAlloc to allocate memory read-execute, write-execute and read-write-execute

This obviously represents a risk if misused by software vendors and may not be flagged as bad even if the most rigorous of SDLs was adhered to. Why is this behaviour a risk? Well VirtualAlloc could potentially undermine the effectiveness of ASLR (when used) and create the break an aggressor needs.

So we then went looking to see who else was aware of this behaviour. We only found a single public reference when we tripped across Chris Rohlf’s and Yan Ivnitskiy’s Mantasano paper titled ‘Attacking Clientside JIT Compilers’ from the summer. In this paper the authors state:

However, the VirtualAlloc call on Win32 is not randomized by default and will return predictable allocations of contiguous memory at offsets of 0x10000 bytes. Fortunately, VirtualAlloc takes an optional argument indicating the desired page location to allocate. Creating a randomization wrapper around VirtualAlloc to simulate mmap’s existent behaviour should be a straightforward process.”

So armed with this we thought it would be useful to understand how prevalent the use of VirtualAlloc with memory protection constants such as PAGE_EXECUTE_READWRITE and PAGE_EXECUTE_WRITECOPY were. We decided to use 'cloud grep' aka Google code search.

Numerous examples were found in many different projects, including:

One of the more interesting implementations is in Google’s Chromium where they take heed of Chris's and Yan’s advice. 

So this is a real positive outcome, the vendor understands the risk, implements a mitigatation and moves on. Anyway, next we went onto binaries, we did a quick audit of files on one of our Windows 7 machines which included Office 2010. We notice that MSO.DLL uses the function.

Now for this to be of concern to us, we need to have 40h or 80h passed as the last parameter to VirtualAlloc. 40h is PAGE_EXECUTE_READWRITE and 80h is PAGE_EXECUTE_WRITECOPY. Looking through MSO.DLL we find at least one example where this occurs:

From this we know that Microsoft Office allocated memory that is RWX using VirtualAlloc on an otherwise enabled ASLR binary. Now this by itself is not a vulnerability, but knowing this behaviour exists means that there is a light at the end of the tunnel if you're trying to bypass ASLR.

We had a chat with Microsoft about the behaviour of VirtualAlloc. They were good enough to point out that there are numerous factors in the real world that could cause some randomization. These factors include the bottom up randomization in EMET, as documented by Didier in his post Bottom Up Randomization Saves Mandatory ASLR.

Anyway, in conclusion we see that there are a number of instances where VirtualAlloc is used in a potentially dangerous manner in the real-world by a variety of software vendors. While some vendors (credit to Google) mitigate the lack of randomness, not all will. Google and Microsoft are also not the only vendors to use this functionality; there are and will continue to be others who also use it. So in short this is something to add to your grep strings when doing code reviews in order to flag to development teams to ensure they're aware and mitigate appropriately.

We've released an SDL friendly version of VirualAlloc called VirtualAlloc_s.

No comments:

Post a Comment