Dell Patches Vulnerability in Pre-installed SupportAssist Utility

[steven36]

Dell recently addressed a local privilege escalation (LPE) vulnerability in SupportAssist, a tool pre-installed on most of all new Dell devices running Windows.

 

 

The security issue resides in a kernel driver the tool loads, Bryan Alexander, the security researcher who discovered the issue, reveals. The Dell SupportAssist tool is mainly used to troubleshoot issues and offer support to both the user and Dell.

The vulnerability can be abused to bypass driver signature enforcement (DSE) ad infinitum, the researcher says. The driver, he explains, exposes a lot of functionality, providing “capabilities for reading and writing the model-specific register (MSR), resetting the 1394 bus, and reading/writing CMOS.”

The impacted driver is first loaded when SupportAssist is launched (filename pcdsrvc_x64.pkms or pcdsrvc.pkms, depending on architecture). Although used by Dell, the driver is built by PC-Doctor, a company that offers “system health solutions” to computer makers such as Dell, Intel, Yokogawa, IBM, and others.

“Once the driver is loaded, it exposes a symlink to the device at PCDSRVC{3B54B31B-D06B6431-06020200}_0 which is writable by unprivileged users on the system. This allows us to trigger one of the many IOCTLs exposed by the driver; approximately 30,” the researcher explains.

Alexander also found a DLL used by the userland agent that also worked as an interface to the kernel driver and had symbol names available. Further analysis revealed a MemDriver class that allow userland services to read and write arbitrary physical addresses.

For that, however, the driver must be ‘unlocked’ to start processing control codes. To unlock it, one would simply need to send a system call (ioctl) containing the proper code. Next, the driver sets a global flag and “will process control codes for the lifetime of the system,” the researcher notes.

To exploit the issue, one can start reading physical memory looking for process pool tags, then identify a target process and a SYSTEM process, and then steal the token.

“However, PCD appears to give us a shortcut via getPhysicalAddress ioctl. If this does indeed return the physical address of a given virtual address (VA), we can simply find the physical of our VA and enable a couple token privileges using the writePhysicalMemory ioctl,” the researcher notes.

The issue, nevertheless, is that only usermode addresses can be resolved this way, as the MmProbeAndLockPages call is passing in UserMode for the KPROCESSOR_MODE.

Even so, one could still read chunks of physical memory, and the researcher used that to toggle on SeDebugPrivilege for the current process token (which requires “finding the token in memory and writing a few bytes at a field offset”).

Once the physical address of the token has been identified, the researcher triggered two separate writes at the Enabled and Default fields of a _TOKEN. The researcher published the source code of the bug on GitHub.

The vulnerability was reported to Dell in early April, but a patched version of SupportAssist was only released last week.

 

Source