Millions of Gigabyte PC motherboards backdoored? What's the actual score?

You may have seen some headlines about a supply-chain backdoor in millions of Gigabyte motherboards. Here's the lowdown. What's the problem? Gigabyte ships a wide range of motherboard models that come with an App Center utility, which is supposed to keep the system's firmware, drivers, and related software up to date. It …

[David 132]

You missed a question.

How about:

“Should I take the moron(s) who thought it would be a good idea to allow UEFI firmware to automatically and silently install root-privileged services to the Windows \system32 folder, off my Christmas card list?

Yes. At minimum.”

[diodesign]

Re: You missed a question.

More than happy to add this Infrequently Asked Question to our list of Frequently Anticipated Questions.

C.

[David 132]

Re: You missed a question.

Yay! I'm directly responsible for a Register article being tweaked! That's not happened in many, many years, ever since the olden days when Mike Magee was on staff :)

[Yet Another Anonymous coward]

Re: You missed a question.

" to the Windows \system32 folder" think a bit of root cause analysis here

[doublelayer]

Re: You missed a question.

I'm not sure how that folder indicates any particular risk, given that you can run a system service from any folder. They could as easily write it to a user folder, anybody's, and run it just the same. For the same reason, they could write it into any Linux installation if they were willing to, but presumably they didn't compile it for Linux.

I wonder whether this works on encrypted OS disks, where the firmware doesn't have the keys to mount and write to them until the user enters a code. It could always insert the software after decryption occurs, right before booting that disk, but if it's running at the start, that might stop it. Either way, I can't imagine why someone at the design stage didn't explain how stupid this plan was, or more likely, what happened to those who did.

[David 132]

Re: You missed a question.

My understanding of the mechanism - and I freely admit I skim-read about it last time something similar hit the news many months ago, so I'm prepared to be corrected (with the calm good manners that are the hallmark of Internet discussions) - is that the firmware doesn't itself write to the disk. Instead, it signals to the OS that it has an OEM-specific file that needs to be added to the system manifest, and Windows accepts the file and writes it to disk.

If true, then an encrypted disk won't make any difference; if the OS has access, the firmware can get the file onto it.

[cantanko]

Re: You missed a question.

Can confirm - running one of the listed boards and Bitlocker. Deleted file, confirmed it was gone, rebooted, still gone, rebooted again and it was back. Domain now intercepted via DNS and the service disabled, but still very unpleasant.

So according to recent shenanigans you can have Asus but no warranty or Gigabyte but firmware-enforced back doors. What do we think ASRock or MSI are going to do?

[Maventi]

Re: You missed a question.

I wonder if this utilises or is related to WPBT? I suspect that active participation by Windows is partly to blame here; I don't expect that UEFI would be able to forcibly write this file to a local filesystem. But I suppose few things surprise me any more with modern tech, especially from the big players in the industry.

[ChoHag]

Re: You missed a question.

> I don't expect that UEFI would be able to forcibly write this file to a local filesystem

UEFI runs before all the parts of your computer that can say "no" have been started. Its only job is to start them.

[Doctor Syntax]

Re: You missed a question.

Its only job is should be to start them.

FTFY

[CrazyOldCatMan]

Re: You missed a question.

Its only job is should be to start them

Much like the only job of an init system should be to make sure that system daemons are started correctly (and re-started if necessary).

And we all know how well that's going eh DedRat?

[doublelayer]

Re: You missed a question.

"I don't expect that UEFI would be able to forcibly write this file to a local filesystem."

From other posts, it appears it's not trying to. However, it certainly could if it wanted to. The firmware has hardware access to the disks and has filesystem drivers for some of them. At most, someone would need to include a new driver in it if it doesn't have the one it needs, because the firmware cannot be blocked from accessing whatever hardware it wants. There's a bit of a space limit on most firmware partitions, which limits the size of the bootstrapped attack vector, but not such a small limit that it's likely to protect you if anyone did write firmware that bad.

[FIA]

Re: You missed a question.

I wonder if this utilises or is related to WPBT?

It would appear it does.

For the uninitiated, WPBT is an ACPI table that can be setup by a motherboards BIOS to describe an in memory executable.

Windows will then save this to the hard disc on boot and execute it.

More details can be found here.

[Binraider]

Re: You missed a question.

See also, Asus, Armoury Crate.

First feature to disable on their board.

Unfortunately from a build quality perspective Gigabyte and Asus (were) usually the better options.

[Noram]

Re: You missed a question.

I would have suggested the use of a roll of cheap carped and a couple of bags of quicklime to be a suitable option for the offender, if not for the first offence, then for the second. Very few third offences.

[user555]

Re: You missed a question.

But M$ loves auto-run features.

[ske1fr]

Phew

Tiptoes away, whistling.

[Kevin McMurtrie]

Not using transport encryption is fine as since there's a digital signature required. You're checking who signed it right?.... right? So somebody else isn't? Right?!?

[Hugo Rune]

X570 Aorus Elite here.

App centre is just a Norton and Chrome drive-by installer. if you use its recommendations it will also downgrade your graphics driver.

Uninstall and use ebios as a separate stand alone program if necessary.

[Pascal Monett]

Unfortunate, to be sure

Now that I know that motherboard makers are inclined to this kind of shenanigans, I'll be on the lookout.

That said, I do not expect that my motherboard is supposed to adhere to the general insane update schedule of software.

It's a motherboard. It's supposed to work right from the box.

I'm glad that an update mechanism is in place, but, again, it's a motherboard. Everything depends on it and its stability.

Stability.

Now that's a word the software world needs to reacquire.

[NickJP]

I notice that on the Gigabyte website there is a firmware update for my motherboard (Z690 Aorus Pro) dated 31 May, and the description for it says "Addresses Download Assistant Vulnerabilities Reported by Eclypsium Research". Not that I've ever installed or run their App Center software...

[Graham Cobb]

How do we defend against this? - Linux edition

So, I gloated for 30 seconds that this didn't affect me because I use Linux. Then I started thinking about how to defend against this sort of thing... at least from entities trying to be "helpful" (not trying hard to be malicious).

It is certainly true that EFI code can do anything it likes to the disks, or to the RAM contents before dispatching the kernel. However, all my disks are encrypted (data disks and root disk). Except for /boot (which contains the kernel and the initrd) and /efi. /efi is trivial for the board EFI code to change, but that doesn't do anything the board can't do directly so isn't much worth worrying about, I think.

The kernel and the initrd are more of a problem. But hacking my kernel image is unlikely for something trying to be helpful, I think. I suppose it could manipulate my initrd either on disk or after loading it easily enough - as far as I know it isn't signed or encrypted? I ought to check.

On the other hand, my normal Linux boot uses grub (or refind on some systems). Unless the EFI code decided to bypass those boot loaders and load the kernel and a modified initrd directly it isn't going to get anywhere. And I would certainly notice bypassing those (still assuming it isn't malicious and replicating my normal boot output to hide itself).

[Graham 32]

Re: How do we defend against this? - Linux edition

Came to the comments with the same question. David 132's post above suggests it's the OS that pulls the file from UEFI. The article makes it sound like UEFI is pushing the file to disk. If it's a pull system then I'm less worried. Linux would have to implement it, the motherboard would have to ship with a Linux version of the file, and Linux would have to ignore all sensible security checks such as asking the user if it's ok. That's just not Linux's style. Some clarity about the mechanism would help.

[v13]

Re: How do we defend against this? - Linux edition

For a push system an encrypted root filesystem should solve the problem since it won't be able to write anything there. Not encrypting your disks is a much bigger problem so the BIOS would be the least of your concerns.

[doublelayer]

Re: How do we defend against this? - Linux edition

I suggested the same thing, but that only works against a lazy implementation. If they were determined to push it, they wouldn't have to be blocked by encrypted volumes since, to boot them, you'll eventually enter decryption keys. The firmware could watch for them and then jump in to make edits before the kernel finished booting from them.

Implementing that would be quite a bit harder, and I wouldn't expect a company just trying to manage updates to do so. That doesn't make it impossible, though.

[david 12]

Re: How do we defend against this? - Linux edition

That's just not Linux's style.

However, that is the entire point of UEFI: it abstracts the hardware, so that it can be loaded by the OS instead of having to (a) make the M/B specific to the OS, or (b) make the OS specific to the M/B.

[Aitor 1]

Re: How do we defend against this? - Linux edition

You are correct, but uefi is just wrong. It is running a mystery os that is unaccountable.

It does have benefits, but is very unsecure.

If we add the "secure" enclaves mystery os, plus complex os/firmware in drives and network cards, what a security nightmare.

[cyberdemon]

Re: How do we defend against this? - Linux edition

Obviously the only solution is to enable secure boot (and with it kernel lockdown) and sign all your initrd and all your kernel modules with your MOK, and render your linux box pretty much useless in the process.

(Meanwhile you are still backdoored by whatever evil lurks inside Intel Management Engine and your CPU microcode)

Stop worrying and learn to love the NSA ..

[Anonymous Coward]

Firmware insecure by design

Maybe the firmware insecure by design to allow backdoor access?

[Doctor Syntax]

A few years ago you might have found a vendor-specific driver provided as a separate disk or maybe included with the pre-installed OS. It would have filled the same role but a little more overtly, Why do they do things differently now? Because they can. Back then the BIOS was a relatively simple (less so than back in 8-bit days) that did a few things and (hopefully) did them well. Now it's an OS running under the user's choice of OS with greatly enhanced powers including greatly enhanced powers of doing things badly or doing bad things. And we're told it can do things such as "secure boot" and provide a "trusted platform module". In whose view is the boot secure and who trusts it. Not the user, that's for sure.

