Windows internals research provides a vast amount of room to explore, and sometimes you come across a particularly interesting subject you may have not known about or heard of: a subject that has very minimal documentation and seems to be a remnant of the days prior to native 64bit support.
These are the times that excite you because you’re certain you will find that brand new vulnerability that may lead to an exploit that affects all versions of the Windows Operating System.
Although this isn't one of those times for me, I wanted to share this “failure” (non-discovery) with you anyways and with any luck you may find something I missed during my own research. I use the term failure here very loosely because in reality, there is no failure when knowledge is gained. While I did not accomplish what I set out to do, I uncovered a wealth of new knowledge that may help you or I in future projects.
This is the beauty of security research. Knowledge is the ultimate victory.
During some loosely related research I came across an API that I had never seen or used before: NtMapUserPhysicalPages. It sounded like an interesting name for an API. My first assumption was that this API allowed a user mode program to manipulate physical memory. After some MSDN-fu that's kind of what it was. This API was part of a technology Microsoft called Address Windowing Extensions (AWE).
Address Windowing Extensions (AWE) is a set of extensions that allows an application to quickly manipulate physical memory greater than 4GB.
AWE solves this problem by allowing applications to directly address huge amounts of memory while continuing to use 32-bit pointers.
These extensions were created to address memory constraints with the 32-bit memory model. However, this isn't particularly what interested me. The documentation goes on to explain some of the restrictions placed when using this extension. These restrictions are what I was particularly interested in ‘testing’:
Virtual address ranges allocated for the AWE are not sharable with other processes (and therefore not inheritable). In fact, two different AWE virtual addresses within the same process are not allowed to map the same physical page. These restrictions provide fast remapping and cleanup when memory is freed.
At a high level, what this extension allows us to do is reserve physical pages of memory that are non-pageable in order to map them into our user-mode virtual address space. This reservation of non-paged memory allows fast memory access and fast memory remapping among the other stated advantages.
So what API’s are needed to utilize these Extensions?
MSDN lists them as:
Oftentimes the best ideas come from challenging documentation. Documentation of an API or set of functions may declare one thing but the code may contain some flawed implementation of its intent. It’s our duty to challenge these intentions.
In order to actually use this extension, the host Operating System (OS) must have a specific policy enabled for the user (Lock Pages in Memory Policy). This policy is disabled by default for all users in a standard Windows installation; however, some machines running a variant of Windows Server with SQL Server have it enabled.
After reading the documentation for AWE I decided to think about some ways we could (ab)use it. Can we somehow allow Process B to remap physical pages allocated by Process A utilizing the fast remapping capabilities of AWE?
It all starts with one question: let’s explore.
We’ve got a basic idea of what we need to work with AWE, so let’s use the extension the way it was intended. MSDN tells us what API’s were needed so a simple usage looks like the code below:
The code flow is as follows:
1. Determine the current system's page size
2. Determine the amount of physical pages we'll be requesting. (AmountOfMemoryInBytes/SystemPageSize)
3. Allocate a buffer for the array of page frame numbers we’ll receive from the kernel (HeapAlloc)
4. Call AllocateUserPhysicalPages(), this API reserves the physical pages for this process and returns the Page Frame Numbers to the caller (why?).
5. Allocate the virtual address space to be used (VirtualAlloc with MEM_PHYSICAL | MEM_RESERVE only)
6. Map the physical pages to the virtual address window (MapUserPhysicalPages)
The memory Windows used for this mapping are now guaranteed to be committed in memory and never paged-out. Also, memory regions can extend the official 2GB virtual space provided for 32bit applications if enough physical memory is available.
As the documents previously stated: “two different AWE virtual addresses within the same process are not allowed to map the same physical page.” We can easily test this, taking our original code above and just adding another Virtual Window we have this code, which turns out to prove the documentation is correct:
Creating two virtual windows and attempting to map them to the same physical pages will in fact fail according to the documentation and this sample code.
Nothing to see here, so let’s move on.
AWE allows what it calls fast remapping. Essentially, this allows one to keep data in physical memory as long as needed and if this data needs to be mapped to another virtual address it can easily do so with no performance impact due to the physical pages never being paged out (to disk) or succumbing to trimming. An example of the flow is shown in the below code snippet: (Error checking removed for clarity).
An initial call to MapUserPhysicalPages is made to map the physical pages to the virtual window; data is written into this window then the Pages are unmapped using a call to MapUserPhysicalPages with a NULL value for the PfnArray parameter. MapUserPhysicalPages is then used to remap those physical pages to a new virtual window. The data is written once and can be mapped to a new virtual address without the penalty that comes with paging in memory from disk. At the end of this sequence, the data written into virtual window one will now reside in virtual window two, and virtual window one will revert back to a RESERVED state.
At this point we’ve read documentation on the APIs related to AWE and have a very basic working knowledge of it. The goal was to see if there were any implementation bugs with these extensions regarding the physical pages across process boundaries. The basic idea behind remote remapping is:
The assumption being made here is that because the documentation states that these pages are not included in the process’s working set, it has to be managed by some other mechanism we don’t know about yet. Furthermore, if the pages are committed, and we control when and how they are released, what can be done with such power? We’ll find out later more about how these physical pages are managed when we deep-dive into our results.
I chose to go an easy route here by utilizing DLL injection and shared memory maps to pass information needed to process B from process A.
The first process (process A) allocates physical pages and a virtual window and writes data to that virtual window. Process A then creates a named mapped section to write the page frame number array we received from our call to AllocateUserPhysicalPages(). Process A spawns process B and injects a DLL that reads the mapped data, allocates physical pages and attempts to remap the physical pages to a new virtual window in process B.
So we already know the outcome of all this. It failed, specifically, we failed with the STATUS_CONFLICTING_ADDRESS error code. We expected it to fail because the documentation said it would. However, we aren't satisfied until we know WHY it failed. So let’s take a trip into the real reason we do research: the WHY.
Earlier we mentioned the documentation stated the pages allocated through the AWE extensions are not included in the process’s working set. What is the working set?
Every process in the Windows OS upon execution is given a minimum and maximum working set; this set defines the amount of physical pages the process is allowed.
According to the Windows Internals Book:
“Every process starts with a default working set minimum of 50 pages and a working set maximum of 345 pages.”
These aren't hard limits however, and if needed the memory manager will allow an application to exceed its maximum limits if system resources permit. It will also trim them below the low limit if more resources are required by the system.
We mention this because the working set will typically contain pages that are committed through calls by the usermode program such VirtualAlloc(). AWE requires a call to VirtualAlloc, with the required MEM_PHYSICAL allocation type, and a subsequent call to NtAllocateUserPhysicalPages. The pages are not included in the working set, however they are still added to the Page Database and managed via some other page management system.
So if AWE pages are not in the working set, where exactly is it managed? We’ll need to go into the kernel and look at how the Virtual Memory is managed for AWE regions.
The first difference with AWE is our call to VirtualAlloc and the MEM_PHYSICAL allocation type. This allocation creates a unique VAD entry in our process' VAD Tree. Below is the VAD tree for our RoundThree.exe. Take note of the two VAD entries marked as AWE regions.
When the call to NtAllocateUserPhysicalPages is made we can examine the disassembly and observe what happens. The function applies basic security and address boundaries checks (ensuring the SeLockMemoryPrivilege is enabled for the current process and the incoming virtual address is valid user-mode address).
NtAllocateUserPhysicalPages will reserve the number of physical pages our user-mode program requests. It does this by reserving physical pages through MiAllocatePagesForMdl(); the pages frames returned are filled into the user-mode buffer.
A structure named AweInfo is then allocated in the EPROCESS of the calling process. The AweInfo structure is undocumented and contains information about the physical pages that will be used in our AWE region. Among the data contained in it are the number of physical pages being requested, and a pointer to a (shadow) VAD Tree describing the virtual address windows we created using VirtualAlloc(). More specifically, it’s a pointer to an _MM_AVL_TABLE with MMADDRESS_NODEs describing the AWE virtual ranges. We can see from our WinDbg output below what the AweInfo structure looks like initially in memory. No AVL_TABLE has been created at this point, this occurs later during NtMapUserPhysicalPages.
When NtMapUserPhysicalPages is called, an _MM_AVL_TABLE is created and populated with the virtual addresses we’ll be mapping physical pages to.
NtMapUserPhysicalPages proceeds to map the physical pages (PFNs) to the virtual windows and assigns them a backing PTE (Page Table Entry). Below is a pointer to the AVL_TABLE populated when MapUserPhysicalPages is called (0x8558f328).
In the case of NtMapUserPhysicalPages with a NULL parameter for the PfnArrays, the function will traverse the PfnDatabase and clear the relevant pages backing PTE’s. The page frames can then be used to map a new AWE window.
Now that we know a little more we can understand why our proof of concept (POC) failed. During the mapping of the physical pages, there are a number of sanity checks when looking up the page frame numbers and the virtual address being mapped. One such lookup is that the virtual address being mapped exists in our AweInfo structure; this check fails since we could not guarantee our VirtualAlloc call in Process B to match Process A’s. Furthermore, we would probably also fail a PTE lookup since we did not provide a valid page frame number array to NtMapUserPhysicalPages in process B.
While we didn't see success on our first try, it shouldn't discourage us from digging a bit deeper into abusing memory-related APIs. This is just one potential abuse that did not work out, but one thing I noticed was the low amount of lock primitives used when remapping was performed. Also, NtFreeUserPhysicalPages was never mentioned or looked into, could we abuse the timing of how and when the Windows Memory Manager decides to actually free up the physical pages (the pages still contain data we wrote when the previous window is unmapped)?
I hope this tale of failure and knowledge encourages other researchers to go out there and fail to learn (and share!). Eventually the knowledge gained will serve its purpose in future endeavors.