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, 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
|
||||||
|
|
Loading…
Reference in a new issue