fmaury/Broken-by-Design
1
0
Fork 0
Code Pull requests Releases Activity Actions

Fix links and add UEFI spec link
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse source
This commit is contained in:
Florian Maury 2022-11-30 08:35:31 +01:00
parent 614ee6abff
commit c4a5bf28b0
No known key found for this signature in database
1 changed files with 20 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
posts/secure_boot.md
View file

@ -30,13 +30,15 @@ software.
## Secure Boot, the technology ## 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, 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 giving way to other technologies to keep the system secure, later on. Secure
boot works by authorizing only select executables to be run. Authorized boot works by authorizing only select executables to be run. Authorized
executables are signed using public cryptography, and the keys used to verify executables are signed using public cryptography, and the keys used to verify
those signatures are stored securely in UEFI "databases". 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 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 between the operating system and the manufacturer platform, a firmware, that
runs very early on most modern systems. The platform is responsible of, among 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 done about using one of the aforementioned integrity features to ensure
operating system integrity. 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" [^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 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]: 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
@ -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-2020-10713[^CVE-2020-10713], CVE-2022-34301[^CVE-2022-34301],
CVE-2022-34302[^CVE-2022-34302], CVE-2022-34303[^CVE-2022-34303]. 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]: [Lenovo flash BIOS with UEFI tool](https://support.lenovo.com/us/en/solutions/ht118103-flash-bios-with-uefi-tool-ideacentre-stick-300)
[^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 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
@ -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 under the control of Microsoft. These public keys are either built in Shim
itself or stored in a EFI variable serving as a database. 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 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
@ -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 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, for many servers, the risk of a rogue employee somewhere in the supply chain,
or the maintenance chain cannot be easily ruled out. or the maintenance chain cannot be easily ruled out.