4 ms·

> Isn't a secure boot policy that can be bypassed with physical access more secure than none? Of course it isn't. Impossibility of bypassing is the only reaso

> Isn't a secure boot policy that can be bypassed with physical access more secure than none? Of course it isn't. Impossibility of bypassing is the only reason for secure boot technologies to exist. They are invented so that you are NOT automatically screwed if an attacker has physical access to your device. Secure boot technology is fine in principle, it's just stupid position the manufacturers hold. They ignore recent history. At their own peril, I'd say. https://en.wikipedia.org/wiki/Clipper_chip https://en.wikipedia.org/wiki/Clipper_chip And I'm not even sure physical access factor is strictly necessary for adversarial bypassing. (I'm not a security expert, too.)

bradford 10y ago
>> Isn't a secure boot policy that can be bypassed with physical access more secure than none? >Of course it isn't. Really? Suppose that you are choosing a new device. You can choose one that let's a remote hacker install a rootkit via a malicious website, or you can choose one that let's a hacker install a rootkit only when they have physical access to your device. Which one do you choose, and why is it the latter?
- s_tec 10y ago
  What about the third option, where a hacker can't install a rootkit even if they have physical access? That's what MS tried to build, but is now completely broken.
- deleted 10y ago
  [deleted]
sp332 10y ago
You need admin rights, but not physical access.
- bradford 10y ago
  requiring admin rights for an exploit is certainly a lower barrier to entry than is requiring physical access, but I think my point still stands: if someone has those rights, you're already screwed.
  - noenpnqnoen 10y ago
    ...which means secure boot doesn't provide security.
  - stable-point 10y ago
    > if someone has those rights, you're already screwed. I think that this was once true, but Secure Boot was an attempt to improve the situation. My understanding is that Microsoft's Virtualization Based Security (which Device Guard/Credential Guard are built upon) rely on the assumption that the boot process is secure. If an attacker could have their root kit load before the OS/Hyper-V, then they render those mitigations useless.

bradford 10y ago

>> Isn't a secure boot policy that can be bypassed with physical access more secure than none? >Of course it isn't. Really? Suppose that you are choosing a new device. You can choose one that let's a remote hacker install a rootkit via a malicious website, or you can choose one that let's a hacker install a rootkit only when they have physical access to your device. Which one do you choose, and why is it the latter?

s_tec 10y ago
What about the third option, where a hacker can't install a rootkit even if they have physical access? That's what MS tried to build, but is now completely broken.
deleted 10y ago
[deleted]

sp332 10y ago

You need admin rights, but not physical access.

bradford 10y ago
requiring admin rights for an exploit is certainly a lower barrier to entry than is requiring physical access, but I think my point still stands: if someone has those rights, you're already screwed.
- noenpnqnoen 10y ago
  ...which means secure boot doesn't provide security.
- stable-point 10y ago
  > if someone has those rights, you're already screwed. I think that this was once true, but Secure Boot was an attempt to improve the situation. My understanding is that Microsoft's Virtualization Based Security (which Device Guard/Credential Guard are built upon) rely on the assumption that the boot process is secure. If an attacker could have their root kit load before the OS/Hyper-V, then they render those mitigations useless.