Comment by romaniv

7 hours ago

I still hope that one of these days people in general will realize that executable signing and SecureBoot are specifically designed for controlling what a normal person can run, rather than for anything resembling real security. The premises of either of those "mitigations" make absolutely no sense for personal computers.

I strongly disagree on the Secure Boot front. It's necessary for FDE to have any sort of practical security, it reduces malicious/vulnerable driver abuse (making it nontrivial), bootkits are a security nightmare and would otherwise be much more common in malware typical users encounter, and ultimately the user can control their secure boot setup and enroll their own keys if they wish.

Does that mean that Microsoft doesn't also use it as a form of control? Of course not. But conflating "Secure Boot can be used for platform control" with "Secure Boot provides no security" is a non-sequitur.

  • Full disk encryption protects from somebody yanking a hard drive from running server (actually happens) or stealing a laptop. Calling it useless because it doesn't match your threat model... I hate todays security people, can't threat model for shit.

    • I (the commenter you responded to) am a security engineer by trade and I'm arguing that SB is useful. I'm not sure if the parent commenter is or isn't a security person but my interactions with other people in the security field have given me the impression that most of them think it's good, too.

      So I'm a little confused about the "can't threat model for shit part," I think these sorts of attacks are definitely within most security folks threat models, haha

    • > Full disk encryption protects from somebody yanking a hard drive from running server (actually happens) or stealing a laptop.

      Both of these are super easy to solve without secure boot: The device uses FDE and the key is provided over the network during boot, in the laptop case after the user provides a password. Doing it this way is significantly more secure than using a TPM because the network can stop providing the key as soon as the device is stolen and then the key was never in non-volatile storage anywhere on the device and can't be extracted from a powered off device even with physical access and specialized equipment.

      6 replies →

  • Secure Boot provides no useful security for an individual user on the machine they own, and as such should be disabled by default.

    If you want to enable it for enterprise/business situations, thats fine, but one should be clear about that. Otherwise you get the exact Microsoft situation you mentioned and also no one knows about it.

    • So everyday users should be vulnerable to bootkits and kernel-mode malware...why, exactly? That is useful security. The fact that people do not pursue this type of malware very frequently is an effect of SB proliferation. If it were not the default then these attacks would be more popular.

      2 replies →

  • >It's necessary for FDE to have any sort of practical security

    why? do you mean because evil maid attacks exist? anyone that cared enough about that specific vector just put their bootloader on a removable media. FDE wasn't somehow enabled by secure boot.

    >bootkits are a security nightmare and would otherwise be much more common in malware

    why weren't they more common before?

    serious question. Back in the 90s viruses were huge business, BIOS was about as unprotected as it would ever possibly be, and lots of chips came with extra unused memory. We still barely ever saw those kind of malware.

    • > anyone that cared enough about that specific vector just put their bootloader on a removable media. FDE wasn't somehow enabled by secure boot.

      Sure, but an attacker could still overwrite your kernel which your untouched bootloader would then happily run. With SB at least in theory you have a way to validate the entire boot chain.

      > why weren't they more common before?

      Because security of the rest of the system was not at the point where they made sense. CIH could wipe system firmware and physically brick your PC - why write a bootkit then? Malware then was also less financially motivated.

      When malware moved from notoriety-driven to financially-driven in the 2000s, bootkits did become more common with things like Mebroot & TDL/Alureon. More recently, still before Secure Boot was widespread, we had things like the Classic Shell/Audacity trojan which overwrote your MBR: https://www.youtube.com/watch?v=DD9CvHVU7B4 and Petya ransomware. With SB this is an attack vector that has been largely rendered useless.

      It's also a lot more difficult to write a malicious bootloader than it is to write a usermode app that runs itself at startup and pings a C2 or whatever.

      3 replies →

    • > serious question. Back in the 90s viruses were huge business,

      No, they were not. They were toys written for fun and/or mischief. The virus authors did not receive any monetary reward from writing them, so they were not even a _business_. So they were the work of individuals, not large teams.

      The turning point was Bitcoin. Suddenly it provided all those nice new business models that can be scaled up: mining, stealing cryptowallets, ransomware, etc.

      1 reply →

  • Instead of proprietary SecureBoot controlled by megacorps, you can use TPM with Heads based entirely on FLOSS with a hardware key like Librem Key. Works for me and protects from the Evil Maid attack.

