Lenovo Patches UEFI Code Execution Vulnerability Affecting More Than 70 Laptop Models (securityweek.com) 20
Lenovo has released a security advisory to inform customers that more than 70 of its laptops are affected by a UEFI/BIOS vulnerability that can lead to arbitrary code execution. SecurityWeek reports: Researchers at cybersecurity firm ESET discovered a total of three buffer overflow vulnerabilities that can allow an attacker with local privileges to affected Lenovo devices to execute arbitrary code. However, Lenovo says only one of the vulnerabilities (CVE-2022-1892) impacts all devices, while the other two impact only a handful of laptops. "The vulnerabilities can be exploited to achieve arbitrary code execution in the early phases of the platform boot, possibly allowing the attackers to hijack the OS execution flow and disable some important security features," ESET explained. "These vulnerabilities were caused by insufficient validation of DataSize parameter passed to the UEFI Runtime Services function GetVariable. An attacker could create a specially crafted NVRAM variable, causing buffer overflow of the Data buffer in the second GetVariable call," it added.
Lenovo has also informed customers about Retbleed, a new speculative execution attack impacting devices with Intel and AMD processors. The company has also issued an advisory for a couple of vulnerabilities affecting many products that use the XClarity Controller server management engine. These flaws can allow authenticated users to cause a DoS condition or make unauthorized connections to internal services.
Lenovo has also informed customers about Retbleed, a new speculative execution attack impacting devices with Intel and AMD processors. The company has also issued an advisory for a couple of vulnerabilities affecting many products that use the XClarity Controller server management engine. These flaws can allow authenticated users to cause a DoS condition or make unauthorized connections to internal services.
UEFI, what more to say (Score:3)
UEFI, secure boot, what more to say on that :) But the China Firmware is different ? I wonder what to read in that.
Lenovo Products (sold in China): https://newsupport.lenovo.com.... [lenovo.com.cn]
Re: (Score:1)
It would be better, they said.
It would be more secure, they said.
It would be easier to use, they said.
It wasn't any better for open source users.
It wasn't any more secure for anyone except large corporations.
It wasn't any easier to use, certainly not for normal users.
If they can do whatever and nobody is going to hold them to account, they're not going to better their ways.
Re: (Score:2)
But the China Firmware is different ? I wonder what to read in that.
The difference is, they're not taking the back doors out of the Chinese models.
I think it has some value (Score:4)
Secure Boot's obviously problematic. I think the best solution is to, by default, prompt the user when loading an untrusted payload to either block, temporarily trust, or permanently trust, with mandatory options available to the user in the UEFI settings to either just disable the system entirely or to enforce it with no prompt. But I think that topic's been pretty well-discussed at this point.
I also don't like that a lot of implementations have networking capability out of the box, that seems like a potential security risk, but I don't know what a good solution would be.
Re: (Score:2)
Standard access to UEFI variables is nice, but unfortunately limited. So you can mess with boot sequence with a nice and surprisingly robust mechanisms, but all those arbitrary UEFI settings are still the realm of needing some utility from a proprietary vendor. I wish implementations went all in on the variables to allow standard access to settings across vendors.
On the GUI, EFI didn't especially enable that, though it may be coincident with it. UEFI still has the same basic setup menu in the common code.
Re: (Score:2)
Another useful feature of EUFI is that ROMs on expansion cards can use a machine agnostic VM, rather than being say x86 machine code. It used to be that a GPU built for an x86 PC wouldn't work on a PPC Mac, because the ROM code was x86 only. You had to flash a special PPC ROM, if you could find one and a suitable PC to do the firmware update.
Secure Boot is very useful for a lot of people. Your idea of prompting to trust unrecognized firmware might not be such a good idea, given that people tend to agree to
Re: (Score:2)
For one, China doesn't trust the TPMs that the world has standardized, so for China you are required to ship a different security chip, while the rest of the world you need to ship security chips from different manufacturers, and *not* the ones China requires, because the rest of the world doesn't support China's.
For another, for business reasons Lenovo carries just a different lineup for China market in general. I have had exposure to a fair representative sample of both the 'rest of world' product line a
Re: (Score:2)
I don't know if it's still the case but often Japan and China got different firmware to the rest of the world simply because supporting their languages took up so much memory. A lot of Japanese machines have only two options, Japanese or English. The European models have a dozen different languages.
HAHA,One of the funniest title ever in two words ! (Score:2)
HAHAHA, "Lenovo Patches". That's the best joke of the day, HAHAHAHAHA
Yeah, no need to read the rest of the title, let alone the article, the two first words of the tile are enough.
"Lenovo Patches". HAHAHHA, Made my day.
Only helpful if pushed by Windows Update (Score:2)
Unless this is being rolled out via Windows Update, it's highly unlikely that many of the people that own these machines are actually going to patch them.
Re: (Score:2)
ESET is one of the better anti-virus vendors, nowhere near so obtrusive and software breaking as MacAfee has often been.
UEFI, unfortunately, was not designed as a security toolkit. It was designed as DRM, and it's pretty much failed due to the amount of virtualization in modern server and office computing.
Re: (Score:2)
At this point it's probably only inertia from when they used to be IBM (like 2 decades ago) and corporate decision makers somehow still think that matters.
Remember, nobody ever got fired for buying IBM.
No Thinkpads affected (Score:3)
Again showing that anything that does not say ThinkPad on it is crap.
I know IBM had a deal with Lenovo that dictated a minimum quality standard for ThinkPads way back when, but it appears that if you're going to buy Lenovo, there's only one product line to consider.
Lenovo may have tried to "mix it up" and confuse matters with things like "ThinkBook" or "IdeaPad" but unless it actually says "ThinkPad" don't accept the imitations.
Re: (Score:2)
Again showing that anything that does not say ThinkPad on it is crap.
And that goes beyond just Lenovo. If you want a good laptop, buy a ThinkPad. If you want a good & cheap laptop, buy a used ThinkPad.
It is a bit simplistic as there are some ThinkPads with plastic bodies, or TN screens which I'd also probably avoid, but for example my current Ryzen-powered X13 is overall a nicer machine than my MacBook Pro, and I recently bought a T460s for my mom for under $200 (149 GBP to be exact), which is amazing for its price.
Can't see info on Lenovo's page. (Score:2)
The Lenovo page only shows the header and footer, so I allowed lenovo.com to run scripts - eventho that shouldn't be necessary to view an information page on a patch for their security flaw.
Still blank.
So I allowed cross-site scripting from adobedtm.com. Still blank.
So I allowed cross-site scripting from go-mpulse.net. Still blank. The fuck?
So I allowed cross-site scripting from confirmit.net. CAPCHA just to view a page info on their security bug? Still blank.
There's 1 more cross-site script, a metric page.
Arbitrary code execution (Score:2)
The phrase "arbitrary code execution" has always struck me as odd. The word "arbitrary" implies seemingly random or a state of randomness. Code that successfully executes on a CPU is not really "arbitrary" unless solar flares are flipping bits and writing functional code now. Random, chaotic systems rarely, if ever, produce functional output.