3

I have the idea that many UEFI motherboards are software flashable. For example, Gigabyte's flashing instructions for their motherboards describes a "A Windows-based BIOS live update utility" which would appear to just run as application software on the computer. Is this correct, are Gigabyte and other motherboard manufacturers now producing software flashable motherboards?

By "software flashable" I mean that no action on the computer hardware (like pushing a button or inserting a USB key) needs to be done, thus the machine could be flashed remotely.

If so, then this is a huge security problem because malware or an enemy operative with remote control of the computer (RAT) could reflash the BIOS/UEFI. Since UEFI code cannot be read from the chip by external software, there is no way to know if I have a genuine OEM UEFI on my system or a malware UEFI.

Is there any way to hardware block UEFI flashing to make it impossible for a remote attacker to reflash my UEFI/BIOS?

  • Some boards (I've seen that on business-grade laptops like Thinkpads and Dell Latitude) have an option in the firmware to only allow signed firmware to be installed. I would expect this to either block the flash right away or let it flash but refuse to execute the malicious code on next boot. – André Borie Jan 25 '17 at 22:22
  • @AndréBorie LOL obviously the malware would make sure it was signed before it tried to flash itself. – Tyler Durden Feb 18 '17 at 11:26
  • To get signed the malware would need cooperation from the machine's manufacturer, something usually not trivial. – André Borie Feb 19 '17 at 0:21
  • 1
    @AndréBorie That's absurd, if it is a government hacker, the company will just hand over the keys, and even a foreign hacker can simply hack the company. Driver signing keys are widely traded in hacking circles. I am looking for actual security here, not some kind of PR statement about how great "secure boot" is. Every year, a bunch of people at Black Hat go through the 16 different ways they either hack secure boot or find some other workaround to obviate it. – Tyler Durden Feb 19 '17 at 0:26
  • 1
    @AndréBorie In any case, the question is not about validating updates to the UEFI. The question is about STOPPING them. I want to prevent remote flashing of my firmware, not validate updates. This question has nothing to do with validation. – Tyler Durden Feb 19 '17 at 0:36
4

Well, that's one reason why UEFI sucks. In theory (and don't get me wrong: nobody serious in sec. ever believed this would work in RL) secure boot and signed drivers should prevent "malware" from being installed. But well: certs get stolen and exploits get found. There have already been many papers on that topic. This driver signing BS is more like a salesman argument from UEFI vendors in case anyone asks (as you just did). Story goes like this: Salesman: "yes we're aware of the risks and we're doing some magic that prevents that. Now I'm not an tech guy but our experts say it works. 100%.". Silence. Everybody in the management board nods in approval, IT-sec guy jumps out of the window.

Now while I'm bashing UEFI let's not forget that long before UEFI there have been (many) vendors that enabled you to flash your BIOS from within the OS (very common in the server / enterprise market but I've seen it on high-end enduser mainboard (ASUS WS PRO series) as well). They did that building proprietary chips and interfaces. So this is not a entirely new problem with UEFI and one could argue UEFI made it better because atleast now we have a standard way to fuc* things up. One could also argue that now you don't have to reverse engineer ALL the mainboards because everyone is using the same known vulnerabilities. One could also say that UEFI made it worse due to unnecessary complexity, adding features to a bootloader nobody ever asked for, which increases the chance of bugs in the implementation.

That said please note that there are efforts to do things better. But unfortunately I yet have not had time to dig in deep into what those alternatives do better (maybe someone wiser can elaborate on this topic?) and - as so often in the history of technology - even if those approaches would be better than what UEFI has to offer they will probably always life in the shadow of the crap the industry has choosen (UEFI). So, till the first nuclear power plant explodes and people die I guess we'll have to live with UEFI (and even then I'm not sure something would change when it comes to IT security).

Oh and because you asked: no, there is nothing you can do to prevent malware from doing such an attack. Besides installing something else then UEFI (with potentially other risks and vulnerabilities). I'm not sure about possible "hardware modifications" that would prevent write access to the UEFI env. but if there is a way it'll probably be very hardware specific and probably not easy to DIY.

But let me tell you: if you panic by knowing this now better don't have a look at what Intel did with AMT (hint: AMD has similar BS). And no: you can't turn off that crap either.

  • Difference is AMD's 'crap' is open source and you can check it for bugs/exploits/etc. You can't on intel's. They do what they want, how they want and you can't do anything about that. – Overmind Jan 26 '17 at 12:32
  • @Overmind still there should be a simple way to disable functions I don't want. Especially when they are very proprietary and provide little to no use to a end-user. Dunno for AMD but Intels "crap" can't be turned off and is added to nearly every CPU they build (even Desktop / Laptop CPUs). It's like even for 3000$ you cant buy a secure x86 CPU anymore just because they started adding stuff nobody asked for. BTW: no offense. I'm sure Intel and AMD both employ very capable people. But somebody there makes bad security decisions and this needs to stop. – masi Jan 26 '17 at 18:01
  • Indeed such a feature should be on choice, not mandatory, but how else will the perfect totalitarian world come into effect ? I don't know if you noticed, but that is the tendency. For your 'security' you give up everything. There are plenty of such examples, including the Grayfish Seagate boot spyware. – Overmind Jan 27 '17 at 9:54
0

Set a firmware password if applicable. Otherwise, no unless you write your own custom firmware for it.

  • A password will not prevent an already running OS from writing to the firmware chip and installing a malicious one. – André Borie Jan 25 '17 at 22:27
  • You are correct. misunderstood the question. had to re-read – Tim Jan 25 '17 at 22:36
  • @AndréBorie According to this article on How-To Geek: howtogeek.com/186235/… a UEFI password prevents software updating of the firmware. Is that not right? – Tyler Durden Feb 18 '17 at 11:35
  • @TylerDurden it depends on the implementation, if the firmware ever guards access to the flash chip. Some may not and thus the OS is free to install whatever malicious firmware they want, without needing a password. – André Borie Feb 19 '17 at 0:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.