5 ms·

Secure Boot is utterly broken (for general purpose pcs at least) anyways. I can just take an old windows kernel and boot with a configuration that loads a drive

Secure Boot is utterly broken (for general purpose pcs at least) anyways. I can just take an old windows kernel and boot with a configuration that loads a driver with a known vulnerability (a certain gpu manufacturer might be a good place to look) and a script that use it to run kernel mode code that does whatever it wants. Newer Windows kernels generally blacklists drivers with know vulns, but you can just use an older version, and practically speaking old windows kernels can't be blacklisted because then people's install media that they might have paid for would stop working.

indolering 9y ago
You could also unenroll all vendor supplied signing keys and load it up with one that you keep in a HSM. Yes, you are technically correct that any opportunistic encryption scheme can be bypassed but it adds cost to the attack and (more importantly) it is a step towards a more secure system.
- poizan42 9y ago
  I feel like that is missing the point. You need social engineering (and probably not an easy case) to get people to change the keys. Using a pre-made image that allows you to bypass secure boot by way of a windows driver with a known vuln is practically free as soon as anyone packages it. I don't know whether that is currently being done, but I suspect it since I have seen people discussing bypassing PatchGuard in Windows 10 where they used a known exploit in a driver from a company that starts with n and ends with vidia.
  - my123 9y ago
    PatchGuard can be disarmed on 8.1 ;-)
- zokier 9y ago
  I remember hearing that there is some problem unenrolling vendor keys, especially MS ones, because they are also used to sign some of the firmware blobs. I'm not sure if that concern really became realized at any point, do you have any information regarding that?
  - my123 9y ago
    Blobs inside the FW image are not subjected to signature checks.
    - zokier 9y ago
      I think it is bit more complicated than that. I checked some presentations [1] about UEFI/SB, and they do seem to imply that there is potentially some blobs (namely option roms, uefi applications and dxe drivers) that need to pass signature check. I don't know how much such modularity is really used in real life, especially in the boot path, but I think the "best practice" recommendation is to keep dxe core small and have stuff as loadable drivers. [1] eg http://c7zero.info/stuff/Windows8SecureBoot_Bulygin-Furtak-Bazhniuk_BHUSA2013.pdf http://c7zero.info/stuff/Windows8SecureBoot_Bulygin-Furtak-B...
      - my123 9y ago
        Everything that is in the ROM proper isn't checked actually, in TianoCore at least.
- hedora 9y ago
  I think I set this up in about 5 minutes on my devuan laptop (basically just Debian 8.3 for the purposes of this discussion). I told it to delete all its keys, then whitelisted the debian efi blob (no Microsoft signature needed), and all was well. I did not test the configuration with an old copy of windows, but I'm pretty sure installing secure-boot enabled Linux distros now fails as expected. Is this not standard functionality for secureboot laptops?
