Fix links and add UEFI spec link

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.
+