improve secure boot article after review #3
1 changed files with 49 additions and 44 deletions
|
@ -30,12 +30,13 @@ software.
|
|||
|
||||
## Secure Boot, the technology
|
||||
|
||||
Secure Boot[^spec] is an attempt at ensuring that only authorized software is run on a
|
||||
machine. It does so by bootstrapping the security of the system at boot time,
|
||||
giving way to other technologies to keep the system secure, later on. Secure
|
||||
boot works by authorizing only select executables to be run. Authorized
|
||||
executables are signed using public cryptography, and the keys used to verify
|
||||
those signatures are stored securely in UEFI "databases".
|
||||
Secure Boot[^spec] helps running only authorized software on a machine. It
|
||||
does so by bootstrapping the security of the system at boot time, by verifying
|
||||
signatures on various software components, before giving way to other
|
||||
technologies to keep the system secure, later on. Secure boot works by
|
||||
authorizing only select executables to be run. Authorized executables are
|
||||
signed using public cryptography, and the keys used to verify those signatures
|
||||
are stored securely in UEFI "databases".
|
||||
|
||||
[^spec]: [UEFI Specifications](https://uefi.org/specs/access)
|
||||
|
||||
|
@ -48,26 +49,28 @@ the case of GNU/Systemd/Linux, the bootloader runs the Linux kernel, which
|
|||
shuts down all UEFI Boot Services, before dropping its privileges and then
|
||||
doing "Linux stuff" (like starting the userland part of the operating system).
|
||||
This privilege drop is very important because this is what ensures that no code
|
||||
past that point is able to tamper with the UEFI environment, including UEFI
|
||||
variables, which contains sensitive data.
|
||||
past that point is able to tamper with the UEFI sensitive information,
|
||||
including UEFI variables, which contains sensitive data.
|
||||
|
||||
Secure Boot aims at securing "everything" that is executed prior to that
|
||||
privilege drop. Once the privileges are drop, it is up to the operating system
|
||||
to ensure that only authorized software is run. Most Linux distros do not even
|
||||
try to do it, although there are notable exceptions (Chrome OS, Android, just
|
||||
to name a few). If we run one of the distros that do not leverage technologies
|
||||
privilege drop. Once the privileges are drop, Secure Boot is done and it is up
|
||||
to the operating system to extend that integrity/authenticity protection and
|
||||
ensure that only authorized software is run. Most Linux distros do not even try
|
||||
to do it, although there are notable exceptions (Chrome OS, Android, just to
|
||||
name a few). If we run one of the distros that do not leverage technologies
|
||||
such as dm-verity, fs-verity (with signatures) or Linux IMA (Integrity
|
||||
Management Architecture), then Secure Boot is strictly insufficient to protect
|
||||
user data integrity or even system integrity in general.
|
||||
Management Architecture), then Secure Boot protected the boot integrity for
|
||||
basically nothing, because the security chain is broken by the operating
|
||||
system, and user data is at risk from possibly any tainted userland executable.
|
||||
|
||||
Nevertheless, ANSSI, the French Infosec Agency recommends in its GNU/Linux
|
||||
security guide[^linuxguide] to enable Secure Boot (R3) for all systems
|
||||
requiring medium security level (level 2 out of 4, 1 being the minimal
|
||||
requirements and 4 being for highly secure systems). Meanwhile, using a Unified
|
||||
requirements and 4 being for highly secure systems). Meanwhile, using a Unified
|
||||
Kernel Image to bundle the Linux kernel with a initramfs into a single
|
||||
executable that can be verified by Secure Boot is only recommended[^R6] for
|
||||
highly secure systems (security level 4 out of 4). No recommendation is ever
|
||||
done about using one of the aforementioned integrity features to ensure
|
||||
done about using one of the aforementioned integrity features to ensure
|
||||
operating system integrity.
|
||||
|
||||
[^linuxguide]: no English version yet. [French version](https://www.ssi.gouv.fr/uploads/2019/02/fr_np_linux_configuration-v2.0.pdf)
|
||||
|
@ -81,46 +84,48 @@ level, and 45% even think that it should be a minimum requirement.
|
|||
This article is a strong push-back against ANSSI "recommendation", and it
|
||||
attempts to prove that it is not only useless but incoherent and misleading.
|
||||
|
||||
[^poll]: [Mastodon poll](https://infosec.exchange/@x_cli/109348532363333158)
|
||||
[^poll]: [Mastodon poll](https://infosec.exchange/@x_cli/109348532363333158)
|
||||
|
||||
## Signature verification and default public keys
|
||||
|
||||
Secure boot relies on a set of public keys to verify authorized software
|
||||
authenticity. By default, most vendors ship Microsoft public keys. These keys
|
||||
sign all Microsoft Windows version, of course, but to avoid a monopoly, other
|
||||
executables were signed. The list is rather short because with each signature
|
||||
and authorized software, the attack surface grows and the probability of a
|
||||
vulnerability raises. Several were already found in the recent past (e.g.
|
||||
CVE-2020-10713[^CVE-2020-10713], CVE-2022-34301[^CVE-2022-34301],
|
||||
CVE-2022-34302[^CVE-2022-34302], CVE-2022-34303[^CVE-2022-34303].
|
||||
executables were signed. The list is ought to be short (and unfortunately, it
|
||||
is not) because with each signature and authorized software, the attack surface
|
||||
grows and the probability of a vulnerability raises. Several were already found
|
||||
in the recent past (e.g. CVE-2020-10713[^CVE-2020-10713],
|
||||
CVE-2022-34301[^CVE-2022-34301], CVE-2022-34302[^CVE-2022-34302],
|
||||
CVE-2022-34303[^CVE-2022-34303].
|
||||
|
||||
[^CVE-2020-10713]: [CVE-2020-10713](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713)
|
||||
[^CVE-2020-10713]: [CVE-2020-10713](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713)
|
||||
|
||||
[^CVE-2022-34301]: [CVE-2022-34301](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34301)
|
||||
[^CVE-2022-34301]: [CVE-2022-34301](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34301)
|
||||
|
||||
[^CVE-2022-34302]: [CVE-2022-34302](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34302)
|
||||
[^CVE-2022-34302]: [CVE-2022-34302](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34302)
|
||||
|
||||
[^CVE-2022-34303]: [CVE-2022-34303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34303)
|
||||
[^CVE-2022-34303]: [CVE-2022-34303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34303)
|
||||
|
||||
For this reason, many software still require that Secure Boot be deactivated,
|
||||
including firmware updates by some manufacturers, including
|
||||
Intel[^intelUpgrade] or Lenovo[^lenovoUpgrade].
|
||||
|
||||
[^intelUpgrade]: [Intel UEFI Flash BIOS Update Instruction](https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/UEFI-Flash-BIOS-Update-Instructions.pdf)
|
||||
[^intelUpgrade]: [Intel UEFI Flash BIOS Update Instruction](https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/UEFI-Flash-BIOS-Update-Instructions.pdf)
|
||||
|
||||
[^lenovoUpgrade]: [Lenovo flash BIOS with UEFI tool](https://support.lenovo.com/us/en/solutions/ht118103-flash-bios-with-uefi-tool-ideacentre-stick-300)
|
||||
[^lenovoUpgrade]: [Lenovo flash BIOS with UEFI tool](https://support.lenovo.com/us/en/solutions/ht118103-flash-bios-with-uefi-tool-ideacentre-stick-300)
|
||||
|
||||
Grub and the kernels are not directly authorized by Microsoft, as it would
|
||||
Grub and the kernels are not directly authorized by Microsoft, as it would
|
||||
require for each and every single version to be signed individually by
|
||||
Microsoft. Instead, a binary called Shim[^shim] was developed. This rather
|
||||
small, auditable, innocuous-looking program is signed by Microsoft. Its role is
|
||||
basically that of a trojan horse. Indeed, its only purpose is to
|
||||
cryptographically verify the authenticity of any executable. However, this
|
||||
time, the list of public keys used to verify these executables is not directly
|
||||
under the control of Microsoft. These public keys are either built in Shim
|
||||
itself or stored in a EFI variable serving as a database.
|
||||
basically that of a trojan horse (or a security pivot, depending on the way you
|
||||
look at it). Indeed, its only purpose is to cryptographically verify the
|
||||
authenticity of any executable. However, this time, the list of public keys
|
||||
used to verify these executables is not directly under the control of
|
||||
Microsoft. These public keys are either built in Shim itself or stored in a EFI
|
||||
variable serving as a database.
|
||||
|
||||
[^shim]: [shim source code](https://github.com/rhboot/shim)
|
||||
[^shim]: [shim source code](https://github.com/rhboot/shim)
|
||||
|
||||
Additionally, shim public key list can be altered by any user able to prove
|
||||
"presence". This is the case of any user using the local console or using a BMC
|
||||
|
@ -134,17 +139,17 @@ the system believe that Secure Boot was used to bootstrap security, while
|
|||
untrusted code was ultimately run within the UEFI privileged mode.
|
||||
|
||||
Hence, thanks to shim, just about any signed or unsigned, trusted or untrusted
|
||||
executable can be validated by proxy by Secure Boot using Microsoft keys.
|
||||
executable can be validated by proxy by Secure Boot using Microsoft keys.
|
||||
|
||||
And this conclusion signs (pun intended) the second incoherence in ANSSI
|
||||
recommendations. Indeed, they recommend replacing Microsoft keys by our own set
|
||||
of keys only for highly secure security level (R4). This means that all systems
|
||||
with intermediate (2/4) and enhanced (3/4) security levels will have the false
|
||||
with intermediate (2/4) and enhanced (3/4) security levels will have the false
|
||||
sense of security of running Secure Boot while exposing themselves to attackers
|
||||
capable of proving "presence".
|
||||
|
||||
For what it is worth, shim does provide a way secure all operations, including
|
||||
disabling verification or enrolling new keys by setting a password on shim's
|
||||
disabling verification or enrolling new keys by setting a password on shim's
|
||||
MOK (Machine Owner Keys) Manager[^mokpass]. However, the feature is mostly
|
||||
unused because no Linux distro enables it (it requires user interaction during
|
||||
the boot procedure) and system administrators often mistake the MOK Manager
|
||||
|
@ -153,10 +158,10 @@ password that is asked when running mokutil commands (including `--import` and
|
|||
`--disable-verification`), which is just a password used to confirm the will of
|
||||
the user in the MOK Manager. The author of this article failed to find a single
|
||||
tutorial or article discussing the necessity of setting a MOK Manager for a
|
||||
Secure Boot. ANSSI also failed to recommend that. Most interestingly, setting a
|
||||
MOK Manager password is recommended even for Windows administrators that have
|
||||
Secure Boot. ANSSI also failed to recommend that. Most interestingly, setting a
|
||||
MOK Manager password is recommended even for Windows administrators that have
|
||||
no intention of ever running Linux, because MOK Manager is one of
|
||||
the executables signed by the Microsoft keys.
|
||||
the executables signed by the Microsoft keys.
|
||||
|
||||
[^mokpass]: The command is `mokutil --password`. Please consider using it.
|
||||
|
||||
|
@ -164,7 +169,7 @@ the executables signed by the Microsoft keys.
|
|||
|
||||
Since replacing the Microsoft keys and signing only authorized binaries (i.e.
|
||||
our own Unified Kernel Image and specifically not shim) is an option, why not
|
||||
do that? It just requires that the system administrators replace the Secure
|
||||
do that? It just requires that the system administrators replace the Secure
|
||||
Boot keys. The question of who controls the private key and the signature
|
||||
process is entirely up to whether the signed executable is altered or not by
|
||||
the system administrator. Distros could ship public keys and Unified Kernel
|
||||
|
@ -181,7 +186,7 @@ First, as mentioned earlier, the only thing that we verified is that the
|
|||
Unified Kernel Image is authentic. That kernel must then verify the operating
|
||||
system to ensure that only verified software is run. This requires
|
||||
cryptographic verification of every single executable (binaries, scripts and
|
||||
executable configuration files (because... yeah... that's a thing)) in the
|
||||
executable configuration files (because... yeah... that's a thing)) in the
|
||||
operating system. This can be achieved if we, at minimum, do the following:
|
||||
|
||||
* use a read-only filesystem for our partitions containing executable code,
|
||||
|
@ -217,7 +222,7 @@ of physical access or remote access through a BMC, what is? Is there a better
|
|||
solution?
|
||||
|
||||
Well, to the best of the author knowledge, there is one: using a TPM. Using a
|
||||
TPM will not necessarily prevent an attacker from tainting the firmware. It
|
||||
TPM will not necessarily prevent an attacker from tainting the firmware. It
|
||||
will not necessarily prevent booting untrusted and unverified executables. What
|
||||
a TPM can give us is the ability to unseal a LUKS passphrase and get access to
|
||||
user data if and only if the cryptographically verified right version of UEFI
|
||||
|
|
Loading…
Reference in a new issue