Viper RGB Driver Local Privilege Escalation (CVE-2019-18845)
Recently, we found a Kernel logic bug in Viper RGB software version 1.0 which is used to manage Viper Gaming DRAM memory modules. The affected component of said software was MsIo64.sys/MsIo32.sys driver which was then utilized to achieve Local Privilege Escalation. The following is the process used to identify and exploit the security vulnerability. Let’s start off by examining the device permissions.
As you can see above the “Everyone” group has “All Access” permissions, meaning any low privileged process in user land can interact with the device driver and as such the next logical step was to reverse engineer the “MsIo” driver looking for bugs. During that process we first located the IOCTL dispatch routine, this routine consists of all available IOCTLs and the corresponding code paths that we can potentially hit from user land.
Going through the dispatch routine function we identify an interesting IOCTL code path, that is 0x80102040.
Following the branch, we notice a call to memmove() at offset 0x1623.
Using WinDbg we determine that the length and contents of the input buffer which we control via DeviceIoControl() will end up as the source and size parameters for memmove() function call. The following is the result of sending a QWORD value of 0x4141414141414141 as an input buffer.
Continuing down that path we reach another function call which we renamed to “IOCTL_MSIO_MAPPHYSTOLIN” based on the string provided by RCX parameter for DbgPrint() function call at offset 0x160b in the previous listing screenshot. The function takes RDX which holds the input buffer contents as second argument and then uses it for the “CommitSize” parameter at the start of said function.
And then a call to ZwOpenSection() function is initiated to open section handle to “\Device\PhysicalMemory” via the “OBJECT_ATTRIBUTES” structure.
Lastly, the “CommitSize” provided by the input buffer is used in ZwMapViewOfSection() function call to map the previously allocated section handle into the calling process.
In summary, we can access an arbitrary physical memory from a low privileged process which ultimately leads to elevation of privileges by locating “EPROCESS” structures within the mapped physical memory range and conduct a token stealing attack against any process with “NT AUTHORITY\SYSTEM” privileges. The following is a demonstration of working exploit for Windows 7 and Windows 10 machines respectively.
Please note that the above exploits were heavily based on prior work done by b33f in the Razer Kernel driver bug found here. At that point we sent the vulnerability details to the vendor and a patch was released in version 1.1 addressing this vulnerability.
Feel free to reach out at labs@activecyber.us if you have any questions. Also, see the link here for complete list of ACTIVELabs advisories.
Affected Products
Viper RGB version 1.0
Disclosure Timeline
10-04-19: ACTIVELabs contacted Patriot Memory on Twitter requesting security contact
10-04-19: Patriot Memory asked to send vulnerability details to support@patriotmem.com
10-04-19: ACTIVELabs sent vulnerability details to Patriot Memory support
10-09-19: ACTIVELabs requested an update
10-09-19: Patriot Memory support responded that R&D team are in the process of testing and patching the vulnerability
10-28-19: Patriot Memory support communicated that patch has be produced and requested ACTIVELabs to test the patch before release
11-01-19: ACTIVELabs confirmed the patch has nullified the vulnerability
11-05-19: Patriot Memory informed ACTIVELabs the patch has been pushed to the website and requested to provide CVE number once assigned
11-08-19: ACTIVELabs publishes an advisory
11-08-19: ACTIVELabs request CVE from MITRE
11-09-19: CVE-2019-18845 assigned
11-26-19: ACTIVELabs publishes this blog post