May 4, 2021
Our Technology Partner SentinelOne announced today that hundreds of millions of Dell Computers (desktops, laptops, notebooks, and tablets), could be vulnerable to a BIOS Driver Privilege Escalation Flaw.
Several months ago, SentinelOne began investigating the security posture of the firmware update driver version 2.3 (dbutil_2_3.sys) module, which seems to have been in use since at least 2009. Today, the firmware update driver component, which is responsible for Dell Firmware Updates via the Dell Bios Utility, comes pre-installed on most Dell machines running Windows and freshly installed Windows machines that have been updated. Hundreds of millions of Dell devices have updates pushed on a regular basis, for both consumer and enterprise systems.
This led to the discovery of five high severity bugs that have remained undisclosed for 12 years. These multiple high severity vulnerabilities in Dell software could allow attackers to escalate privileges from a non-administrator user to kernel mode privileges. Over the years, Dell has released BIOS update utilities which contain the vulnerable driver for hundreds of millions of computers (including desktops, laptops, notebooks, and tablets) worldwide.
Dell has assigned one CVE to cover all the flaws in the firmware update driver, but this single CVE can be broken down into the following five separate flaws:
CVE-2021-21551: Local Elevation Of Privileges #1 – Memory corruption
CVE-2021-21551: Local Elevation Of Privileges #2 – Memory corruption
CVE-2021-21551: Local Elevation Of Privileges #3 – Lack of input validation
CVE-2021-21551: Local Elevation Of Privileges #4 – Lack of input validation
CVE-2021-21551: Denial Of Service – Code logic issue
This alert describes some of the general problems with this driver. However, to enable Dell customers the opportunity to remediate this vulnerability, SentinelOne is withholding sharing their Proof of Concept details until June 1, 2021. That proof of concept will demonstrate the first local EOP which arises out of a memory corruption issue.
The first and most immediate problem with the firmware update driver arises out of the fact that it accepts IOCTL (Input/Output Control) requests without any ACL requirements. That means that it can be invoked by a non-privileged user:
Allowing any process to communicate with your driver is often a bad practice since drivers operate with the highest of privileges; thus, some IOCTL functions can be abused “by design”.
The firmware update driver exposes many functions via IRP_MJ_DEVICE_CONTROL. The most obvious bug to exploit gives you an extremely powerful primitive. Via IOCTL 0x9B0C1EC8, it is possible to completely control the arguments passed to memmove, thus, allowing an arbitrary read/write vulnerability:
A classic exploitation technique for this vulnerability would be to overwrite the values of Present and Enabled in the Token privilege member inside the EPROCESS of the process whose privileges we want to escalate:
This can be triggered and exploited quite simply:
Another interesting vulnerability in this driver is one that makes it possible to run I/O (IN/OUT) instructions in kernel mode with arbitrary operands (LPE #3 and LPE #4). This is less trivial to exploit and might require using various creative techniques to achieve elevation of privileges.
Since IOPL (I/O privilege level) equals CPL (current privilege level), it is obviously possible to interact with peripheral devices such as the HDD and GPU to either read/write directly to the disk or invoke DMA operations. For example, we could communicate with ATA port IO for directly writing to the disk, then overwrite a binary that is loaded by a privileged process.
The following code illustrates direct read/write using ATA port IO and shows how to invoke those IOCTLs (IN/OUT wrappers are abstracted):
Writing directly to the HDD without creating an IRP for that disk write basically bypasses all security mechanisms in the operating system and allows an attacker to write to any sector on the disk.
For example, here is code from the LearnOS repository that takes advantage of IN/OUT instructions for direct HDD writing:
Interestingly, unrelated to the IOCTL handler bugs, the driver file itself is located in C:\Windows\Temp, which is also a bug itself and opens the door to other issues. The classic way to exploit this would be to transform any BYOVD (Bring Your Own Vulnerable Driver) into an Elevation of Privileges vulnerability since loading a (vulnerable) driver means you require administrator privileges, which essentially eliminates the need for a vulnerability. Thus, using this side noted vulnerability virtually means you can take any BYOVD to an Elevation of Privileges.
Here you can see a proof-of-concept to demonstrate the first LPE due to memory corruption:
The high severity flaws could allow any user on the computer, even without privileges, to escalate their privileges and run code in kernel mode. Among the obvious abuses of such vulnerabilities are that they could be used to bypass security products.
An attacker with access to an organization’s network may also gain access to execute code on unpatched Dell systems and use this vulnerability to gain local elevation of privilege. Attackers can then leverage other techniques to pivot to the broader network, like lateral movement.
This vulnerability and its remedies are described in Dell Security Advisory DSA-2021-088. We recommend Dell customers, both enterprise and consumer, apply the patch as soon as possible.
While Dell is releasing a patch (a fixed driver), note that the certificate was not yet revoked (at the time of writing). This is not considered best practice since the vulnerable driver can still be used in a BYOVD attack as mentioned earlier. Please see the Dell Security Advisory for complete remediation details.
These high severity vulnerabilities, which have been present in Dell devices since 2009, affect hundreds of millions of devices and millions of users worldwide. Similar to a previous vulnerability that was hidden for many years, the impact this could have on users and enterprises that fail to patch is far-reaching and significant.
While SentinelOne hasn’t seen any indicators that these vulnerabilities have been exploited in the wild up till now, with hundreds of millions of enterprises and users currently vulnerable, it is inevitable that attackers will seek out those that do not take the appropriate action. Our reason for publishing this research is to not only help our customers but also the community to understand the risk and to take action.
We (Avertium) would like to thank SentinelOne and Dell for their approach to this disclosure and for remediating the vulnerabilities.
We would like to thank SentinelOne and SentinelLabs for their research into this vulnerability. We know that many of our customers have Dell Technology deployed within their enterprise and thought it prudent to share this alert. The original information can be found here.
We, at Avertium, would also like to stress that although we haven’t seen any activity in the wild at this point, given the sheer numbers of affected assets and the possible severity of the vulnerability, swift action should be planned and acted on.