I don't know about executable signing, but in the embedded world SecureBoot is also used to serve the customer; id est provide guarantees to the customer that the firmware of the device they receive has not been tampered with at some point in the supply chain.

  • Computers should abide by their owners. Any computer not doing that is broken.

    • Its a simple solution in law to enable. Force manufacturers to allow owners of computer to put any signing key in the BIOS.

      We need this law. Once we have this law, consumers csn get maximum benefit of secure boot withiut losing contorl

      3 replies →

    • I make the analogy with a company, because on that front, ownership seems to matter a lot in the Western world. It's like it had to have unfaithful management appointed by another company they're a customer of, as a condition to use their products. Worse, said provider is also a provider for every other business, and their products are not interoperable. How long before courts jump in to prevent this and give back control to the business owner?

    • This gets tricky. If I click on a link intending to view a picture of a cat, but instead it installs ransomware, is that abiding by its owner or not? It did what I told it to do, but not at all what I wanted.

      4 replies →

  • And what if that customer wants to run their own firmware, ie after the manufacturer goes out of business? "Security" in this case conveniently prevente that.

    • Tradeoffs. Which is more likely here?

      1. A customer wants to run their own firmware, or

      2. Someone malicious close to the customer, an angry ex, tampers with their device, and uses the lack of Secure Boot to modify the OS to hide all trace of a tracker's existence, or

      3. A malicious piece of firmware uses the lack of Secure Boot to modify the boot partition to ensure the malware loads before the OS, thereby permanently disabling all ability for the system to repair itself from within itself

      Apple uses #2 and #3 in their own arguments. If your Mac gets hacked, that's bad. If your iPhone gets hacked, that's your life, and your precise location, at all times.

      19 replies →

  • I don't know about executable signing, but in the embedded world SecureBoot is also used to serve the PRODUCER; id est provide guarantees to the PRODUCER that the firmware of the device they SELL has not been tampered with at some point in the PROFIT chain.

  • > id est provide guarantees to the customer that the firmware of the device they receive has not been tampered with

    The firmware of the device being a binary blob for the most part... Not like I trust it to begin with.

    Whereas my open source Linux distribution requires me to disables SecureBoot.

    What a world.

    • You can set up custom SecureBoot keys on your firmware and configure Linux to boot using it.

      There's also plenty of folks combining this with TPM and boot measurements.

      The ugly part of SecureBoot is that all hardware comes with MS's keys, and lots of software assume that you'll want MS in charge of your hardware security, but SecureBoot _can_ be used to serve the user.

      Obviously there's hardware that's the exception to this, and I totally share your dislike of it.

      2 replies →

    • +1

      An unsigned hash is plenty guard to against tampering. The supply chain and any secret sauce that went into that firmware is just trust. Trust that the blob is well intentioned, trust that you downloaded from the right URL, checked the right SHA, trust that the organization running the URL is sanctioned to do so by Microsoft...

      Once all of that trust for every piece of software is concentrated in one organization, Microsoft, Apple or Google, is has become totally meaningless.

  • It's to serve the regulators. The Radio Equipment Directive essentially requires the use of secure boot fir new devices.

    • I happen to like knowing that my mobile device did not have a ring 0 backdoor installed before it left the factory in Asia. SecureBoot gives me that confidence.

      4 replies →

If only people didn't install Ask Jeeves toolbars all over the place and then asked their grandson during vacations to clean their computer.

  • Geez, this brings back memories.

    At one time at our university we had table desktop dancers installed everywhere. Was kind of funny when it turned up just as a student wanted to defend their work in a lab.

> I still hope that one of these days people in general will realize that executable signing and SecureBoot are specifically designed for controlling what a normal person can run, rather than for anything resembling real security

For home/business users I'd agree. But in Embedded / money-handling then it's a life-saver and a really important technology.

Apple is also somewhat responsible for the attitude shift with the introduction of iOS. 20-25 years ago a locked down bootloader and only permitting signed code would have been seen by techies as dystopian. It's now quite normalized. They say it's about security but it's always been about control.

Stallman tried to warn us with "tivoization".

This is like saying you shouldn't vaccinate your kids because no one gets polio anymore