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.
Permalink for comment 551510
To read all comments associated with this story, please click here.
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