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