Merry Hackmas: multiple vulnerabilities in MSI’s productsYlabs
Reading Time: 2 minutes
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
MmMapIoSpacefunction call, mapping physical memory into a virtual address user-space.
- Read/write Model-Specific Registers (MSRs) via the
- Read/write 1/2/4 bytes to or from an IO port.
- MSIAfterburner <= 220.127.116.1117 Beta 4
RTCore32.sys - 413433EF697784B599FEA00DBD841B1BBEFB19C2
RTCore32.sys - B3EBAF47B4B0D3C9B0FC9EBC31642E25939A97E1
RTCore64.sys - 4FE873544C34243826489997A5FF14ED39DD090D
RTCore64.sys - CC3E5E45ACA5B670035DFB008F0A88CECFD91CF7
- MSI App Player <= 4.280.1.6309
NTIOLib_X64.sys - AE3763CBBD21F6E561AC502D2EE7FE8EDFB2292D
- MSI Center <= 18.104.22.168
- MSICenter Pro <= 22.214.171.124
- MSIDragon Center <= 126.96.36.199
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 DetailsAll 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.
VulnerabilitiesSpecifically, all the vulnerabilities are triggered by sending IOCTL requests and will allow to:
Get/Set BusDataByOffsetAllows 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 bytesAllows 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 PrimitiveSince we can control all the parameters of the
MmMapIoSpacefunction, 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 PrimitiveModel-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_LSTARregister is used during a system call transition from user-mode to kernel-mode. The transition to kernel-mode can be schematized as follows:
- kernel function handles the syscall logic
__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.