Researchers at SentinelLabs say that they found various exploitable bugs in one of Dell’s Windows kernel drivers, which they reported back in December 2020.
There were five related bugs, now collectively dubbed CVE-2021-21551.
Dell has now issued a patch for these vulnerabilities (the official update is dated 2021-05-04), noting that:
Dell dbutil_2_3.sys driver contains an insufficient access control vulnerability which may lead to escalation of privileges, denial of service, or information disclosure. Local authenticated user access is required.
Expunging the bugs
The good news, therefore, is that even though these bugs are dangerous, they don’t let cybercriminals break into your network in the first place, and they’ve now been fixed.
The bad news, however, is that the bugs seem to go all the way back to 2009, with the result that Dell’s official list of affected products stretches for pages and pages.
Dell’s documentation is split into two lists of devices that need updating:
- Table A: Supported Dell platforms. There are 381 model names here, including Dell brands such as Inspiron, Latitude, OptiPlex, Precision, Vostro. XPS and even some Dell Dock devices.
- Table B: End of Service Life Dell platforms. A further 195 model names are listed, including seven Alienware computers.
Dell has included instructions for manually removing the buggy kernel driver, which it says will be found in one of two places:
C:\Users\%USERNAME%\AppData\Local\Temp\dbutil_2_3.sys
C:\Windows\Temp\dbutil_2_3.sys
If you are nervous about removing system files by hand, the company has published a download page with an automatic driver remover with the remarkable name of Dell-Security-Advisory-Update-DSA-2021-088_7PR57_WIN_1.0.0_A00.EXE.
Unfortunately, just removing the old driver is not enough on its own, because the old firmare update utility left behind on your computer may inadvertently reinstall the buggy driver, thus reintroducing the bug.
According to Dell, you also need to download and install an updated firmware update program that knows about and includes a patched version of the flawed dbutil_2_3.sys kernel module.
Updated firmware updaters are available right now for Windows 10, but for earlier Windows versions (Dell still supports both Windows 8.1 and Windows 7, it seems), the update-to-the-updater will only be available “by 31 July 2021.”
In other words (and although this sounds tricky, it’s more a question of fuss than complexity):
- Get rid of the old
dbutil_2_3.sysdriver, either by hand or using Dell’s dedicated tool-with-a-very-long-name. - Update the Dell firmware update utility, assuming that an update is available.
- If you can’t yet do step 2, remember to repeat step 1 every time that you run the old firmware updater, in case the update process itself quietly reinstalls the old driver.
What harm could the buggy driver do?
The researchers who investigated the flawed driver found a number of problems with it, starting with the fact that any user, whether an administrator or not, could issue low-level configuration commands to the driver itself.
That’s not automatically a bug, as long as the scope of those configuration commands is carefully limited.
As an example, a security program with a driver that allowed unprivileged users to issue a command to opt in to increased protection would probably be considered OK, but one that allowed anyone to opt out of protection whenever they felt like it would clearly be no good at all.
However, in this case, the researchers discovered driver coding flaws that could allow unprivileged driver commands either to crash the driver and bring down the system (denial of service) or to promote the user issuing the commands to a local administrator (elevation of privilege).
Although those coding bugs would have needed fixing anyway, their impact would have been much less serious if attackers who wanted to exploit them needed to have administrator privileges already.
After all, if you already have sysadmin powers, you don’t need an elevation of privilege bug because you already have elevated privileges.
Interestingly, the researchers also noted that it might be possible to abuse one of the bugs in dbutil_2_3.sys to write to the hard disk in undocumented, low-level ways, bypassing the usual Windows system calls for disk access.
Given that a user with administrator powers could probably write pretty much anywhere on your hard disk anyway, this issue doesn’t add much extra danger over and above the elevation of privilege bug that already exists.
In theory, however, this flaw could be abused by attackers who were already administrators in order to access or manipulate data without using a conventional sequence of system commands, thus potentially bypassing various logging or security settings that might otherwise catch them out.
LISTEN NOW: UNDERSTANDING VULNERABILITIES
Learn more about vulnerabilities, how they work, and how to defend against them.
Recorded in 2013, this podcast is still an excellent and jargon-free explainer of this vital topic.
Click-and-drag above to skip to any point in the podcast. You can also listen directly on Soundcloud.
Bring Your Own Bug
Another obvious problem with this driver is that it lives either in your own or the system’s TEMP directory, where an attacker who is already in your network could easily overwrite it with an older, buggier version in order to force what’s known as a downgrade or a BYOB (bring your own bug) attack.
Remember that attackers can’t easily install their own malicious kernel drivers these days, because those drivers would need to be submitted to Microsoft first to be digitally signed.
(Not even sysadmins can load unsigned kernel drivers any more on 64-bit versions of Windows without rebooting into a special startup mode used for driver testing; on the next reboot after that, signed driver enforcement is automatically re-enabled.)
However, canny cybercrimimals sometimes try to install old-but-signed drivers quite deliberately in order to reintroduce old vulnerabilities, notably elevation of privilege or other security bypass bugs that you thought you’d patched long ago.
In other words, if you remove the vulnerable driver without also updating the firmware update utility that is coded to look for the driver in the TEMP folder, you run a risk not only that the firmware utility itself might reinstall an old version of the driver, but also that an attacker already inside your network might do so, too.
We assume that Dell’s updated firmare update tool (see step 2 above) not only includes a patched driver but also installs that driver in a safer place.
As mentioned above, however, you can’t update Dell’s firmware utility yet if you have Windows earlier than version 10.
We therefore recommend that you keep your eye out for the reappearance of a file called dbutil_2_3.sys in either of the TEMP locations listed above, in case your system gets downgraded, either by accident or by design.
What to do?
- If you are a user: visit the relevant security advisory page on Dell’s website and follow the instructions to remove the buggy driver. Also update the entire Dell firmware update utility as soon as you can, which is right now for Windows 10 and some time before 31 July 2021 for earlier versions of Windows.
- If you work in the cybersecurity operations team: check your hardware inventory against Dell’s list of affected models to make sure you don’t miss any. Make a list of computers that needed updating and keep an eye on the abovementioned
TEMPdirectories for the unwanted reappearance of the buggy driver file, which could be an IoC (indicator of compromise). - If you are a programmer: don’t give unprivileged users access to driver control functions they don’t need. Poor access control was not the root cause of the bugs in this case, but stricter access to the driver itself would have mitigated the risk by restricting the privilege escalation exploits to users who were already privileged anyway.
- If you work in quality assurance or in the code review team: make a regular habit of revisiting legacy driver code. Loosely speaking, the older a driver, the less likely that it was originally coded in accordance with contemporary attitudes to and guidelines for cybersecurity.
If you have the Sophos Endpoint Detection and Response (EDR) product, we have created a system query you can use to hunt for buggy Dell drivers on your network. Head to our article on Sophos News to find out how to use it.
John
There might be one “in” missing in “Dell fixes exploitable holes its own firmware update driver – patch now!”
Paul Ducklin
Hahahahaha, “there might be” is very polite way of putting it :-)
Following a careful search I found a spare one so I have now, errrr, added the missing in in in pursuit of correctness.
Thanks!
Logan
Thanks for the info. Dell has been stumbling lately with unsigned drivers in Dell Support Assist and inaccurate shipping promises. The later due to global supply chain issues but the way they communicate ship times is very confusing and usually wrong from day to day. Another mess, another straw on the camels’ back.
Mark Bennett
Are they really issuing a new file, but re-using the same filename of dbutil_2_3.sys? So you can’t really know if the file you’re looking at is the old or new version of the file? I realize it would be easy to rename the file, but at least make it easier to identify the bad from the good program.
Paul Ducklin
I don’t know quite how much has been “fixed” so far. There’s a bunch of issues mixed up here: the root cause bugs involving memory and integer variable errors, and the circumstantial (probably not the right word but I can’t think of a better one ATM -) problems of having a driver that doesn’t have precautionary access control on its IOCTLs, and runs from a badly chosen directory.
Dell’s own notification page describes CVE-2021-21551 (which actually covers a bunch of bugs I didn’t expect to see rolled up into a single CVE number) as an “insufficient access control vulnerability”, and therefore it’s not clear whether the bugs-below-that-bug were patched at all, or if the underlying bugs were just temporarily “shielded” behind a layer of newly-set ACLs.
TBH, I was expecting to see Dell explicitly referring to “memory corruption” and “input validation” in its security advisory, as a signifier of the sort of code updates included in the fix.
If you install the updated firmware updater as well as deleting the errant driver, and then force a firmware update with the new updater, does a driver with a name like “dbutil” appear anywhere? If so, where does the “new” driver go? (If the current fix doesn’t deal with the underlying bugs but does prevent them being exploited for EoP, I’d still call that a win, but I would expect a new-new driver to show up soon…
(Ooooh, I wish I had one of those 8-core 4K XPS-15 laptops on which to try out the updates for myself, except that [a] I don’t and [b] if I did it would be running Linux [96% likely] or FreeBSD [4% likely].)
Anonymous
Are there any BIOS patches with this or just drivers?
Paul Ducklin
I must admit that I am not 100% sure from Dell’s advisory where actual firmware updates fit in. From the Dell report, I got the impression that updating the firmware update software itself is a *necessary* condition for fixing this issue fully, but may not be a *sufficient* one.
At one point it says you need to “get and run the new firmware updater”, which seems to suggest that you can run the updater, even if it has nothing to do, and thereby update the *driver* without also needing to do an actual firmware update at the same time. At another point, it implies that the new driver will only be deployed when you run the updater and actually apply a firmware update.
In other words, if there is no firmware update for your Dell computer at the moment (or there is one but you don’t yet wish to install it), does that mean you can’t get this vulnerability fixed untli there is also new firmware you can use to force the process? (Perhaps you can redundantly reflash with the current firmware, thus “updating without actually updating”, if you know what I mean, to ensure that this bug is fixed?)
Anyone with any Dell kit who has tried this and can comment?