Merry Hackmas: multiple vulnerabilities in MSI’s products
This blog post serves as an advisory for a couple of MSI’s products that are affected by multiple high-severity vulnerabilities in the driver components they are shipped with.
All the vulnerabilities are triggered by sending specific IOCTL requests and will allow to:
- Directly interact with physical memory via the
MmMapIoSpace
function call, mapping physical memory into a virtual address user-space. - Read/write Model-Specific Registers (MSRs) via the
__readmsr/__writemsr
functions calls. - Read/write 1/2/4 bytes to or from an IO port.
An attacker could exploit these issues to achieve local privilege escalation (LPE/EoP) from a low-privileged user to NT AUTHORITY\SYSTEM
.
This blog post is a re-post of the original article “Multiple escalation of privileges in MSI’s products” that I have written for Yarix on YLabs.
Table of Contents
Vulnerable Products
- MSI App Player <= 4.280.1.6309
- MSI Center <= 1.0.31.0
- MSICenter Pro <= 2.0.16.0
- MSIDragon Center <= 2.0.116.0
Vulnerable Driver Components:
atidgllk.sys - D299A2420F92A1F0150265F26D496AE587A681DA
atillk64.sys - C52CEF5B9E1D4A78431B7AF56A6FDB6AA1BCAD65
MODAPI.sys - D25340AE8E92A6D29F599FEF426A2BC1B5217299
NTIOLib.sys - CFD03C6FA17F369E5D7286D1B8A97C49DDAE93A3
NTIOLib.sys - FC639CC99362DF79D7AAC31057740C515205A6C4
NTIOLib.sys - 4C9691E9B87DC84619E30C6EB21256369EFB8996
NTIOLib_X64.sys - AE3763CBBD21F6E561AC502D2EE7FE8EDFB2292D
NTIOLib_X64.sys - 9F31AD3DBA608773EBE62962D654508D7787FF08
NTIOLib_X64.sys - DB4C5957DBDA3D3691AA1E393D1F63AD0B049DF5
NTIOLib_X64.sys - AD31989CC268ABF8CB36BF44C2087AA761F30F3E
WinRing0.sys - 8AC34EB21B9B38F67CD29684C45696C20AB2E75A
WinRing0x64.sys - D25340AE8E92A6D29F599FEF426A2BC1B5217299
Technical Details
All the vulnerabilities are caused by well-known open-source vulnerable drivers as well as MSI proprietary driver components with similar functionalities (sometimes directly copied from the open-source projects).
While I’m still waiting for MITRE issuing the related CVEs (Ref. #1184151), I would also like to point out that many of these findings collided with another fellow security researcher @X2FuYWdyYW1f.
Vulnerabilities
Specifically, all the vulnerabilities are triggered by sending IOCTL requests and will allow to:
Get/Set BusDataByOffset
Allows a low privilege user to write data to the I/O bus, possibly changing PCI configuration information, or vendor-specific data registers.
Read/Write 1/2/4 bytes
Allows a low privilege user to read/write 1/2/4 bytes to or from an IO port. Since I/O privilege level (IOPL) equals to current privilege level (CPL), it is possible to interact with peripheral devices such as the HDD and GPU to either read/write directly to the disk or invoke Direct Memory Access (DMA) operations. For example, communicating with ATA port IO for directly writing to the disk, then overwriting a binary that is loaded by a privileged process.
MapPhysicalMemory – Read/Write-What-Where Primitive
Since we can control all the parameters of the MmMapIoSpace
function, we will possibly be able to specify a physical memory address and offset and copy a user-controlled buffer into that space once it is mapped into our process space. This is essentially a Read/Write-What-Where exploit primitive.
Using VDM this vulnerability can be quickly weaponized into a full-fledged exploit.
Write MSRs – Pointer Overwrite Primitive
Model-Specific Registers (MSRs) are registers used for toggling or querying CPU info. The most interesting thing about MSRs is that on modern systems the MSR_LSTAR
register is used during a system call transition from user-mode to kernel-mode.
The transition to kernel-mode can be schematized as follows:
- syscall
- read
MSR_LSTAR
register - call
MSR_LSTAR
pointer (ring-0) - kernel function handles the syscall logic
Exposed WRMSR (__writemsr
) instruction gives us a pointer overwrite primitive, the function pointer is called when any syscall is issued and it is called from ring-0. Using msrexec we can quickly weaponize it into a full-fledged exploit.