diff --git a/posts/secure_boot.md b/posts/secure_boot.md index 5ed4c20..1e87769 100644 --- a/posts/secure_boot.md +++ b/posts/secure_boot.md @@ -1,10 +1,10 @@ ---- +--- 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 +type: posts +draft: false categories: - security tags: @@ -12,7 +12,7 @@ tags: - secure boot - sysadmin - linux -lang: en +lang: en --- Before being a technology, secure boot is an English expression. But, what does @@ -30,13 +30,15 @@ software. ## Secure Boot, the technology -Secure Boot is an attempt at ensuring that only authorized software is run on a +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". +[^spec]: [UEFI Specifications](https://uefi.org/specs/access) + 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 @@ -68,7 +70,7 @@ 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 +[^linuxguide]: no English version yet. [French version](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" @@ -79,7 +81,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]: https://infosec.exchange/@x_cli/109348532363333158 +[^poll]: [Mastodon poll](https://infosec.exchange/@x_cli/109348532363333158) ## Signature verification and default public keys @@ -92,20 +94,21 @@ 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-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]: 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]: 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]: 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]. -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]: 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 +[^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 @@ -117,7 +120,7 @@ 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 +[^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 @@ -243,3 +246,4 @@ 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. +