ASUS, GIGABYTE Drivers Contain Code Execution Vulnerabilities – PoCs Galore

Four drivers from ASUS and GIGABYTE come with several vulnerabilities that can be leveraged by an attacker to gain higher permissions on the system and to execute arbitrary code.

In total, there are seven vulnerabilities affecting five software products, and researchers wrote exploit code for each of them. Many of them might still be unaddressed.

Two of the vulnerable drivers are installed by the Aura Sync software (v1.07.22 and earlier) from ASUS and the flaws they carry can be exploited for local code execution.

The drivers from GIGABYTE are distributed with motherboards and graphics cards of the same brand as well as from the company’s subsidiary, AORUS.

The vulnerabilities lead to privilege escalation via software like the GIGABYTE App Center (v1.05.21 and below), AORUS Graphics Engine (v1.33 and below), the XTREME Engine utility (v1.25 and earlier), and OC Guru II (v2.08).
Three bugs found in ASUS’ GLCKIo and Asusgio drivers

Aura Sync is a utility that enables the user to synchronize the lighting via RGB strips used with compatible products such as motherboards, graphics cards, and peripherals (keyboards, mice) for a personalized gaming experience.

When added to the system, Aura Sync also installs the GLCKIo and Asusgio drivers, which are vulnerable to CVE-2018-18537, CVE-2018-18536, CVE-2018-18535 security bugs that allow code execution.

Diego Juarez, exploit writer at SecureAuth discovered and studies these flaws; the security company disclosed them responsibly but after releasing two new versions for Aura Sync, ASUS still left two of the vulnerabilities unaddressed, the researchers say in an advisory published today.

CVE-2018-18537 can be exploited in the GLCKIo driver by writing an arbitrary “double word” [DWORD] to an arbitrary address. To demonstrate the flaw, the researchers created a proof-of-concept (PoC) that ends with triggering a system crash.

The second glitch, CVE-2018-18536, is in both the GLCKIo and Asusgion drivers and consists in exposing a way that permits reading and writing data from and to IO ports.

“This could be leveraged in a number of ways to ultimately run code with elevated privileges,” says SecureAuth

They showed the possible effects of the bug with a PoC that rebooted the computer, although it could be used for more damaging results.

CVE-2018-18535 was discovered in Asusgio and it also exposes a read/write method, this time for model-specific registers (MSRs). It could be leveraged to run arbitrary code with the highest privileges (ring-0, reserved for the operating system kernel).

MSRs are control registers particular to the CPU architecture that provide access to CPU features for debugging, or performance monitoring, or program execution tracing. They can be accessed via privileged instructions ‘rdmsr’ and ‘wrmsr’ that can be executed only by code with ring-0 privilege level.

A PoC from the researchers shows that CVE-2018-18535 in the Asusgio driver allows insecure access to MSRs by leaking a kernel function pointer that bypasses the kernel address space layout randomization (KASLR). The result is an instant BSOD (blue screen of death).
Broken communication

According to the disclosure timeline published by SecureAuth, the communication with ASUS began in November 2017. ASUS acknowledged a draft report with the vulnerabilities on February 2, 2018, and 19 days later said it would update the Aura Sync utility in April.

On March 26, ASUS informed SecureAuth that the vulnerabilities were addressed; that was the last reply from ASUS, SecureAuth says.

The security company asked for clarifications when it noticed that an update for Aura Sync in April still included the security faults. A subsequent release for the software became available, spotted in May, and SecureAuth determined that it fixed only one of the three problems.
GIGABYTE drivers allow interaction with non-privileged processes

Juarez also analyzed GPCIDrv and GDrv drivers from GIGABYTE and found that they can receive system calls from non-privileged user processes, even those running at a low integrity level, considered by Windows to run code that is not trusted.

The first vulnerability he uncovered, now tracked as CVE-2018-19320, offers an attacker the possibility to take full control of the system.

To highlight this, Juarez created a PoC for GDrv where non-privileged read/write access is granted to arbitrary virtual memory. Since it is for demo purposes, all his code does is trigger a system crash.

The second bug, identified as CVE-2018-19322, exposes a way to use non-privileged access to read and write data from and to input/output ports.

It affects both drivers from GIGABYTE and enables an attacker to increase their privileges on the system. Juarez’ exploit code only reboots the computer, but it could be altered for a more dangerous outcome.

A way to access MSR registers from a non-privileged level is also exposed by GDrv, allowing the possibility to execute arbitrary code with ring-0 permissions.

Identified as CVE-2018-19323, the flaw has been demonstrated with an exploit code that causes a BSOD. The exploit achieves by leaking a kernel function pointer and bypassing the KASLR protection.

Both GPCIDrv and GDrv are vulnerable to CVE-2018-19321 according to the research from SecureAuth. It is a memory corruption glitch that could put an attacker in full control of the affected system.

The PoC provided to BleepingComputer is harmless as all it does is crash the computer but it has the potential to create more trouble than this.

According to the disclosure timeline in the advisory from SecureAuth, the company tried to contact GIGABYTE about the issues starting April 24, 2018, and received a reply six days later.

After several email exchanges that led to no positive result, Gigabyte responded that its products were not affected by the disclosed vulnerabilities.
GIGABYTE communication also unfruitful

The disclosure timeline in SecureAuth’s advisory indicates that GIGABYTE did not address any of the issues mentioned above, despite receiving a technical description and the demo exploit code.

In May 2018, “Gigabyte Technical support team answered that Gigabyte is a hardware company and they are not specialized in software. They requested for technical details and tutorials to verify the vulnerabilities,” SecureAuth discloses.

The last answer received from the hardware company dismissed the vulnerabilities completely, as “Gigabyte responded that, according to its PM and engineers, its products are not affected by the reported vulnerabilities,” SecureAuth says.