So, it seems that not only ASUS drivers allows unprivileged reading and writing to physical memory. Just a few months ago I was looking at the drivers that are loaded on my machine, and I found small MSI driver called NTIOLib_X64.sys. Out of curiosity I’ve looked at it in IDA and it turned out that it has almost the same functionality as the ASMMAP/ASMMAP64 ASUS drivers. I’ve tried to contact MSI through various different channels, but I haven’t really get past their customer support, so I’m not sure if anyone from the development team is aware of this design flaw. After almost 4 months I decided to publish my findings here.

Brief description

NTIOLib.sys is installed with a few different MSI utilities that are part of the software package for MSI motherboards and graphic cards. WinIO.sys is completely different driver and is installed with Dragon Gaming Center application, which is part of the software package for MSI notebooks. Since both drivers expose physical memory access to the unprivileged users, I decided to put it into one report (I’ll describe the technical differences later). Actually when I was verifying list of affected software, I’ve found third driver that is doing exactly the same thing, just have a bit different interface and name (RTCore32.sys / RTCore64.sys).

Affected software:

• NTIOLib.sys / NTIOLib_X64.sys
• MSI FastBoot
• MSI Command Center
• MSI Live Update
• MSI Gaming APP
• MSI Super Charger
• MSI Dragon Center
• WinIO.sys / WinIO64.sys
• MSI Dragon Gaming Center
• MSI Dragon Center
• RTCore32.sys / RTCore64.sys
• MSI Afterburner

NTIOLib functionality exposed through IOCTLs:

• read/write physical memory (using MmMapIoSpace)
• read write MSR registers (using rdmsr/wrmsr opcodes)
• read PMC register (using rdpmc opcode)
• in/out port operations
• HalGetBusDataByOffset / HalSetBusDataByOffset

WinIO functionality exposed through IOCTLs:

• read/write physical memory (ZwMapViewOfSection of “\\Device\\PhysicalMemory”)
• in/out port operations

RTCore functionality exposed through IOCTLs:

• read/write physical memory (ZwMapViewOfSection of “\\Device\\PhysicalMemory”)
• read write MSR registers (using rdmsr/wrmsr opcodes)
• in/out port operations
• HalGetBusDataByOffset / HalSetBusDataByOffset

It appears that RTCore driver is kind of hybrid between NTIOLib and WinIO. It’s also worth noting that WinIO driver is just compiled (and signed by MSI) version of the code that can be found here: http://www.internals.com/utilities_main.htm.

UPDATE: RTCore driver is part of RivaTuner software, so all OEM branded RivaTuner clones are vulnerable (https://twitter.com/equilibriumuk/status/780367990160326656).

Some of the mentioned applications load vulnerable driver on demand, but some of them loads the driver with service startup and keeps it loaded for the whole time, thus exploitation is rather trivial. I haven’t thoroughly inspected all MSI applications, since it’s not really possible (different version of the software for different hardware, multiple installers etc), so it’s very probable that my list doesn’t cover all cases. Generally if someone owns any MSI hardware, it’s good to check if any of above drivers (or with similar name) is loaded, and if yes, just remove the application that installed it.

Disclosure timeline:

Technical details & PoC

After ASMMAP disclosure, I’ve read that the exploitation of this kind of vulnerability is rather easy:

This can be done by scanning for EPROCESS structures within memory and identifying one, then jumping through the linked list to find your target process and a known SYSTEM process (e.g. lsass), then duplicating the Token field across to elevate your process. This part isn’t really that novel or interesting, so I won’t go into it here.

Since I don’t have much experience in this area, I decided to try above method and see if the exploitation is really straightforward. I’ve started randomly poking with physical pages, just to see how it behaves. My first observation was, that the WinIO driver is a lot more stable than NTIOLib, it probably stems from the method that is used to expose physical memory to the user application (MmMapIoSpace vs ZwMapViewOfSection). NTIOLib tends to BSODs sometimes, especially if the accessed addresses are random (aligned to the 0x1000). My second observation was, that NTIOLib becomes quite stable if the memory is accessed sequentially (page by page). This is actually good, because EPROCESS search is sequential activity.

EPROCESS structures are allocated with Proc pool tag, this is the first indicator that EPROCESS search algorithm will look for. Each memory chunk starts with POOL_HEADER structure, followed by a few OBJECT_HEADER_xxx_INFO structures and finally by the OBJECT_HEADER. OBJECT_HEADER.Body is the actual EPROCESS. More details can be found in Uninformed Journal or in WRK (ObpAllocateObject, \wrk\base\ntos\ob\obcreate.c). On Windows 10 x64 (TH2, RS1) all those structures sums up to 0x80 bytes. To successfully execute local privilege escalation, I need to locate EPROCESS structure of 2 processes. One will be some system process and the second should be the process that privileges are supposed to be escalated. For system process I chose wininit.exe, and the escalated process will be the current process. Having names and PIDs of chosen processes, exploit can proceed to final EPROCESS verification (checks of UniqueProcessId and ImageFileName fields).

With above information it is possible to test initial exploit – it is very slow, so slow that I haven’t wait till it finish. The slowdown comes from accessing addresses that are reserved for hardware IO devices. Those reserved memory ranges will vary from one machine to another, so it’s required to find them out and skip during EPROCESS search. The easiest method to get those ranges is calling NtQuerySystemInformation with SuperfetchInformationClass (http://www.alex-ionescu.com/?p=51), however this call requires elevation, so it has no use in this case. Second place where this information can be obtained is WMI (CIMV2, Win32_DeviceMemoryAddress). This method is not as accurate as SuperfetchInformationClass, but I decided to use it in my PoC. Information returned on VMware test system were 100% accurate, and the slowdown disappeared, however I was still experiencing slowdown on my host machine. I come up with really simple and ugly solution: I’ve added hardcoded <0xF0000000-0xFFFFFFFF> region to the ranges returned from WMI. At this point PoC successfully runs on both VMware test machine (Win10 x64 TH2) and my host machine (Win10 x64 RS1):

  Whoami: secret\user
  Found wininit.exe PID: 000002D8
  Looking for wininit.exe EPROCESS...
  EPROCESS: wininit.exe, token: FFFF8A06105A006B, PID: 2D8
  Stealing token...
  Stolen token: FFFF8A06105A006B
  Looking for MsiExploit.exe EPROCESS...
  EPROCESS: MsiExploit.exe, token: FFFF8A0642E3B957, PID: CAA8
  Reusing token...
  Whoami: nt authority\system

Over-engineered version of PoC can be found on github (Visual Studio 2015 recommended):

https://github.com/rwfpl/rewolf-msi-exploit

It has hard-coded EPROCESS field offsets, so it only works on Win10 x64 TH2/RS1. PoC should work with any version of NTIOLib and WinIO drivers. I haven’t fully analyzed RTCore interface due to the fact, that I found it just today, so obviously it is not included in PoC.

If anyone has any suggestions, thoughts or just want to point out some mistakes, please leave a comment below.