Add article about secure boot
All checks were successful
continuous-integration/drone/push Build is passing
All checks were successful
continuous-integration/drone/push Build is passing
This commit is contained in:
parent
9347f7cf9f
commit
614ee6abff
1 changed files with 245 additions and 0 deletions
245
posts/secure_boot.md
Normal file
245
posts/secure_boot.md
Normal file
|
@ -0,0 +1,245 @@
|
||||||
|
---
|
||||||
|
title: "Secure Boot: this is not the protection we are looking for"
|
||||||
|
slug: "secure-boot-not"
|
||||||
|
description: "An article trying to prove that Secure Boot is often failing to provide any kind of meaningful protection, mostly because of the number of stuff that can go wrong."
|
||||||
|
date: 2022-11-30T00:00:00+00:00
|
||||||
|
type: posts
|
||||||
|
draft: false
|
||||||
|
categories:
|
||||||
|
- security
|
||||||
|
tags:
|
||||||
|
- tpm
|
||||||
|
- secure boot
|
||||||
|
- sysadmin
|
||||||
|
- linux
|
||||||
|
lang: en
|
||||||
|
---
|
||||||
|
|
||||||
|
Before being a technology, secure boot is an English expression. But, what does
|
||||||
|
it mean to boot securely? What are we trying to achieve and to protect?
|
||||||
|
|
||||||
|
First, we want user data protection from a secure system. User data is really
|
||||||
|
any piece of data a user might display or edit, including the obvious office
|
||||||
|
documents but also configuration files, databases, downloaded files, log files,
|
||||||
|
user commands, etc. These data must be protected in confidentiality. For this,
|
||||||
|
the system must ensure that these data are protected at rest, when the system
|
||||||
|
is shutdown. However, this is not enough, since access from unauthorized
|
||||||
|
software could leak the data, for instance over the network or by copying it on
|
||||||
|
an external removable drive. Hence, a secure system should only run authorized
|
||||||
|
software.
|
||||||
|
|
||||||
|
## Secure Boot, the technology
|
||||||
|
|
||||||
|
Secure Boot 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".
|
||||||
|
|
||||||
|
UEFI is the successor of the now nearly defunct BIOS. It is an interface
|
||||||
|
between the operating system and the manufacturer platform, a firmware, that
|
||||||
|
runs very early on most modern systems. The platform is responsible of, among
|
||||||
|
many other things, executing the bootloader (for instance, Grub or
|
||||||
|
systemd-boot). Generally, the bootloader then starts an operating system. In
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
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
|
||||||
|
operating system integrity.
|
||||||
|
|
||||||
|
[^linuxguide]: no English version yet. French version is https://www.ssi.gouv.fr/uploads/2019/02/fr_np_linux_configuration-v2.0.pdf
|
||||||
|
|
||||||
|
[^R6]: "Protect command line parameters and initramfs with Secure Boot"
|
||||||
|
|
||||||
|
Interestingly, a poll on the fediverse[^poll] revealed that 89% of the
|
||||||
|
respondants thinks that Secure Boot is necessary for intermediate security
|
||||||
|
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]: 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].
|
||||||
|
|
||||||
|
[^CVE-2020-10713]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713
|
||||||
|
|
||||||
|
|
||||||
|
[^CVE-2022-34301]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34301
|
||||||
|
|
||||||
|
[^CVE-2022-34302]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34302
|
||||||
|
|
||||||
|
[^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]: https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/UEFI-Flash-BIOS-Update-Instructions.pdf
|
||||||
|
|
||||||
|
[^lenovoUpgrade]: 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
|
||||||
|
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.
|
||||||
|
|
||||||
|
[^shim]: 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
|
||||||
|
for remote console access. Once a new public key enrolled, all executables
|
||||||
|
verifiable by that key can run in the UEFI privileged mode, and for instance
|
||||||
|
create a persistent backdoor in the bootstrapping code of the machine.
|
||||||
|
|
||||||
|
If this was not enough, users able to prove "presence" can also disable shim
|
||||||
|
verification of authorized software. This means that shim can be used to have
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
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
|
||||||
|
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
|
||||||
|
password, which secures the access to the MOK Manager as a whole, with the
|
||||||
|
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
|
||||||
|
no intention of ever running Linux, because MOK Manager is one of
|
||||||
|
the executables signed by the Microsoft keys.
|
||||||
|
|
||||||
|
[^mokpass]: The command is `mokutil --password`. Please consider using it.
|
||||||
|
|
||||||
|
## Using our own set of Secure Boot keys (PK and KEK)
|
||||||
|
|
||||||
|
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
|
||||||
|
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
|
||||||
|
Images instead of relying on Shim. If we run our own kernel, as recommended by
|
||||||
|
ANSSI (R15 to R27), then we need to handle the private key and the signature
|
||||||
|
process ourselves.
|
||||||
|
|
||||||
|
With a Unified Kernel Image signed and verified by Secure Boot, we are now sure
|
||||||
|
that only our code is executed, and we can safely ask for the user passphrase
|
||||||
|
to unlock the LUKS container. This way, user data is protected at rest, and
|
||||||
|
accessed only by authorized software. Cool. Except it is not.
|
||||||
|
|
||||||
|
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
|
||||||
|
operating system. This can be achieved if we, at minimum, do the following:
|
||||||
|
|
||||||
|
* use a read-only filesystem for our partitions containing executable code,
|
||||||
|
enforced using dm-verity, or fs-verity with file signature or Linux IMA, or
|
||||||
|
something similar;
|
||||||
|
|
||||||
|
* use the noexec mount option on data partitions;
|
||||||
|
|
||||||
|
* modify command interpreters to ensure they do not execute scripts from mount
|
||||||
|
points with noexec nor from STDIN;
|
||||||
|
|
||||||
|
* prevent writable memory from ever getting executed, by patching the kernel;
|
||||||
|
|
||||||
|
* ensure that no executable configuration file is writable.
|
||||||
|
|
||||||
|
Welcome in Wonderland, Alice.
|
||||||
|
|
||||||
|
Ok, but let's assume we go down that rabbit hole... are we secure yet?
|
||||||
|
|
||||||
|
No. No, we are not.
|
||||||
|
|
||||||
|
Because there is no way of telling if our Secure Boot implementation is tainted
|
||||||
|
by an attacker or not. Indeed, someone could have flashed our UEFI firmware
|
||||||
|
before we enabled Secure Boot. Or they could have disabled it, flashed and
|
||||||
|
reenabled it, if we did not have a UEFI administration password at some point.
|
||||||
|
Or they could have abused shim when we were using the default keys to flash
|
||||||
|
UEFI.
|
||||||
|
|
||||||
|
## Nirvana Fallacy much?
|
||||||
|
|
||||||
|
So, if Secure Boot is not a good answer, especially against an attacker capable
|
||||||
|
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
|
||||||
|
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
|
||||||
|
firmware, Unified Kernel Image and operating system image have been booted.
|
||||||
|
This is based on PCR policies, that ties the sealed passphrase to a particular
|
||||||
|
signed set of executables measured by the TPM. This approach ensures user data
|
||||||
|
confidentiality at rest and the authenticity of the executables that are on
|
||||||
|
disk during boot. Of course, it does not prevent executing writable memory, nor
|
||||||
|
user data flagged as executable, including scripts, and executable
|
||||||
|
configuration files. And of course, having a signed set of policies means
|
||||||
|
handling a private key and designing a signature procedure. There is no free
|
||||||
|
lunch. Sorry.
|
||||||
|
|
||||||
|
However, using a TPM offers the same security level against attackers with
|
||||||
|
physical access, attackers with remote access through a BMC, and a rogue system
|
||||||
|
administrator, and that is something that Secure Boot cannot brag about.
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
So there you have it: recommending idly Secure Boot for all systems requiring
|
||||||
|
intermediate security level accomplishes nothing, except maybe giving more work
|
||||||
|
to system administrators that are recompiling their kernel, while offering
|
||||||
|
exactly no measurable security against many threats if UEFI Administrative
|
||||||
|
password and MOK Manager passwords are not set. This is especially true for
|
||||||
|
laptop systems where physical access cannot be prevented for obvious reasons.
|
||||||
|
For servers in colocation, the risk of physical access is not null. And finally
|
||||||
|
for many servers, the risk of a rogue employee somewhere in the supply chain,
|
||||||
|
or the maintenance chain cannot be easily ruled out.
|
Loading…
Reference in a new issue