Dell patches 12-year-old driver vulnerability impacting millions of PCs | Hacker News Reader

Dell patches 12-year-old driver vulnerability impacting millions of PCs

labs.sentinelone.com

We've changed the URL from https://therecord.media/dell-patches-12-year-old-driver-vuln..., which points to this.

From the guidelines: "Please submit the original source. If a post reports on something found on another site, submit the latter."

https://news.ycombinator.com/newsguidelines.html

Okay thanks!

It's not clear from the article, but my reading is that while the bug was introduced 12 years ago, it was discovered and fixed only now.

Which is different from knowing about it but ignoring it for 12 years.

I'd infer from the CVE naming (CVE-2021-21551) that it was discovered this year.

It was publicly documented by the people generating those codes this year.

It could have been discovered quite some time before that, and going by some tweets already posted (caveat: I've not verified anything here) some parts of it at least we're noticed, and Dell notified about them, in 2019.

they actually ignored it only 2 years: https://twitter.com/aionescu/status/1389713670138073089

This is why having preinstalled bloat ware on your computer is bad. I’ve seen a lot of old outdated apps on consumer grade PC’s that reinstall themselves after a factory restore that could be used by malware.

HP seems to be even worse than Dell in doing this and it’s recommended that you format the hard drive and install a clean OS

if a vendor makes use of the Windows Platform Binary Table then it can use the UEFI to persist even through a format. This is how Lenovo did the superfish thing (also used by various asset-theft-tracking services) and afaik it was never removed from Windows or the UEFI, Lenovo was just shamed into not using it.

Excellent point! I had forgotten about the problem with this.

https://cve.report/CVE-2021-21551

Seems to be an optional package. It's not on any of my Dell hardware. Not the sort of thing a security-conscious person would willingly install anyway.

From the security company's report at https://labs.sentinelone.com/cve-2021-21551-hundreds-of-mill... :

> 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.

Dell's security advisory page (https://www.dell.com/support/kbdoc/en-us/000186019/dsa-2021-...) suggests that it would be installed if you installed any of a number of their update programs:

> This driver file may have been installed on your Dell Windows operating system when you used firmware update utility packages, Dell Command Update, Dell Update, Alienware Update, Dell System Inventory Agent, or Dell Platform Tags, including when using any Dell notification solution to update drivers, BIOS, or firmware for your system.

The "Process Hacker" tool that this article refers to seems quite useful. It can be found here: https://processhacker.sourceforge.io (free GPL software)

Yes, +1 for Process Hacker, it's basically an open source alternative to Sysinternals Process Explorer[0]. The service alerts noted in this article in particular led me to getting spooked and discovering that Windows Defender likes creating fun malware-like driver service names like MpKslasdfas3.sys. I'm at the point where it's always open to increase system awareness, and for quick filehandle views when I forget what application is stopping me from ejecting a USB.

[0] https://docs.microsoft.com/en-us/sysinternals/downloads/proc...

I find it weird that Windows doesn't already tell you what app is holding a file/directory/USB locked when you try to move/delete/eject something.

Is there some common use case that makes this hard?

Yeah I don't believe windows tells you in the pop-up at all. Spawning questions like https://superuser.com/questions/87364/can-windows-tell-me-wh...

For me sometimes it's something as simple as a "rogue" notepad I lost track of on another monitor.

I agree it doesn't tell you.

Your link has some great pointers, even the event log will straight up tell you.

So why doesn't the popup tell you?

It doesn't seem like a complicated issue, hence my query as I feel like I am missing something here.

Ok, we've changed the URL at the top to that one, from https://therecord.media/dell-patches-12-year-old-driver-vuln..., which points to it. Thanks!

When you manage a number of Dell computers, the Dell Update package is helpful. Dell Update will alert you when there are updates available. Not so different than Windows Update. Keeping up to date with drivers and firmware is a security-conscious thing to do.

I don't use any of the other Dell software/packages but I find Update helpful.

I have always used the DOS/FreeDOS method to update my Dell firmware. Seems silly to let an insecure OS such as Windows have write access to the BIOS. It would provide an easy path to the holy grail of malware persistence.

Every time I've updated the BIOS on my Dell laptop it's been done on the next boot, before Windows starts.

The update process that runs in the OS would need to use the driver at issue here to write the new firmware into flash at some staging location. After that is done, then you reboot, and the chips see there’s a staged update and applies it.

That's not how UEFI capsule updates (which AFAIK is what modern Dell computers use) work. The update is written to the EFI partition, the computer reboots into an EFI updater which loads the update to RAM and tells the BIOS where it is, the computer then reboots again and the BIOS itself loads the firmware update from the staging location in RAM and writes it to flash (which is still unlocked at that point in the boot sequence). At no point does anything other than the BIOS write to the flash.

That's matches what I've observed on my ~2017 Dell XPS. On Linux with fwupd (and Windows), it would write the updater to the EFI partition and then set it as the default boot entry for the next boot. I had to manually add Dell's certificate to the EFI "db" variable when I switched to using custom secure boot keys.

Even on Debian 11 also!

Neither FreeDOS nor Windows have direct write access to the BIOS. They use the UEFI capsule mechanism (i.e. let UEFI update itself on the next reboot).

i find it crazy that you think DOS is secure when compared to windows. or anything else, really.

There’s certainly no question that DOS can be exploited, on the other hand DOS has fewer moving parts. And the boot device is usually freshly imaged from the source.

No networking, no multitasking, nobody writing new malware for it.

For those using the traditional DOS-style approach, there has never been a reason or need for any Dell-supplied Windows apps which can compromise the firmware, even upon reboot. Allowing only the local manual console operator to do the deed, and only when NOT booted to Windows or Linux always gave an extra layer of security by comparison.

Now we know the Windows way was far less secure than we thought, although it did seem like an obvious security compromise when they first started trying to update BIOS from Vista in addition to the DOS way.

Dell has traditionally provided BIOS firmware updates primarily in DOS-executable .EXE form, with additional Windows apps or Dell Update Package approaches becoming available over the decades as the functional reliability was thought to be almost comparable when attempting to replace the ROM file from Windows.

The most reliable way to update your firmware has always been to turn off the PC, disconnect the HDD or SSD, then boot to DOS using a floppy, CD, or USB device which contains the flashing program and the ROM file. Run the BIOS flash program from the DOS command line like usual.

The equivalent on UEFI motherboards is to boot to the UEFI Shell itself, which if built-in may just come up by default if no drives are connected. Otherwise you will need to supply your own Shell64.efi on a storage medium in a recognized filesystem like FAT32 which UEFI is required to read from.

In shell64.efi you will be in a DOS-like command line then you run the vendor-supplied UEFI-executable .EFI program also on your storage media, which then applies the updated ROM file just like it would in DOS. But no operating system needed or wanted, not even DOS any more.

Dell example option 1.3.1:

https://qrl.dell.com/Files/en-us/Html/Workstations/DellPreci...

Other motherboards have had a built-in flash routine for some time now, where it recognizes a proper ROM file on a FAT32-formatted USB drive, and you can flash it with no OS necessary either.

Also, the FreeDOS approach is just the DOS that is used for distribution to avoid copyright issues. Most of the updates distributed with a FreeDOS platform were usually developed & tested using MS-DOS, and you may have better luck burning the FreeDOS version to floppy, CD, or USB, then copying the vendor executables & files to equivalent MS-DOS-booting media rather than the supplied FreeDOS-booting approach.

is code signing not a thing on EFI or something?

I believe a consistent number of users will have their systems compromised but not top-notch security skills or support to understand why, and thus Dell will not get any negative PR from it.

This is why we don't let 12-year-olds drive

dbutil_2_3.sys ... it only affects windows dell machines, right? https://xkcd.com/272/

> This bug is nothing out of the ordinary.

In summation

I read this CVE with some interest, to see if it provides a solution to a frustrating problem, involving a Latitude 5300 (2-in-1). The problem: once the device is fully charged and subsequently shutdown, it rapidly drains the battery to around 80% within a few hours ─ at which point it retains the remaining charge. The problem is less pronounced, when it is put into sleep mode.

I have been through numerous suggestions and permutations; 'hard' shutdown by holding the power button for varying durations, BIOS updates, OS updates (W10 latest build/version/updates/drivers), manufacturer specific driver updates, fresh rebuilds, tweaking power,wake,idle,throttle settings for CPU, network adapters (via BIOS and OS), date/time anomalies, turning off Modern/Connected-Standby, Registry hacks etc. Furthermore, I have contemplated using Wireshark and other tools to diagnose the problem, but that would require a significant chunk of my time troubleshooting a device, which I expect to work, out of the box. I resent the fact, that no explanation or a solution is forthcoming from Dell, which is a matter of concern.

The post below describes my conundrum, fairly accurately.

https://www.dell.com/community/Latitude/Latitude-7400-batter...

I’m not sure if this helps, but if the battery is charged to 100% and then stored for a long period of time, it will not last long at all. 2 years, tops.

As an engineering approximation that we use in the industry, each 5% undercharged may very well double the cycle life of your battery. 80% is usually the good point of compromise for most consumer electronics.

My XPS has options for smart battery charging/storage so you might try playing around with the optional battery optimisation apps to see if one of those charging modes is enabled. Chances are it might be “fake charging to 100” but intentionally limiting to 80 based on your usage pattern.

Thank you for engaging, and for your suggestions. I have owned the machine from new, for a little more than a year. It was manufactured approximately 4 months prior to the date, it came into my possession. The laptop was displaying the problem described, from the outset.

I am in full agreement with your assessment on ageing devices exhibiting the Bathtub Curve, and also your suggestion on undercharging. However, the battery on this device has less than 15 cycles in total. Furthermore, when in Sleep mode, it only loses 2-3% daily from its designed capacity -- which is an acceptable range.

Hence, the reason for my curiosity to determine the precipitous drop in charge, when the machine is in a complete shutdown state. You are correct, there are a lot of features in the latest BIOS for management i.e. CPU, power, network, battery etc. I have disabled most of them or opted for the best possible option, where appropriate.

The point about the battery is moot, as I am more concerned about an undocumented feature which might be causing the high drain. There are more reports of Dell laptops exhibiting this unsolvable behaviour, than any other manufacturers combined ─ which usually relate to Modern Standby and/or Intel Management Engine(IME).

Hi, I am not talking about your device ageing. I am talking about the protections put in place by Dell to prolong the life of your product. Dell are especially innovative in this space.

For example, in my opinion, you're seeing the effect of "Dell Smart Charging", which is a by-design feature of the Dell Power Manager [1].

Your profile may be set to 'Adaptive', and it may automatically use the 'Primarily AC' behavior. Here is an excerpt from that behavior: 'Extends battery life by lowering the charge threshold, so that the battery never charges to 100 percent capacity. Recommended for users who primarily operate the system while plugged into an external power source'.

My experience with Dell Power Manager is that this is done transparently to the user, for example the user may see '100%', but at the battery firmware level it knows that it is only charged to '80%'. I think that you're just noticing the smoke and mirrors and getting concerned when there's probably nothing at all to be concerned about. There is a numeric filter between your real and fake battery levels, and yes, at times you're going to see inconsistencies when rebooting your product. And there will especially be differences between sleep and cold-start. But if Dell had implemented it differently, on the flipside plenty of people would send their laptops back for 'not charging to full'.

My recommendation here might be to reset your BIOS settings to factory default and see if the settings in the Dell Power Manager can resolve what you are experiencing instead (i.e. from Windows DPM disable Advanced Charge and use the Standard setting instead of the Adaptive setting, fully charge and discharge your product, then leave attached to an adapter for 4+ hours).

[1]: https://dl.dell.com/topicspdf/power-manager_users-guide_en-u...

Source: electric vehicle battery engineer.

>Your profile may be set to 'Adaptive', and it may automatically use the 'Primarily AC' behavior.

Initially, it was set to Adaptive by default in the BIOS. During the process of fault-finding -- changed it to 'Standard' hoping that the firmware will relinquish control and give it back to the OS, allowing it to over-ride any settings. I have toggled settings for power management where you can choose the mode of charging, to prolong battery life i.e. constant power or restricted to certain levels, schedules etc., without any joy.

I have reset the BIOS a couple of times, but will try all your suggested solutions from scratch, including installing the Dell Power Manager ─ something I have not tried before ─ to see where it leads. Thanks for your continued patience. I will let you know what happens, regardless of the outcome.

Reply on news.ycombinator.com