improve secure boot article after review #3

Merged
fmaury merged 2 commits from secure_boot_2 into master 2022-12-16 16:09:06 +00:00

View file

@ -30,12 +30,13 @@ software.
## Secure Boot, the technology ## Secure Boot, the technology
Secure Boot[^spec] is an attempt at ensuring that only authorized software is run on a Secure Boot[^spec] helps running only authorized software on a machine. It
machine. It does so by bootstrapping the security of the system at boot time, does so by bootstrapping the security of the system at boot time, by verifying
giving way to other technologies to keep the system secure, later on. Secure signatures on various software components, before giving way to other
boot works by authorizing only select executables to be run. Authorized technologies to keep the system secure, later on. Secure boot works by
executables are signed using public cryptography, and the keys used to verify authorizing only select executables to be run. Authorized executables are
those signatures are stored securely in UEFI "databases". 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) [^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 shuts down all UEFI Boot Services, before dropping its privileges and then
doing "Linux stuff" (like starting the userland part of the operating system). 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 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 past that point is able to tamper with the UEFI sensitive information,
variables, which contains sensitive data. including UEFI variables, which contains sensitive data.
Secure Boot aims at securing "everything" that is executed prior to that 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 privilege drop. Once the privileges are drop, Secure Boot is done and it is up
to ensure that only authorized software is run. Most Linux distros do not even to the operating system to extend that integrity/authenticity protection and
try to do it, although there are notable exceptions (Chrome OS, Android, just ensure that only authorized software is run. Most Linux distros do not even try
to name a few). If we run one of the distros that do not leverage technologies 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 such as dm-verity, fs-verity (with signatures) or Linux IMA (Integrity
Management Architecture), then Secure Boot is strictly insufficient to protect Management Architecture), then Secure Boot protected the boot integrity for
user data integrity or even system integrity in general. 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 Nevertheless, ANSSI, the French Infosec Agency recommends in its GNU/Linux
security guide[^linuxguide] to enable Secure Boot (R3) for all systems security guide[^linuxguide] to enable Secure Boot (R3) for all systems
requiring medium security level (level 2 out of 4, 1 being the minimal 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 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 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 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. 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) [^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 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. 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 ## Signature verification and default public keys
Secure boot relies on a set of public keys to verify authorized software Secure boot relies on a set of public keys to verify authorized software
authenticity. By default, most vendors ship Microsoft public keys. These keys authenticity. By default, most vendors ship Microsoft public keys. These keys
sign all Microsoft Windows version, of course, but to avoid a monopoly, other 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 executables were signed. The list is ought to be short (and unfortunately, it
and authorized software, the attack surface grows and the probability of a is not) because with each signature and authorized software, the attack surface
vulnerability raises. Several were already found in the recent past (e.g. grows and the probability of a vulnerability raises. Several were already found
CVE-2020-10713[^CVE-2020-10713], CVE-2022-34301[^CVE-2022-34301], in the recent past (e.g. CVE-2020-10713[^CVE-2020-10713],
CVE-2022-34302[^CVE-2022-34302], CVE-2022-34303[^CVE-2022-34303]. 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, For this reason, many software still require that Secure Boot be deactivated,
including firmware updates by some manufacturers, including including firmware updates by some manufacturers, including
Intel[^intelUpgrade] or Lenovo[^lenovoUpgrade]. 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 require for each and every single version to be signed individually by
Microsoft. Instead, a binary called Shim[^shim] was developed. This rather Microsoft. Instead, a binary called Shim[^shim] was developed. This rather
small, auditable, innocuous-looking program is signed by Microsoft. Its role is small, auditable, innocuous-looking program is signed by Microsoft. Its role is
basically that of a trojan horse. Indeed, its only purpose is to basically that of a trojan horse (or a security pivot, depending on the way you
cryptographically verify the authenticity of any executable. However, this look at it). Indeed, its only purpose is to cryptographically verify the
time, the list of public keys used to verify these executables is not directly authenticity of any executable. However, this time, the list of public keys
under the control of Microsoft. These public keys are either built in Shim used to verify these executables is not directly under the control of
itself or stored in a EFI variable serving as a database. 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 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 "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. untrusted code was ultimately run within the UEFI privileged mode.
Hence, thanks to shim, just about any signed or unsigned, trusted or untrusted 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 And this conclusion signs (pun intended) the second incoherence in ANSSI
recommendations. Indeed, they recommend replacing Microsoft keys by our own set 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 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 sense of security of running Secure Boot while exposing themselves to attackers
capable of proving "presence". capable of proving "presence".
For what it is worth, shim does provide a way secure all operations, including 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 MOK (Machine Owner Keys) Manager[^mokpass]. However, the feature is mostly
unused because no Linux distro enables it (it requires user interaction during unused because no Linux distro enables it (it requires user interaction during
the boot procedure) and system administrators often mistake the MOK Manager 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 `--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 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 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 Secure Boot. ANSSI also failed to recommend that. Most interestingly, setting a
MOK Manager password is recommended even for Windows administrators that have MOK Manager password is recommended even for Windows administrators that have
no intention of ever running Linux, because MOK Manager is one of 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. [^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. 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 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 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 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 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 Unified Kernel Image is authentic. That kernel must then verify the operating
system to ensure that only verified software is run. This requires system to ensure that only verified software is run. This requires
cryptographic verification of every single executable (binaries, scripts and 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: operating system. This can be achieved if we, at minimum, do the following:
* use a read-only filesystem for our partitions containing executable code, * 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? solution?
Well, to the best of the author knowledge, there is one: using a TPM. Using a 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 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 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 user data if and only if the cryptographically verified right version of UEFI