hackuser 9y ago
FWIW Secure Boot has its own blacklist, called the Revoked Signatures or Forbidden Signatures database or dbx, though I don't know if and how it is actually used. > old windows kernels can't be blacklisted because then people's install media that they might have paid for would stop working. I understand the theory, but are you sure that is true in practice? There also could be a workaround (such as disabling Secure Boot for the install).
- my123 9y ago
  Microsoft uses STLs, which are flashed into UEFI variables. (had other glaring issues though, Secure Boot policies weren't checked with DBX or the STLs... which made it a real issue)
- poizan42 9y ago
  There was the secure golden key boot exploit last year[0]. In the conclusion they also points out that Microsoft can't revoke the affected bootmgr versions: > Either way, it'd be impossible in practise for MS to revoke every bootmgr earlier than a certain point, as they'd break install media, recovery partitions, backups, etc. [0]: https://rol.im/securegoldenkeyboot/ https://rol.im/securegoldenkeyboot/
my123 9y ago
Oh well, Secure Boot security is a can of worms. It can be workarounded with enough effort...
hackuser 9y ago
> Secure Boot is utterly broken (for general purpose pcs at least) anyways. I can just take an old windows kernel and boot with a configuration that loads a driver with a known vulnerability (a certain gpu manufacturer might be a good place to look) and a script that use it to run kernel mode code that does whatever it wants. If you are referring to the Golden Key exploit (a misnomer because it doesn't involve keys, FWIW), it doesn't impact desktops and laptops, possibly because you can simply disable Secure Boot on them, but does affect certain mobile devices on which Secure Boot was supposed to be impossible to disable. It also requires physical access.

indolering 9y ago

You could also unenroll all vendor supplied signing keys and load it up with one that you keep in a HSM. Yes, you are technically correct that any opportunistic encryption scheme can be bypassed but it adds cost to the attack and (more importantly) it is a step towards a more secure system.

poizan42 9y ago
I feel like that is missing the point. You need social engineering (and probably not an easy case) to get people to change the keys. Using a pre-made image that allows you to bypass secure boot by way of a windows driver with a known vuln is practically free as soon as anyone packages it. I don't know whether that is currently being done, but I suspect it since I have seen people discussing bypassing PatchGuard in Windows 10 where they used a known exploit in a driver from a company that starts with n and ends with vidia.
- my123 9y ago
  PatchGuard can be disarmed on 8.1 ;-)
zokier 9y ago
I remember hearing that there is some problem unenrolling vendor keys, especially MS ones, because they are also used to sign some of the firmware blobs. I'm not sure if that concern really became realized at any point, do you have any information regarding that?
- my123 9y ago
  Blobs inside the FW image are not subjected to signature checks.
  - zokier 9y ago
    I think it is bit more complicated than that. I checked some presentations [1] about UEFI/SB, and they do seem to imply that there is potentially some blobs (namely option roms, uefi applications and dxe drivers) that need to pass signature check. I don't know how much such modularity is really used in real life, especially in the boot path, but I think the "best practice" recommendation is to keep dxe core small and have stuff as loadable drivers. [1] eg http://c7zero.info/stuff/Windows8SecureBoot_Bulygin-Furtak-Bazhniuk_BHUSA2013.pdf http://c7zero.info/stuff/Windows8SecureBoot_Bulygin-Furtak-B...
    - my123 9y ago
      Everything that is in the ROM proper isn't checked actually, in TianoCore at least.
hedora 9y ago
I think I set this up in about 5 minutes on my devuan laptop (basically just Debian 8.3 for the purposes of this discussion). I told it to delete all its keys, then whitelisted the debian efi blob (no Microsoft signature needed), and all was well. I did not test the configuration with an old copy of windows, but I'm pretty sure installing secure-boot enabled Linux distros now fails as expected. Is this not standard functionality for secureboot laptops?

hackuser 9y ago

FWIW Secure Boot has its own blacklist, called the Revoked Signatures or Forbidden Signatures database or dbx, though I don't know if and how it is actually used. > old windows kernels can't be blacklisted because then people's install media that they might have paid for would stop working. I understand the theory, but are you sure that is true in practice? There also could be a workaround (such as disabling Secure Boot for the install).

my123 9y ago
Microsoft uses STLs, which are flashed into UEFI variables. (had other glaring issues though, Secure Boot policies weren't checked with DBX or the STLs... which made it a real issue)
poizan42 9y ago
There was the secure golden key boot exploit last year[0]. In the conclusion they also points out that Microsoft can't revoke the affected bootmgr versions: > Either way, it'd be impossible in practise for MS to revoke every bootmgr earlier than a certain point, as they'd break install media, recovery partitions, backups, etc. [0]: https://rol.im/securegoldenkeyboot/ https://rol.im/securegoldenkeyboot/

my123 9y ago

Oh well, Secure Boot security is a can of worms. It can be workarounded with enough effort...

hackuser 9y ago

> Secure Boot is utterly broken (for general purpose pcs at least) anyways. I can just take an old windows kernel and boot with a configuration that loads a driver with a known vulnerability (a certain gpu manufacturer might be a good place to look) and a script that use it to run kernel mode code that does whatever it wants. If you are referring to the Golden Key exploit (a misnomer because it doesn't involve keys, FWIW), it doesn't impact desktops and laptops, possibly because you can simply disable Secure Boot on them, but does affect certain mobile devices on which Secure Boot was supposed to be impossible to disable. It also requires physical access.