Hackers Can Infect Over 100 Lenovo Models With Unremovable Malware (arstechnica.com) 43
Lenovo has released security updates for more than 100 laptop models to fix critical vulnerabilities that make it possible for advanced hackers to surreptitiously install malicious firmware that can be next to impossible to remove or, in some cases, to detect. Ars Technica reports: Three vulnerabilities affecting more than 1 million laptops can give hackers the ability to modify a computer's UEFI. Short for Unified Extensible Firmware Interface, the UEFI is the software that bridges a computer's device firmware with its operating system. As the first piece of software to run when virtually any modern machine is turned on, it's the initial link in the security chain. Because the UEFI resides in a flash chip on the motherboard, infections are difficult to detect and even harder to remove.
Two of the vulnerabilities -- tracked as CVE-2021-3971 and CVE-2021-3972 -- reside in UEFI firmware drivers intended for use only during the manufacturing process of Lenovo consumer notebooks. Lenovo engineers inadvertently included the drivers in the production BIOS images without being properly deactivated. Hackers can exploit these buggy drivers to disable protections, including UEFI secure boot, BIOS control register bits, and protected range register, which are baked into the serial peripheral interface (SPI) and designed to prevent unauthorized changes to the firmware it runs. After discovering and analyzing the vulnerabilities, researchers from security firm ESET found a third vulnerability, CVE-2021-3970. It allows hackers to run malicious firmware when a machine is put into system management mode, a high-privilege operating mode typically used by hardware manufacturers for low-level system management. "All three of the Lenovo vulnerabilities discovered by ESET require local access, meaning that the attacker must already have control over the vulnerable machine with unfettered privileges," notes Ars Technica's Dan Goodin. "The bar for that kind of access is high and would likely require exploiting one or more critical other vulnerabilities elsewhere that would already put a user at considerable risk."
Still, it's worth looking to see if you have an affected model and, if so, patch your computer as soon as possible.
Two of the vulnerabilities -- tracked as CVE-2021-3971 and CVE-2021-3972 -- reside in UEFI firmware drivers intended for use only during the manufacturing process of Lenovo consumer notebooks. Lenovo engineers inadvertently included the drivers in the production BIOS images without being properly deactivated. Hackers can exploit these buggy drivers to disable protections, including UEFI secure boot, BIOS control register bits, and protected range register, which are baked into the serial peripheral interface (SPI) and designed to prevent unauthorized changes to the firmware it runs. After discovering and analyzing the vulnerabilities, researchers from security firm ESET found a third vulnerability, CVE-2021-3970. It allows hackers to run malicious firmware when a machine is put into system management mode, a high-privilege operating mode typically used by hardware manufacturers for low-level system management. "All three of the Lenovo vulnerabilities discovered by ESET require local access, meaning that the attacker must already have control over the vulnerable machine with unfettered privileges," notes Ars Technica's Dan Goodin. "The bar for that kind of access is high and would likely require exploiting one or more critical other vulnerabilities elsewhere that would already put a user at considerable risk."
Still, it's worth looking to see if you have an affected model and, if so, patch your computer as soon as possible.
No real news, Citizen. (Score:1)
So if I'm reading this right, an attacker that breaks in to my house can install anything they want on my computer. That just sounds like the computer working properly. If you think about it, this is some 1984 level shit. We're getting a security alert because a system that's designed to make it difficult for you to use your computer can be bypassed.
Re: (Score:3)
Re: (Score:3, Interesting)
This is the crux right here.
UEFI was mandatory by "suggestion" due to microsoft screaming "your machine will be more secure"
Yet, nothing has changed.
They would also have known that, so the real question is, why push UEFI so hard? Why is it all crypto locked and signed if its so easy to bypass.
Re: (Score:2)
UEFI was mandatory by "suggestion" due to microsoft screaming "your machine will be more secure"
Well, for a start, they don't see it as "your machine". All machines are THEIR machines.
The syndrome described sounds a lot like that stock scenario in thriller/horror stories. The winsome designated victim rushes into her house, locks all the doors, and piles up the furniture to prevent the monster from breaking in.
Then she discovers that the monster has been inside all along.
Re: (Score:2)
They can bypass it, the state can bypass it, Microsoft can bypass it. You cannot bypass it.
And you ask *why* that is?
Please be a little more creative.
A question to get you on the right track: what would happen to you or me, if we embezzled 1 million from a bank, employer, customer and what happens to representatives of the state and the banks if they embezzle 100 million?
Lenovo==China (Score:2, Insightful)
Re: Lenovo==China (Score:2, Flamebait)
no UEFI (Score:1)
Well my model is not on the list, but I am on Linux (Slackware) and have been resisting the move to UEFI and Secure Boot. I am sure more of these will show up with other brands. So much for "being more secure (tm)" with these new boot systems.
Nothing like sticking with tried and true tech to avoid these issues. Plus using Open Systems where I am not locked into a walled garden. At least I have some control over my hardware.
Re: (Score:2)
As much as I love Slackware, it's what I first learnt my trade on, I wouldn't really espouse it from a security perspective. Dealing with dependency hell & compiling everything by hand isn't really conducive to keeping everything up-to-date whilst also getting your day-to-day work done.
apt upgrade/yum update & let me get back to work!
Re: (Score:2)
A bit off-topic, but :) Slackware comes with everything I need, and probably 95% of most people. No need at all to use apt or yast or dnf or whatever after a full install. About the only thing not included is is Oracle Java due to its license. And that is not a compile.
See for what is included: https://slackware.osuosl.org/s... [osuosl.org]
Re: (Score:1)
But doesn't that mean that your hardware is pretty outdated? Not that this is necessarily a bad thing, but it somehow limits the options when stuff breaks.
Re: (Score:2)
Um. Uh. (Score:2)
What? Local access you say? Unremovable you say? Patching it fixes you say? But you just said it was unremovable. So the patch doesn't work? If it gets hacked is it unpatchable? You didn't say.
Pretty sure if I have local access there is a whole world of nasty things I can do to those Lenovo's, or any other computer.
Re:Um. Uh. (Score:5, Informative)
My thousand-plus dollar SuperMicro server motherboards might be recoverable from a firmware corruption attack by replacing the removable ROM. But if it's a laptop, you can bet that sucker is (a) soldered on and (b) the smallest damn BGA they could find. Good luck replacing it. Is it even meaningfully possible to remove a BGA from a board and attach a new one (meaningful meaning, without costing more technician time than a whole new board)?
While not applicable to these specific local access already required attacks, virtually all BIOS corruption attacks can be 100% cockblocked if manufacturers would just put a switch next to the BIOS rom that physically disables the write-enable line. Some enterprise hardware does, in fact, appear to come with this - jumpers that are required to be in position A to enable firmware update.
Just do a factory reset and reinstall the O/S (Score:2)
... oops.
It is amazing how brittle these over complex designs are. You have no control at all.
Re: (Score:3)
Anything with JTAG support aught to make it possible for any tech shop to fix the firmware. Anything without JTAG would make life fun. However, and I might be the only weirdo arguing this but oh well, this might be an argument for requiring computers to be fitted with standard, non-proprietary, interfaces that would - in principle - allow anyone to maintain their own hardware and to abolish total vendor lockdowns. Sure, most wouldn't. But if you're going to make it possible for any tech shop to fix this kin
Re: (Score:2)
Guess what you use to reflash your BIOS? If the bastards have already implanted themselves in the hardware initializer firmware aka the UEFI, it will be virtually impossible to expel them without using tools practically nobody has.
One of the USB ports on the back panel near the dedicated button on the board for "BIOS flashback"? I'm pretty sure it's using something other than the CPU and the BIOS, seeing as there was no CPU installed on the board when I used it, and it also ought to work when the BIOS is totally hosed...
Re:Um. Uh. (Score:5, Insightful)
If the patch prevents the malware from being installed, but the malware itself is unremovable (which seems improbable), then both parts can be true. I'm hoping this is the intended interpretation as nothing else seems to make sense. If it's hacked, my guess would be that either it would be unpatchable or that the patch would do nothing (it wouldn't stop existing malware from running, it would merely stop the malware from installing updates).
Ok, it's not a totally useless patch, if I'm right on this, but it's largely useless.
As I understand it, the whole philosophy of the combination of Secure Boot and TPM is to prevent precisely this sort of scenario. There have always been questions about whether these approaches are useful. The results seem to show they are not. Further, Secure Boot and TPM are relatively simple, so it should be straightforward to show there are no defects in the logic. If this is not happening, then the manufacturers are stating that they themselves are lazy and inept, relying more on ticking boxes than producing sound logic.
This second part is, in my mind, more worrying. Once you include things like Boeing's joke of a flight leveller, Microsoft's Windows 11 defects, and the (so far) total lack of any significant reform in the industry to ensure that standards are raised in the past few decades, then we see that the software and hardware industries are in a dangerous state. The freedom from lemon laws has succeeded in producing more and more lemons.
Sure, you can't prove software reliable for all conditions, but it should be straightforward to define "fitness for purpose" in terms of acceptable defect density per market, and the equivalent of a warranty (replace defective components) would be bugfixes, which the industry already issues. To deal with Open Source, the responsibility would be last-organization-touching, so you're not responsible for a customer editing your code. Open Source would also have lighter restrictions, just as we don't require lemonade stands and bake sales to be licensed and their products tested for consumer safety, but those same things still aren't free to spike drinks or food with toxins. We can, therefore, have lemon laws in software without harming the industry or Open Source.
Would this particular bug have been caught by imposing such restrictions? As a direct consequence - no. One bug in however many lines of code isn't a significant increase in defect density. However, it might have led to companies investing more in testing (which quite likely would have caught a lot of serious defects) and would have deterred overly complex, difficult-to-fix solutions because that would have left companies exposed in the event of there being defective components.
If the choice ends up being between standards enforcement and a steady eroding of freedom for users, the former would improve freedom and would lead to fewer scares like this.
There's going to be constraints, but we should be opposed to having them imposed and we should also seek for them to be effective, minimal and (ideally) looser in places where we really want improved freedom.
Unresolved problems (Score:3)
Re: (Score:1)
Yeah, I'm sure my mom would be able to do this.
Warning! Dell has determined you have an unsafe version of BIOS installed on your machine. Download the newest version of the BIOS for your machine, disassemble your laptop so you can find the jumper under the battery compartment, move the jumper into the "Flash" position, turn you machine back on and run the update utility, then disassemble your laptop again and move the jumper back to the "Safe" position. Caution. Continuously running your laptop with the
Re: (Score:2)
They wouldn't, for the most part, but if you enable shops to be able to make the same fixes in a way that doesn't require a fresh set of hardware per vendor, special training per vendor or a special, expensive, license per vendor, then it has to be theoretically possible for anyone to be able to maintain their own system. There should be no obligation for them to do so, just as there was no obligation in the 1980s that people maintained their own car BUT THEY COULD.
No Thinkpads on the list (Score:3)
Re: (Score:2)
Re: (Score:2)
The bar for that kind of access is high? (Score:1)
So, you just need to get the user to click on Yes/Allow a few times so they can install/view their game cheat, movie codec, payment invoice, etc?
And that's why it used to be... (Score:3)
And that's why, in the good old days, the motherboard had a jumper to enable your BIOS to be flashed.
Over time this was seen as cost-ineffective and user-unfriendly and thus removed by almost any manufacturer. Who would want to open up their computer to upgrade the firmware?
And that's where we are today. Issue at hand is not new, easy avoidable but for some reason existent.
Re: (Score:2)
Re: (Score:2)
yes. sometimes there are not more elegant solutions, did you forget that Desktop Support exists?
Re: (Score:2)
Back in the old days, we had 4 solutions:
1. the end-user could do it themselves if they felt they were technically-competent to do it. We would send them written instructions and be available to talk them thru the process via telephone.
2. send the machine in to have a tech do the work and ship it back to them.
3. wait until the next time they came in to an office for a meeting/training/etc and have a tech do the work while they were there.
4. not apply the patch.
This is why now remote management tools (IME,
Re: (Score:2)
You're making a huge assumption. The jumper exists, and guess what? After the first update, it will be in the "enabled" position permane
Re: (Score:1)
You have a dip switch behind a little flap, you open the flap, and flip the switch to 'unsafe', and upgrade the BIOS/UEFI. You forget to reset the switch, but there's a tiny robot finger that pops up periodically and sets the switch to 'safe'. And - here's the clever part - the robot finger is positioned so it's only mechanically possible for it to flip the switch from 'unsafe' to 'safe', so it doesn't matter if an evil hacker gains control of the finger!
Re: (Score:2)
This is a cool machine to own. (Score:2)
Re: (Score:2)
Re: (Score:1)
Indeed. The Deja vu is real.
RE (Score:1)