Back to Posts

Merry Hackmas: multiple vulnerabilities in MSI’s products

Posted by: voidsec Post Date: December 16, 2021


Reading Time: 3 minutes

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.

Vulnerable Products

  1. MSI App Player <= 4.280.1.6309
  2. MSI Center <= 1.0.31.0
  3. MSICenter Pro <= 2.0.16.0
  4. 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:

  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

Back to Posts