Lenovo Scrambling To Get a Fix For BIOS Vulnerability (theregister.co.uk)

Richard Chirgwin, reporting for The Register: Lenovo, and possibly other PC vendors, are exposed to a UEFI bug that can be exploited to disable firmware write-protection. If the claims made by Dmytro Oleksiuk at Github are correct, an attacker can "disable flash write protection and infect platform firmware, disable Secure Boot, [and] bypass Virtual Secure Mode (Credential Guard, etc.) on Windows 10 Enterprise." The reason Oleksiuk believes other vendors are also vulnerable is that the buggy code is inherited from Intel. He writes that the SystemSmmRuntimeRt was copied from Intel reference code. Lenovo complains in its advisory that it tried to make contact with Oleksiuk before he published the vulnerability. The company says the vulnerable System Management Mode software came from an upstream BIOS vendor -- making it likely that other vendors getting BIOS software from the same outlet will also be vulnerable. There's also a hint that Lenovo agrees with a speculation by Oleksiuk, that the code may be an intentional backdoor: "Lenovo is engaging all of its IBVs as well as Intel to identify or rule out any additional instances of the vulnerability's presence in the BIOS provided to Lenovo by other IBVs, as well as the original purpose of the vulnerable code."

Comments

Software based firmware write protection is a joke

[Anonymous Coward]

Software based firmware write protection is a joke. It is just as stupid as a door lock on a door and then hiding the key under the flowerpot on the porch.
It is no real protection at all. It should be a hardware switch like in the old days, but no, that increases the costs per device by $0.02 and it makes using the system by dumb people more difficult. Lets not do it and make an extra buck.

And because everyone reasons like this, we are now stuck with huge hardware and software stacks, which inherently cannot be secured, and an entire industry that tries just that, securing crappy systems, and failing at it.

Executing code in a input buffer? yeah, suck it up

[freax]

You asked for it Lenovo and/or Intel. This turns an incoming buffer into a funciton pointer and executes arbitrary incoming code:

v3 = *(VOID **)(CommunicationBuffer + 0x20);
v4 = CommunicationBuffer;
*(v3 + 0x8)(*(VOID **)v3, &dword_AD002290, CommunicationBuffer + 0x18);

That's moron. You asked for it. Now suck it up. Apologize to the world for creating a obvious backdoor.

I'm quite sure it won't be the only one coming from Intel's headquarters. And yes, security-researchers will keep digging them up and expose them. Forever.

You know what flashing a BIOS secure?

[mhkohne]

I liked it better when I had to move a jumper before I could flash the BIOS in a machine. That was really quite secure against post-shipment BIOS modification.

Of course, I also can't think of the last time I flashed the BIOS in any of my systems, which makes me wonder why the hell we ever got away from ROMs in the first place...

Re:You know what flashing a BIOS secure?

[PsychoSlashDot]

I liked it better when I had to move a jumper before I could flash the BIOS in a machine. That was really quite secure against post-shipment BIOS modification.

A good thought but it doesn't work so well when you've got hundreds or thousands of remotely supported systems scattered over the city/country/continent/planet.

Of course, I also can't think of the last time I flashed the BIOS in any of my systems, which makes me wonder why the hell we ever got away from ROMs in the first place...

You know this article is about shitty code, right? Well, I can tell you that the BIOS being shipped these days is shitty in more ways than this. If you have enough machines out there, you will sooner or later encounter something strange that involves a bug in firmware. From a mouse/printer/USB-vibrator to the latest DVI/HDMI/DisplayPort monitor, sooner or later you'll plug something in and it won't work as advertised. Or something that used to work stops working because... reasons. Basically, if you accept that there are firmware updates for motherboards, you should accept that there are reasons for them existing, even if you haven't needed them.

And don't get me started on the shitty code in server firmwares.

Most commercial systems (Dell, Lenovo, HP) they're bugfixes. Most consumer systems (Asus, Gigabyte, etc) they're updating support for processor microcode or memory module compatibility or whatever.

Re:You know what flashing a BIOS secure?

[williamyf]

I liked it better when I had to move a jumper before I could flash the BIOS in a machine. That was really quite secure against post-shipment BIOS modification.

Of course, I also can't think of the last time I flashed the BIOS in any of my systems, which makes me wonder why the hell we ever got away from ROMs in the first place...

Dear guys:

You seem to not realize how servers and cloud influence general computing. Intel, RedHat and many other companies do make the bulk of their income and profits from servers, therefore, servers are first, second and third.

That's why you got UEFI in the first place, and that's why UEFI has provisions for:
- Remote connections.
- Ethernet boot.
- etc.

Jumper to change the FIRMWARE?
Yeah, like that's going to work when your server count is in the couple of thousands... (also, not for a desktop/laptop fleet, but that's a different story).

sytemd is another example. Does anyone really believes that "RedHat is shoving the desktop down our throats"?

- You need to boot faster your cloud servers for elasticty's sake.
- Also, you need to boot faster if your preferred remedy for failures is to freze the VM for latter analisys, and spin up another instance.
- You need to shotdown machines fast when the work peak is over, in order to release resources fast, and not to overcharge the customer (if on public cloud).
- If your servers/virtual machines are controlled by another machine and not by a human, what do you preffer, configure a centralized repository of values via an API (like on VMS and 'gulp' Windows' registry*)? Or having to parse a rag-tag fleee of config files, each with "a slightly different syntax"**?

I guess you can see the drift from here...

* I am not saying that the IMPLEMENTATION of the Windows Registry is right. What I am saying is that the IDEA of a Centralized Repository Of System Configuration Info Accessible Trough An API is good. Again, see VMS.

** Even though for us humans the syntax of most config files seems the same, for other machines one config file is ussaly completely different from the other...

Re:NSA Strikes Again!

[AJWM]

"Once is an accident. Twice is coincidence. Three times is enemy action."

      -- Ian Fleming

We're way past three.