Before moving to my Stoned project I want to explain the pagefile attack presented by Joanna Rutkowska in a technical manner. I want to release technical information on how to that and make it "Open Information". I plan also to develop proof of concept code and making it Open Source. I will also release documents about it in future. I really have to criticize Rutkowska, because she did not release any technical information at all.
Peter Kleissner, Software Engineer (March 2009)
About the Pagefile Attack
The pagefile attack is about to use the fact that Windows is swapping out memory into the pagefile. The attack is based on modification of the pagefile - so indirectly the physical memory. The idea is to find specific memory in the pagefile, modifying it, and letting Windows reloading it without any verification. But there are a few limitations to consider, the most important one is that you can not directly access the pagefile. The file "C:\pagefile.sys" is locked for access, you can not open it by CreateFile. The system process has an open handled without any Shared Access flag set, so any access to pagefile.sys will fail consequently.
How to access the pagefile under Windows
So how to access the pagefile? By bypassing the Windows File overhead. This can be done by not using the CreateFile/WriteFile functions but direct driver communication. Direct driver communication can be done through 2 ways (and the first is the Windows File Management again):
- CreateFile with a valid DOS device name or device name (i.e. "\\.\PhysicalDrive0")
With the first you can open handles which can be used to send and receive (ReadFile, WriteFile) data to and from drivers. A driver can register a device name, and if you open a handle to the device you open a handle to the driver. Once opened, you can communicate with the driver, in the example you would directly do read/write operations on the hard disk (compare with Raw Sector Access). There was also an attack to physical memory, because the physical memory object "\Device\PhysicalMemory" was writable as non-Administrator in Windows XP (fixed in Service Pack 2).
You can use the DeviceIoControl function to directly send control codes (IOCTLs, I/O Control Codes) to the driver. Control codes tell the driver what to do. For the function you also need an open handle, but in difference to file mapped driver communication you can open a handle with the correct, undocumented flags. After you opened a handle to the driver using CreateFile, you can send IOCTLs using DeviceIoControl.
I'm glad to say that Microsoft started documenting the IOCTLs since late 2008, so there are now many documented IOCTLs in the connection with their next operating system Windows 7. The want people to NOT write drivers but use existing API functions. This is also a result from the fact that Windows Vista and newer only allow to load signed drivers, which means to have a company and pay for signing, and registering etc.
So hows done the magic to access the pagefile? By using the correct IOCTLs and flags:
- Open handle to NTFS file system driver of the volume via CreateFile by specifying "\\.\C:\" as file name and FILE_READ_ATTRIBUTES as desired access flag
- Receive cluster list by calling DeviceIoControl with FSCTL_GET_RETRIEVAL_POINTERS IOCTL
- Calculate start sector and count by LCN (Logical Cluster Number), data run and NTFS volume info (Sectors per Cluster, Clusters per Record)
- Read the data runs directly using raw sector access
Be sure to specify correct device name "\\.\[Drive Letter]:\" with the ending backslash, otherwise you would open a handle to the logical drive. The undocumented FILE_READ_ATTRIBUTES flag for the desired access allows you to send IOCTLs to the driver (but still forbids read/write IO). And this is exactly what we need, and what was done in the Pagefile Attack.
You need to know about the internal NTFS file structure, how clusters are stored. There is a concept used called "Data Runs" (also appearing in FAT file system), which means that multiple clusters are stored and remembered in a list as one single data run. All runs together make the file. The list of the data runs is received by the IOCTL FSCTL_GET_RETRIEVAL_POINTERS, and each element consists of next VCN and LCN. Next VCN tells you the starting virtual cluster number (starting from zero) inside the file, and LCN the logical cluster number on the drive. This concept, receiving the cluster list with the IOCTL, works for both FAT and NTFS.
I don't want to explain the full NTFS file system here but be aware of sparse data (= clusters which are fully zero, alpha compression), because they are not stored on NTFS but assigned as LCN -1. And do not forget compresson, encryption and resident data. Take a look at the NTFS documentation.
Like given in my Hibernation File Attack, the Pagefile Attack has also its limitations. First you need elevated Administrator rights for the driver communication. Second the Pagefile Attack works only up to Windows XP, Microsoft fixed the vulnerability in Windows Vista Release Candidate in response to the public presentation of the pagefile attack. Furthermore its important to say that it is a relative high expenditure to find and replace specific memory in the pagefile, so it is only limited qualified for real exploits used by malware.
- Vista RC2 vs. pagefile attack (and some thoughts about Patch Guard), Joanna Rutkowska in her blog "invisiblethings"
- Subverting Vista Kernel For Fun And Profit - presentation at Black Hat USA 2006
- Rutkowska's profile on Black Hat USA 2006