This blog post serves as an advisory for a couple 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.

Attacker could exploit these issues to achieve local privilege escalation (LPE/EoP) from a low-privileged users to NT AUTHORITY\SYSTEM.

Vulnerable Products

1. MSIAfterburner <= 4.6.4.16117 Beta 4

Vulnerable Driver Components:

• RTCore32.sys - 413433EF697784B599FEA00DBD841B1BBEFB19C2
• RTCore32.sys - B3EBAF47B4B0D3C9B0FC9EBC31642E25939A97E1
• RTCore64.sys - 4FE873544C34243826489997A5FF14ED39DD090D
• RTCore64.sys - CC3E5E45ACA5B670035DFB008F0A88CECFD91CF7

2. MSI App Player <= 4.280.1.6309

Vulnerable Driver Components:

• NTIOLib_X64.sys - AE3763CBBD21F6E561AC502D2EE7FE8EDFB2292D

3. MSI Center <= 1.0.31.0
4. MSICenter Pro <= 2.0.16.0
5. 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 - 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 we're 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:

1. syscall
2. read MSR_LSTAR register
3. call MSR_LSTAR pointer (ring-0)
4. 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.

Resources & References

• VDM & msrexec
• MSR Madness Infiltrate 2019

Author

Paolo Stagno (aka VoidSec) is a Vulnerability Researcher and Exploit Developer focused on Windows offensive application security (kernel and user-land). He enjoys understanding the digital world we live in, disassembling, reverse engineering and exploiting complex products and code.