Linked by Thom Holwerda on Mon 4th Feb 2013 22:10 UTC
Google "People are, unsurprisingly, upset that Microsoft have imposed UEFI Secure Boot on the x86 market. A situation in which one company gets to determine which software will boot on systems by default is obviously open to abuse. What's more surprising is that many of the people who are upset about this are completely fine with encouraging people to buy Chromebooks. Out of the box, Chromebooks are even more locked down than Windows 8 machines." Good point.
Thread beginning with comment 551437
To read all comments associated with this story, please click here.
Repeat a lie until it becomes the truth
by saso on Tue 5th Feb 2013 00:01 UTC
saso
Member since:
2007-04-18

This whole UEFI business is just a wonderful example of how when you repeat a lie long enough, it becomes accepted truth. UEFI SecureBoot never was about boot viruses, though yes, it does make them very hard or near impossible. The whole point of this technology has always been to shift control over the software users install over to the hardware vendor.

MBR viruses have been a dead horse for at least 10-15 years now, ever since the web browser and its plugins became a much more lucrative target for malware. Please note that SecureBoot in no way prevents rootkits or kernel exploits - it's still the responsibility of the OS to verify all code it loads.

UEFI is just a whole bunch of new ways for your machine to fail or misbehave. If you think ACPI was bad enough, wait till you get a load of UEFI firmware bugs, such as DMA'ing network packets over a region of memory where it wasn't supposed to (causing random OS crashes), or, as in the case of Samsung, bricking your machine because some OS had the audacity to follow Samsung's own declared APIs. One Linux user of the samsung UEFI driver also reported that due to a UEFI firmware bug, installing Ubuntu caused Samsung's UEFI to overwrite its "Setup" boot entry with Ubuntu, blocking access to the firmware setup menu. On servers, it's an even worse plague - IBM servers with UEFI configuration menus now require mouse input in order to set up properly (it's still possible via the keyboard, but it's about as pleasant as walking over broken glass). And forget about serial console redirection - text terminals can't handle GUIs, so no remote recovery for you!

The BIOS was crap, but at least it was simple. It loaded into predictable locations, and all we needed was a simple set of BIOS extensions in well specified regions to provide new features. Instead, this UEFI crap was concieved of, with the spec itself over a motherfucking 2200 pages long. FFS, all parts of MPEG-2 are together less than 1000 pages long (the core systems+video+audio tech is < 500 pages), and that's a fully-fledged multimedia system. With a spec this long, it's no wonder firmware vendors (who are crap at producing even workable BIOSes) will produce terrible implementations.

Reply Score: 16

Brendan Member since:
2005-11-16

Hi,

MBR viruses have been a dead horse for at least 10-15 years now, ever since the web browser and its plugins became a much more lucrative target for malware. Please note that SecureBoot in no way prevents rootkits or kernel exploits - it's still the responsibility of the OS to verify all code it loads.


To install an MBR boot virus you'd need write access to the MBR (and it's extremely easy to detect if that sector has been modified). Also, the MBR boot virus would need to run in real mode while all sane OSs switch to protected mode (or long mode) and discard all of the real mode code, so an MBR virus can't easily do anything after the OS has booted. These are the things that makes an MBR boot virus a waste of time.

For UEFI, everything typically sits on a big FAT partition with no security whatsoever; and various parts of UEFI remain (and may be executed as privileged code) after the OS boots. These things combined mean that (without secure boot) UEFI is a massive security disaster.

Secure boot is an attempt to fix UEFI's huge gaping security holes. It's very necessary.

The problem is who manages the keys. The EFI/UEFI specifications should have required that the computer's owner has complete control over all keys; and that OEMs, OS providers and the current user (if they aren't also the computer's owner - e.g. "disgruntled employee") has no control of any keys at all.

- Brendan

Reply Parent Score: 7

saso Member since:
2007-04-18

To install an MBR boot virus you'd need write access to the MBR (and it's extremely easy to detect if that sector has been modified). Also, the MBR boot virus would need to run in real mode while all sane OSs switch to protected mode (or long mode) and discard all of the real mode code, so an MBR virus can't easily do anything after the OS has booted. These are the things that makes an MBR boot virus a waste of time.

I didn't purport to explain all of the problems with MBR viruses. Yes, all you said is true, they are difficult to write, however, once installed (and if done properly), they are very difficult to detect (e.g. by manipulating the VM layout, you can trick the OS into thinking it's calling the BIOS, when its actually calling your crafted functions, allowing you to mask your presence). However, even in their hey days (we're talking DOS/Win3 early 90s), they were very few and far between.

For UEFI, everything typically sits on a big FAT partition with no security whatsoever; and various parts of UEFI remain (and may be executed as privileged code) after the OS boots. These things combined mean that (without secure boot) UEFI is a massive security disaster. Secure boot is an attempt to fix UEFI's huge gaping security holes. It's very necessary.

Well, it depends on the OS - if the OS doesn't allow you to modify this partition, then its over. It's not the choice of filesystem that makes a system insecure ("chmod -R a+rwx /" and you've got the same on a Unix machine, on Linux its easy to solve FAT's insecurity thusly: "mount /mountpoint -o remount,ro"). I'm not saying there isn't any value in SecureBoot - the evil maid attack is one example where it helps a lot - I'm saying that the reasons for UEFI's and SecureBoot's widespread adoption aren't to help protect users, but to transfer control over the machine from the user to the manufacturer and the security thing is just a cloak under which they want to hide it. News sites such as OSNews are doing users a disservice by not calling the vendors out on it at every opportunity. This isn't about securing your machine from attackers. It's about securing the machine from you, the owner.

The problem is who manages the keys. The EFI/UEFI specifications should have required that the computer's owner has complete control over all keys; and that OEMs, OS providers and the current user (if they aren't also the computer's owner - e.g. "disgruntled employee") has no control of any keys at all.

Yes, that would be part of the spec if it were intended to help users. My contention is that that was actually not the goal.

Edited 2013-02-05 12:10 UTC

Reply Parent Score: 3