CVE-2019-8372
LG Device Manager LHA, arbitrary kernel write via insufficient IOCTL validation
Summary
| Field | Value |
|---|---|
| Driver | LG LSB driver (lha.sys / LgCoreTemp.sys) |
| Vendor | LG Electronics |
| Vulnerability Class | Arbitrary Write / IOCTL Access Control |
| Abused Version | Various versions shipped with LG Device Manager |
| Status | Withdrawn — driver removed from LG software |
| Exploited ITW | No |
The Story
LG Device Manager ships a kernel driver for laptop management features like temperature monitoring and power management. Jackson Thuraisamy discovered that the driver exposes an IOCTL that writes to arbitrary kernel memory addresses with no validation whatsoever. The user-supplied buffer contains a target address and a value, and the driver writes the value directly to the address.
This is not a buffer overflow or a race condition. It is a design choice: the IOCTL handler takes an address from user mode and writes to it in kernel mode, trusting that only the legitimate LG utility would ever call it. The device object has permissive ACLs, so any process can open a handle and send the write IOCTL.
Thuraisamy documented the complete discovery and exploitation process at jackson-t.ca, walking through how the arbitrary write primitive can be leveraged for local privilege escalation.
BYOVD Context
- Driver signing: Authenticode-signed by LG Electronics with valid certificate
- Vulnerable Driver Blocklist: Not included in Microsoft's recommended driver block rules
- HVCI behavior: May load on HVCI-enabled systems if not hash-blocked
- KDU integration: Not integrated
- LOLDrivers: Listed at loldrivers.io
Affected IOCTLs
- Arbitrary kernel memory write via IOCTL with user-controlled address and value
From a Single Write to SYSTEM
The exploitation chain demonstrates how a single arbitrary write primitive can be amplified into full kernel control. The attacker opens the device handle through the permissive ACLs and sends the write IOCTL with a carefully chosen target: the PreviousMode field of the current thread's KTHREAD structure. Writing zero to this field switches the thread from UserMode to KernelMode, causing all subsequent NtReadVirtualMemory and NtWriteVirtualMemory calls to bypass ProbeForRead/ProbeForWrite checks.
With PreviousMode zeroed, the attacker has full arbitrary read/write over the entire kernel address space using standard Nt* APIs. From there, locating the SYSTEM token and swapping it into the current process is the standard escalation path.
The key insight is that a single write to the right location is sufficient for full compromise. The attacker does not need to spray the heap, win a race, or chain multiple primitives. One write to PreviousMode unlocks everything.
Detection
YARA Rule
rule CVE_2019_8372_LG_Driver {
meta:
description = "Detects LG LSB vulnerable driver"
cve = "CVE-2019-8372"
author = "KernelSight"
severity = "high"
strings:
$mz = { 4D 5A }
$lha = "lha.sys" wide ascii nocase
$lg_core = "LgCoreTemp" wide ascii nocase
$lg = "LG Electronics" wide ascii
condition:
$mz at 0 and ($lha or $lg_core or $lg)
}
ETW Indicators
| Provider | Event / Signal | Relevance |
|---|---|---|
| Microsoft-Windows-Kernel-File | Driver load event | Detects loading of LG driver |
| Sysmon | Event ID 6 — Driver loaded | Hash and signature capture |
| Microsoft-Windows-Security-Auditing | Event 4697 — Service installed | Driver service creation |
| Microsoft-Windows-Kernel-Process | Process token modification | Post-exploitation token swap |
Behavioral Indicators
- Loading of LG kernel driver outside of LG Device Manager installation
- Arbitrary write IOCTL calls from non-LG processes
- PreviousMode modification on the current thread following IOCTL interaction
- Privilege escalation from medium to SYSTEM integrity after driver interaction
Broader Significance
CVE-2019-8372 demonstrates the minimum BYOVD primitive needed for full kernel compromise: a single arbitrary write. When the target is PreviousMode, one write converts a constrained primitive into unrestricted kernel access. This pattern recurs across the BYOVD landscape and highlights why even "limited" write primitives (as opposed to full read/write drivers) should be treated as critical. For driver developers, the lesson is that any IOCTL accepting a kernel address from user mode is a privilege escalation vulnerability, regardless of what value it writes.