5

I found the concept of Secure Boot quite intriguing. I can't say that I know much about it because I don't but I believe I understand the main concept of it.

Secure Boot verifies the signature of the executable the computer is booting. (Usually, the case is the bootloader)

On a computer without secure boot, an attacker could just overwrite \EFI\Boot\bootx64.efi or \EFI\Boot\bootia32.efi depending on the architecture with his own program, his program would somehow infect the machine OS and continue execution with Windows's bootloader which is stored in \EFI\Microsoft\Boot\bootmgr.efi

Secure Boot prevents that because the attacker's EFI executable isn't signed.

But that could easily be evaded.

An attacker could just install systemd-boot bootloader which would call the attacker's EFI file which would call the Windows Bootloader after it does its work.

Am I missing something?

Improve this question

2 Answers 2

Reset to default
5

systemd-boot has to be signed as well. The original signed gummiboot respects the 'secure' boot process and requires that the binaries it is to launch are signed as well: https://www.rodsbooks.com/efi-bootloaders/secureboot.html

So it's not quite that trivial. But there are attacks on a different part of the boot process (called Secure Boot by Windows, but not part of the UEFI Secure Boot) that do override some protections:

The very term secure in relation to x86 architecture is always relative; It has to be viewed like car crash ratings - no car is crash-proof, some just take a bit more force to make it fatal.

This is to some degree inherent to all security, but with other designs there's a steep S-curve from "open wide" to "need an an electron microscope and a focused ion beam to crack". The efforts to secure a x86+Windows system are akin to plugging every hole on a sieve to make it seaworthy - with the proviso that every plug must open automatically when some legacy feature depends on the sieve's original function of letting the water through.

Improve this answer
3
  • The articles you linked have nothing to with UEFI Secure Boot. They refer to the widely misunderstood "Secure Golden Key Boot" vulnerability in the Windows Boot Manager (WBM). As soon as WBM executes, UEFI Secure Boot ends, and WBM is now responsible for signature verification of all EFI images (e.g winload.efi) that it chainloads. "Secure Golden Key Boot" only allows one to bypass this verification, not the signature verification done by the firmware (i.e. UEFI Secure Boot). The misunderstand is largely due to Microsoft's lax terminology in calling WBM's signature verification Secure Boot.
    – wmjdgla
    Commented Apr 13, 2020 at 13:31
  • Realized my response above was rather curt. My apologies, had to cut some words due to the word limit.
    – wmjdgla
    Commented Apr 13, 2020 at 14:42
  • @wmjdgla Thanks, I'll keep that in mind. Yes, upon checking more closely, the attacks are on a different part of the system.
    – Therac
    Commented Apr 13, 2020 at 17:21
3

I think the theory is that each level only signs an instance of the next level if it implements signature checks correctly.

In other words systemd-boot is supposed to do signature checks, and only load files that pass validation.

Obviously there may be gaps between theory and practice...

Improve this answer
1
  • 1
    You're describing SRTM, which is distinct from Secure Boot.
    – forest
    Commented Mar 4, 2018 at 3:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .