improve secure boot article after review #3
1 changed files with 19 additions and 19 deletions
|
@ -66,11 +66,11 @@ 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)
|
||||
|
@ -84,7 +84,7 @@ 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
|
||||
|
||||
|
@ -98,21 +98,21 @@ 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
|
||||
require for each and every single version to be signed individually by
|
||||
|
@ -125,7 +125,7 @@ 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
|
||||
|
@ -139,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
|
||||
|
@ -158,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.
|
||||
|
||||
|
@ -169,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
|
||||
|
@ -186,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,
|
||||
|
@ -222,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