Fix links and add UEFI spec link
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
614ee6abff
commit
c4a5bf28b0
1 changed files with 20 additions and 16 deletions
|
@ -1,10 +1,10 @@
|
||||||
---
|
---
|
||||||
title: "Secure Boot: this is not the protection we are looking for"
|
title: "Secure Boot: this is not the protection we are looking for"
|
||||||
slug: "secure-boot-not"
|
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."
|
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
|
date: 2022-11-30T00:00:00+00:00
|
||||||
type: posts
|
type: posts
|
||||||
draft: false
|
draft: false
|
||||||
categories:
|
categories:
|
||||||
- security
|
- security
|
||||||
tags:
|
tags:
|
||||||
|
@ -12,7 +12,7 @@ tags:
|
||||||
- secure boot
|
- secure boot
|
||||||
- sysadmin
|
- sysadmin
|
||||||
- linux
|
- linux
|
||||||
lang: en
|
lang: en
|
||||||
---
|
---
|
||||||
|
|
||||||
Before being a technology, secure boot is an English expression. But, what does
|
Before being a technology, secure boot is an English expression. But, what does
|
||||||
|
@ -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.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue