'Millions' of Dell PCs will grant malware, rogue users admin-level access if asked nicely Dell desktops, laptops, and tablets built since 2009 and running Windows can be exploited to grant rogue users and malware system-administrator-level access to the computers. We're told this amounts of hundreds of millions of machines that can be completely hijacked. This is made possible by five security vulnerabilities in …
I'm all for MS bashing but this pre-dates W10 and is entirely on Dell. Doesn't look like they have any interest in updating other operating system drivers according to the article, either that or El'Reg hasn't dug into it any deeper.
Even in the 90s we'd always wipe vendor PCs before deploying, this might have snuck on though if it was part of a driver package and not identified as bloat (which some drivers were).
"operate beyond the control of the operating system such as hex editors, disk wipe software etc."
Hex editors can edit anything they want. They just can't write it back to disk without permission. i.e. control of the operating system. Same with disk wipe*. The typical user doesn't have permission to write raw disk sectors (let alone read all of them).
*Disk wipe utilities typically work from bootable media. Giving themselves their own little OS and permission to write to any drive that they mount.
This driver is part of applications like those able to update the PC system firmware - BIOS, etc.
Quite difficult to perform that without elevated privileges - and by design kernel code runs with highest privileges (once x86 CPU could access I/O ports without being at ring 0, but system designers never liked the x86 four rings and IOPL, and ignored them....)
But the problem are not the privilege themselves, it's the lack of checks about the caller having the required privileges.
Moreover Dell could have installed the driver when needed to perform such operations, and remove it when finished.
"Essentially, Dell's driver accepts system calls from any user or program on a machine; there are no security checks nor an access control list to see if the caller is sufficiently authorized or privileged "
No security checks, no ACL.
You tell me that there isn't a single rogue engineer that thought that wasn't a good idea.
"How did nobody on a firmware development team remedy this in eleven years?"
Maybe contractors came in, said it was really bad and must be dealt with, management said "Shhhh!" and the contractor found their contract was not renewed at the end of the term!
>If the user's uninstalled the Dell Update app (or performed a clean install of Win 10) they'll not get this firmware update?
It's not a firmware update, it is a (Windows) driver update to a driver distributed with the Dell Update app, albeit the driver that is used to update firmware from Windows. So if you've uninstalled the Dell Update app and deleted all files, you aren't vulnerable and don't need the update...
Interestingly, given the main purpose of Dell Command Update is to automatically update firmware remediation Step 1 effectively castrates DCU...
That is why I got my new computer, Not a Dell, but before I even started it I inserted a USB Thumb Drive in a USB port and started the computer to boot from the USB Thumb drive. On that USB Thumb Drive was the ISO image for Linux Mint 20.1 Ulyess Cinnamon. Linux minx booted up and during the install stage where it said Install beside Windows, I set it to erase the Hard Drive and Install Linux Mint, and since then there has never been a version of Windows on this Computer. I have installed several other Operating Systems, all Linux Based, they are Ubuntu Studio 20.04 LTS and Storm, that last one is off shoot of Arch. I do not miss Windows in any way, it was too clunky, slow and cost to much. I can achieve everything I need on Linux Mint
>So you've missed the articles about Linux having driver vulnerabilities for 15 years then?So you've missed the articles about Linux having driver vulnerabilities for 15 years then?
I actually went looking...
Dell do in their advisory say Dell System Update Linux isn't affected. So at least Dell do take Linux sufficiently seriously to actually check to see if (Windows application) vulnerabilities have been ported.
"I can achieve everything I need on Linux Mint"
Lucky you!
Some of us live in the real business world where Linux is still considered server room only, or "quaint" or "geeky" on the desktop. The SecInfo guy will string you up for not conforming to business standard operating systems, usually Windows.
I'd love to live in a Linux paradise you speak of, unfortuately making a living in the real world of day-to-day working IT in a real company gets in the way and I have to knuckle down and use Windows.
That used to be the case, but it is changing for those of us migrating to cloud services. The additional cost of using Windows in the cloud makes Linux look more appealing to the budget holders, and with Microsoft providing better Azure tools on the desktop for linux the need to use Windows desktop is diminishing.
The Azure training I was on last year (yeah - i got to go on a 2020 conference!) recommended the linux "az" tool over the powershell equivalent if we could use it.
These malware scares only help the argument, but the security team are having to learn new skills when it comes to dealing with linux boxes.
... since then there has never been a version of Windows on this Computer ...
Indeed ...
But you do have a version of the MS Registry running inside Linux Mint.
It is called systemd and is nothing but a developer endorsed registry-class virus set up inside many Linux distributions.
Which is just as bad worse.
Because Linux, by design, has always been much more secure than any MS OS.
And basically, you don't expect any nasty stuff to "just happen".
Like with Windows.
From a post here at ElReg, May 2017:
"Systemd also has its dirty fingers into other parts of the system. As a replacement for sysvinit is is supposed to be an init system, but because its scope goes far beyond the initialization phase (and it doesn't let you take the good without the bad) it has become a dependency for many userspace programs that should never have any reason to interact with the init system at all, making it harder to use those programs on a non-systemd system."
So, you are not as safe as you think you are.
Check this recent article here at ElReg.
O.
Like the Intel vPro remote management bug the other year that would accept a null string instead of a password, this is Dell saying “we just don’t care about security.” This never could have passed any meaningful code review or internal red teaming.
I doubt it's just Dell, I was firmware updating a new Lenovo the other week at User level privilege, neither Windows10 Pro or the Lenovo update utility asked anything more than a "OK to proceed?". I'm still gobsmacked you can 'blow' the firmware from within the OS.
I'm still gobsmacked you can 'blow' the firmware from within the OS.
Sure, boot Linux
cd /sys/firmware/efi
then feel free to play with all those writable files down there. There's hundreds to chose from. Some of which can be modified in ways which will leave the box unbootable.
rm -rf /
won't just spoil your software's day these days.
I can't believe that Linux is the only environment which gives easy access to this stuff, I'm sure I remember reading about how to access this stuff on OpenVMS too.
Well I don't know about your system but when I remove the file from under /sys/firmware/efi/efivars it deletes the variables from the NVRAM.
If you want to play with this make yourself a VM and add a new boot entry with efibootmgr and then go and delete it from /sys.
I wouldn't personally recommend removing the variables that hold the secure boot keys from a laptop if you want to run Windows on it again.
This has been covered on El'Reg before, try https://www.theregister.com/2016/02/02/delete_efivars_linux/
That 2016 link was pointing out two problems that combined to make a third very, very bad problem.
Sadly, neither of the two problems has been fixed.
Happily, cognizant admins have been aware of both for about a decade and thus don't purchase computers with brain-dead uefi implementations, nor do they install brain-dead software that exacerbates the problem by making hardware variables writable by default (for example, the systemd-cancer).
Jake, my posting wasn't intended to be a criticism of Linux, as I said other OS have also made it possible to interact with the settings in the firmware. Either you have FW which can be configured from within the OS so that things like the installer can ensure that the newly installed OS is going to be the default boot device or you have the dumb situation we used to have with legacy BIOS where there were no defined APIs so you could install an OS, reboot and find the system attempt to boot from somewhere altogether different and typically fail.
It isn't userland stuff, even the monstrosity of systemd, which determines whether "hardware variables" are writable. At least you need to hope not. It's the firmware design and then whether the OS kernel provides a way to communicate with the underlying firmware.
Do you want the OS to be able to configure FW settings? If it can't then we're forced to make changes down at the FW level, tedious when you're installing rack after rack of boxes, or you're forced to rely on vendor supplied tools, the weakness of which this article is discussing. Things like the boot device table are obvious, we want to be able to configure them, but if you can configure things you can mess up. Secure boot is a useful feature but like any lock there is the possibility of locking yourself out. You can rely on the shim SW signed by M$ or you need to be able to load in new keys, for example Alma Linux (OK it's systemd based so you might not want to) announced the other day their beta 8.4 release with secure boot, this means loading their key so there needs to be a mechanism to do this. Either you need to be able to do this from the OS or an admin needs to go to the EFI shell and load the key from there.
I was firmware updating a new Lenovo the other week at User level privilege
Hopefully the firmware file was signed and the driver first verified that the signature checked out okay.
Either way, it would not have hurt them to require elevation so that we won't have to question their implementation.
There was probably customer demand to do it the way they did. After all, an elevated process can spin up drivers as needed. So the driver is pre-installed to allow user-mode apps to initiate the flash. But it certainly does not feel like this approach will be found on any 'security best practices' lists.
> I'm still gobsmacked you can 'blow' the firmware from within the OS.
Not really...
In updating a stack of HP/Dell/Lenovo systems this past year, I've tripped up and had to manually run updates ie. perform the update outside of Dell Command Update for example, only to have both the AV and Windows produce security alerts - in the case of the AV, it also automatically deleted the BIOS firmware file.
So provided everything is correctly signed and performed within the secure OS update box, the user is merely pushing the button and effectively telling the OS "I'm not doing anything important at the moment, so go ahead and update and reboot if necessary, but be quick about it".
You get what you pay for
Dell, and all the others, all they’re doing is building PC’s
Any technician worth their salt can do this, but the cost would be higher. But mark my words, those systems will be 100x better for lots of reasons, than the crap Dell, Lenovo, or whatever, push out.
First of all, the motherboards will be higher quality
In addition to being more expensive, you don't really know the motherboards will be better. I can go get a motherboard from a variety of sources from companies that nobody's heard of because they started up last year. You have to trust that your technicians aren't just doing that. That's not the main issue though. Self-building works fine for desktops, but a lot of buyers and users don't want desktops. Laptops have a lot of convenience, and now that their processors aren't hampered compared to the needed office workloads, they're quite suitable. I have rarely seen a successful self-built laptop, let alone one that people would really want to carry.
What a coincidence. Do you believe in coincidences?
Dell unveils its Apex suite of Cloud Services and Custom Solutions etc., which quoting Michael Dell .... "This is a business model transformation. The opportunities are significant with multicloud and edge. We’re investing heavily in those. It’s an expansion as we see it of the opportunities because moving from products to services and managed services – which were already substantial businesses for us – leads to the next step, which is everything-as-a-service. It’s a whole new chapter for our company.” ....... https://www.nextplatform.com/2021/05/06/getting-the-cloud-but-keeping-control/ ....... and then a tale emerges about something from 2009 we're told can completely hijack hundreds of millions of Dell machines, ..."five security vulnerabilities in Dell's dbutil_2_3.sys driver, which it bundles with its PCs. These are grouped under the label CVE 2021-21551, and they can be abused to crash systems, steal information, and escalate privileges to take total control. These programming blunders can only be exploited by applications already running on a machine, or a logged-in user ...... it is inevitable that attackers will seek out those that do not take the appropriate action," warned Kasif Dekel, a senior security researcher at SentinelOne who helped find the holes." .... even though, over the past 12 years,with hundreds of million of enterprises and users currently vulnerable ... we haven’t seen any indicators that these vulnerabilities have been exploited in the wild up till now
One would almost think Dell had the competition really worried about their transforming of business operations and their leading ways of doing it with software jumping over and quantum leaping the opposition.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