[Kurgan]

UEFI is the Systemd of BIOS

UEFI it to BIOS what Systemd is to Init.

UEFI is bloated, insecure, buggy, malfunctioning, incompatible and complicated and it's a solution to a problem that simply did not exist in the first place. Like systemd.

[sitta_europea]

Re: UEFI is the Systemd of BIOS

"UEFI is the Systemd of BIOS

UEFI it to BIOS what Systemd is to Init.

UEFI is bloated, insecure, buggy, malfunctioning, incompatible and complicated and it's a solution to a problem that simply did not exist in the first place. Like systemd."

How very true. Have an upvote on me.

This isn't the place for me to list the things that systemd has done to me, and thus explain why I loathe it so thoroughly, and you haven't got time to listen to such a lenghty diatribe anyway, but to get back on the topic the main reason that I don't worry about UEFI is that I won't have it on site.

[Orv]

Re: UEFI is the Systemd of BIOS

UEFI is absolutely hideously over-engineered, but that doesn't change that the PC BIOS was no longer really fit for purpose. It was hacks on top of hacks on top of hacks just to boot from large disks, USB, etc., it couldn't boot from GPT partitions unless you also made a fake legacy partition table, and you needed extra software to boot multiple operating systems. The fact that we were used to it didn't make it any less ugly.

I'm not sure what the best solution would have been. I kind of thought Sun's trick of making the boot loader a FORTH interpreter was clever, but that probably opens nearly as many attack vectors as UEFI.

[Ace2]

Re: UEFI is the Systemd of BIOS

BIOS - Bugs Idiosyncrasies Oversights and Screwups

[that one in the corner]

Re: UEFI is the Systemd of BIOS

> UEFI is absolutely hideously over-engineered,

> I'm not sure what the best solution would have been.

For a start, not to have followed Design By Committee procedures quite so assiduously. Gary Kildall's BIOS was well made and performed the task sensibly, but as you point out, it had then been hacked upon for decades[1] by whoever got the job dumped on them next.

Although, as you have (inadvertently?) hinted, at the moment the single voice with the most pull who would have gleefully taken on the job would have been Poettering and gawd help us all.

I too liked Sun's use of Forth: you have reminded me, I don't know UEFI at all well (like, how does Windows update manage to make UEFI override my choice of boot OS?). For example, how many different bytecode interpreters are in there now? Is it just ACPI?

[1] starting right from IBM's "we did it deliberately, honest, no we do really know the difference between hex and decimal" in the serial i/o routine in their first PC BIOS.

[Cybersaber]

Read the research

Per a couple of earlier poster's questions:

The UEFI process is able to be disabled. (And is reportedly disabled by default. The fact that the researchers' examples were on doesn't isn't conclusive.)

The UEFI process doesn't write to disk, it writes to memory, which the Windows Session Manager Subsystem checks and then writes to disk as part of its normal process (So disk encryption doesn't defeat it.)

Would it affect Linux? Not by this vector - the reported problem requires the collaboration of the WSM subsystem in windows to read that memory location. The WSM is what accepts and unpacks the payload, all the UEFI does is write the binary to a memory location WSMS looks for. Linux would have to have a WSMS analogue.

[david 12]

the reported problem requires the collaboration of the WSM subsystem in windows to read that memory location

The reported Windows problem uses the WSM subsystem, but that's because it's a Windows application/driver, not because the problem is unique to Windows.

A linux application/driver would do the same using the equivalent linux API. Perhaps something along the lines of "efi_get_memory_map" and "request_firmware"?

[Anonymous Coward]

Firmware update

There now appears to be a firmware update for my motherboard to address these issues - so maybe the company is listening..

[StrangerHereMyself]

Incompetence

This is pure incompetence on the part of the software developers hired or employed by Gigabyte. If they can't even do the minimum (TLS with certificate validation) to secure this kind of stuff then I am loath buying their wares.

[Tron]

Microsoft may have saved our bacon here.

Anyone who has used Microsoft Anything over the last however many decades we have been using PCs, has learned to turn off everything that 'auto' does anything if it is an option. I would rather stop and restart my own heart than update my Mobo's BIOS.

[retiredmonkey]

I can't imagine that any TLA's would take advantage of this.

[John Klos]

Do people actually think things through?

I can't imagine a meeting where people who work at a motherboard company discuss doing something this dumb, then decide it's a good idea and plan to do it, then a team of programmers get tasked to write the code, all the while not a single person points out how ridiculously insecure this whole thing will be.

Are people really that dumb? Spiteful? Evil? I really don't know any more!