Go offline with the Player FM app!
Episode 235
Manage episode 435684709 series 2423058
Overview
A recent Microsoft Windows update breaks Linux dual-boot - or does it? This week we look into reports of the recent Windows patch-Tuesday update breaking dual-boot, including a deep-dive into the technical details of Secure Boot, SBAT, grub, shim and more, plus we look at a vulnerability in GNOME Shell and the handling of captive portals as well.
This week in Ubuntu Security Updates
135 unique CVEs addressed
[USN-6960-1] RMagick vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
[USN-6951-2] Linux kernel (Azure) vulnerabilities
- 83 CVEs addressed in Focal (20.04 LTS)
- CVE-2022-48674
- CVE-2024-39471
- CVE-2024-39292
- CVE-2024-36270
- CVE-2024-36904
- CVE-2024-38618
- CVE-2024-36014
- CVE-2024-36941
- CVE-2024-38637
- CVE-2024-38613
- CVE-2024-36286
- CVE-2024-36902
- CVE-2024-38599
- CVE-2024-39301
- CVE-2024-39475
- CVE-2024-36954
- CVE-2024-33621
- CVE-2024-38552
- CVE-2024-36950
- CVE-2024-38582
- CVE-2024-36015
- CVE-2023-52434
- CVE-2024-38659
- CVE-2024-36940
- CVE-2024-38607
- CVE-2024-39480
- CVE-2024-38583
- CVE-2023-52882
- CVE-2024-39467
- CVE-2024-39489
- CVE-2024-38601
- CVE-2024-27019
- CVE-2023-52752
- CVE-2024-36960
- CVE-2024-38549
- CVE-2024-38567
- CVE-2024-38587
- CVE-2024-38635
- CVE-2024-38598
- CVE-2024-38612
- CVE-2024-38579
- CVE-2024-27401
- CVE-2024-36946
- CVE-2024-36017
- CVE-2022-48772
- CVE-2024-36905
- CVE-2024-35947
- CVE-2024-38381
- CVE-2024-38565
- CVE-2024-38589
- CVE-2024-36939
- CVE-2024-38661
- CVE-2024-39488
- CVE-2024-36883
- CVE-2024-38621
- CVE-2024-37353
- CVE-2024-38780
- CVE-2024-36964
- CVE-2024-38627
- CVE-2024-36971
- CVE-2024-38615
- CVE-2024-38559
- CVE-2024-31076
- CVE-2024-26886
- CVE-2024-39493
- CVE-2024-27398
- CVE-2024-36886
- CVE-2024-38633
- CVE-2024-36959
- CVE-2024-38634
- CVE-2024-38560
- CVE-2024-38558
- CVE-2023-52585
- CVE-2024-37356
- CVE-2024-35976
- CVE-2024-36919
- CVE-2024-36933
- CVE-2024-38596
- CVE-2024-39276
- CVE-2024-27399
- CVE-2024-38600
- CVE-2024-38578
- CVE-2024-36934
[USN-6961-1] BusyBox vulnerabilities
- 4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6962-1] LibreOffice vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6963-1] GNOME Shell vulnerability (01:03)
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
- Captive portal detection would spawn an embedded webkit browser automatically to allow user to login etc
- But the page the user gets directed to is controlled by the attacker and can contain arbitrary javascript etc
- Upstream bug report claimed could then get a reverse shell etc - not clear this is the case since would still be constrained by the webkitgtk browser so would also need a sandbox escape etc.
- This update then includes a change to both not automatically open the captive portal page (instead it will show a notification and the user needs to click that) BUT to also disable the use of the webkitgtk-based embedded browser and instead use the users regular browser
[USN-6909-3] Bind vulnerabilities
- 2 CVEs addressed in Xenial ESM (16.04 ESM)
[USN-6964-1] ORC vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6837-2] Rack vulnerabilitie
- 3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS)
[USN-6966-1] Firefox vulnerabilities
- 13 CVEs addressed in Focal (20.04 LTS)
[USN-6966-2] Firefox regressions
- 13 CVEs addressed in Focal (20.04 LTS)
[USN-6951-3] Linux kernel (Azure) vulnerabilities
- 83 CVEs addressed in Bionic ESM (18.04 ESM)
- CVE-2022-48674
- CVE-2024-39471
- CVE-2024-39292
- CVE-2024-36270
- CVE-2024-36904
- CVE-2024-38618
- CVE-2024-36014
- CVE-2024-36941
- CVE-2024-38637
- CVE-2024-38613
- CVE-2024-36286
- CVE-2024-36902
- CVE-2024-38599
- CVE-2024-39301
- CVE-2024-39475
- CVE-2024-36954
- CVE-2024-33621
- CVE-2024-38552
- CVE-2024-36950
- CVE-2024-38582
- CVE-2024-36015
- CVE-2023-52434
- CVE-2024-38659
- CVE-2024-36940
- CVE-2024-38607
- CVE-2024-39480
- CVE-2024-38583
- CVE-2023-52882
- CVE-2024-39467
- CVE-2024-39489
- CVE-2024-38601
- CVE-2024-27019
- CVE-2023-52752
- CVE-2024-36960
- CVE-2024-38549
- CVE-2024-38567
- CVE-2024-38587
- CVE-2024-38635
- CVE-2024-38598
- CVE-2024-38612
- CVE-2024-38579
- CVE-2024-27401
- CVE-2024-36946
- CVE-2024-36017
- CVE-2022-48772
- CVE-2024-36905
- CVE-2024-35947
- CVE-2024-38381
- CVE-2024-38565
- CVE-2024-38589
- CVE-2024-36939
- CVE-2024-38661
- CVE-2024-39488
- CVE-2024-36883
- CVE-2024-38621
- CVE-2024-37353
- CVE-2024-38780
- CVE-2024-36964
- CVE-2024-38627
- CVE-2024-36971
- CVE-2024-38615
- CVE-2024-38559
- CVE-2024-31076
- CVE-2024-26886
- CVE-2024-39493
- CVE-2024-27398
- CVE-2024-36886
- CVE-2024-38633
- CVE-2024-36959
- CVE-2024-38634
- CVE-2024-38560
- CVE-2024-38558
- CVE-2023-52585
- CVE-2024-37356
- CVE-2024-35976
- CVE-2024-36919
- CVE-2024-36933
- CVE-2024-38596
- CVE-2024-39276
- CVE-2024-27399
- CVE-2024-38600
- CVE-2024-38578
- CVE-2024-36934
[USN-6968-1] PostgreSQL vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6967-1] Intel Microcode vulnerabilities
- 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[LSN-0106-1] Linux kernel vulnerability
- 3 CVEs addressed in
[USN-6969-1] Cacti vulnerabilities
- 10 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6970-1] exfatprogs vulnerability
- 1 CVEs addressed in Jammy (22.04 LTS)
[USN-6944-2] curl vulnerability
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
[USN-6965-1] Vim vulnerabilities
- 5 CVEs addressed in Trusty ESM (14.04 ESM)
Goings on in Ubuntu Security Community
Reports of dual-boot Linux/Windows machines failing to boot (04:30)
- https://arstechnica.com/security/2024/08/a-patch-microsoft-spent-2-years-preparing-is-making-a-mess-for-some-linux-users/
- https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2022-2601
- https://discourse.ubuntu.com/t/sbat-self-check-failed-mitigating-the-impact-of-shim-15-7-revocation-on-the-ubuntu-boot-process-for-devices-running-windows/47378
- Microsoft released an update for Windows on 13th August 2024 - revoking old versions of grub that were susceptible to CVE-2022-2601
- How do you revoke grub?
- Secure Boot relies on each component in the boot chain verifying that the next component is signed with a valid signature before it is then loaded
- UEFI BIOS validates shim
- shim validates grub
- grub validates kernel
- kernel validates kernel modules etc
- UEFI specification has effectively a CRL - list of hashes of binaries which shouldn’t be trusted
- BUT there is only limited space in the UEFI storage - after the original BootHole vulnerabilities revoked a huge number of grub binaries from many different distros, some devices failed to boot as the NVRAM was too full
- Microsoft and Red Hat and other maintainers of shim decided on a new scheme, called SBAT - Secure Boot Advanced Targeting
- maintains a generation number for each component in the boot chain
- when say shim or grub gets updated to fix a bunch more security vulnerabilities, upstream bumps the generation number
- shim/grub then embeds the generation number within itself
- Signed UEFI variable then lists which generation numbers are acceptable
- shim checks the generation number of a binary (grub/fwupd etc) against this list and if it is too old refuses to load it
- Secure Boot relies on each component in the boot chain verifying that the next component is signed with a valid signature before it is then loaded
- In Ubuntu this was patched back in Jan 2023 and was documented on the Ubuntu Discourse - in this case we updated shim to a newer version which itself revoked an older grub,
grub,1
- Now Microsoft’s update revokes
grub,2
, ie sets the minimum generation number for grub to3
- You can inspect the SBAT policy by either directly reading the associated EFI variable or using
mokutil --list-sbat-revocations
cat /sys/firmware/efi/efivars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23 mokutil --list-sbat-revocations
sbat,1,2023012900 shim,2 grub,3 grub.debian,4
objdump -j .sbat -s /boot/efi/EFI/ubuntu/grubx64.efi | xxd -r
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.12,https://www.gnu.org/software/grub/ grub.ubuntu,2,Ubuntu,grub2,2.12-5ubuntu4,https://www.ubuntu.com/ grub.peimage,2,Canonical,grub2,2.12-5ubuntu4,https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/secure-boot/efi-use-peimage-shim.patch
rm -rf grub2-signed mkdir grub2-signed pushd grub2-signed >/dev/null || exit for rel in focal jammy noble; do mkdir $rel pushd $rel >/dev/null || exit pull-lp-debs grub2-signed $rel-security 1>/dev/null 2>/dev/null || pull-lp-debs grub2-signed $rel-release 1>/dev/null 2>/dev/null dpkg-deb -x grub-efi-amd64-signed*.deb grub2-signed echo $rel echo ----- find . -name grubx64.efi.signed -exec objdump -j .sbat -s {} \; | tail -n +5 | xxd -r popd >/dev/null || exit done popd >/dev/null
focal ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/ grub.ubuntu,1,Ubuntu,grub2,2.06-2ubuntu14.4,https://www.ubuntu.com/ jammy ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/ grub.ubuntu,1,Ubuntu,grub2,2.06-2ubuntu14.4,https://www.ubuntu.com/ noble ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.12,https://www.gnu.org/software/grub/ grub.ubuntu,2,Ubuntu,grub2,2.12-1ubuntu7,https://www.ubuntu.com/ grub.peimage,2,Canonical,grub2,2.12-1ubuntu7,https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/secure-boot/efi-use-peimage-shim.patch
- So if all the current LTS releases have a grub with a generation number higher than this, why are so many machines failing to boot?
- It is not just grub that is the issue - shim itself also got revoked in the same update https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2023-40547 - so shim 15.8 (ie. 4th SBAT generation of shim) is now required
- Unfortunately, the related updates for this shim in Ubuntu are still in the process of being released - https://bugs.launchpad.net/ubuntu/+source/shim/+bug/2051151
rm -rf shim-signed mkdir shim-signed pushd shim-signed >/dev/null || exit for rel in focal jammy noble; do mkdir $rel pushd $rel >/dev/null || exit pull-lp-debs shim-signed $rel-security 1>/dev/null 2>/dev/null || pull-lp-debs shim-signed $rel-release 1>/dev/null 2>/dev/null dpkg-deb -x shim-signed*.deb shim-signed echo $rel echo ----- find . -name shimx64.efi.signed.latest -exec objdump -j .sbat -s {} \; | tail -n +5 | xxd -r popd >/dev/null || exit done popd >/dev/null
focal ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.7-0ubuntu1,https://www.ubuntu.com/ jammy ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.7-0ubuntu1,https://www.ubuntu.com/ noble ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.8-0ubuntu1,https://www.ubuntu.com/
only noble has a new-enough shim in the security/release pocket - both focal and jammy have the older one - but the new 4th generation shim is currently undergoing testing in the -proposed pocket and will be released next week
until then, if affected, need to disable secure boot in BIOS then can either wait until the new shim is released OR just reboot twice in this mode and shim will automoatically reset the SBAT policy to the previous version, allowing the older shim to still be used
then can re-enable Secure Boot in BIOS
Once new shim is released it will reinstall the new SBAT policy to revoke its older version
One other thing, this also means the old ISOs won’t boot either
- 24.04.1 will be released on 29th August
- upcoming 22.04.5 release will also have this new shim too
- no further ISO spins planned for 20.04 - so if you really want to install this release on new hardware, would need to disable secure boot first, do the install, then install updates to get the new shim, and re-enable secure boot
Get in contact
240 episodes
Manage episode 435684709 series 2423058
Overview
A recent Microsoft Windows update breaks Linux dual-boot - or does it? This week we look into reports of the recent Windows patch-Tuesday update breaking dual-boot, including a deep-dive into the technical details of Secure Boot, SBAT, grub, shim and more, plus we look at a vulnerability in GNOME Shell and the handling of captive portals as well.
This week in Ubuntu Security Updates
135 unique CVEs addressed
[USN-6960-1] RMagick vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
[USN-6951-2] Linux kernel (Azure) vulnerabilities
- 83 CVEs addressed in Focal (20.04 LTS)
- CVE-2022-48674
- CVE-2024-39471
- CVE-2024-39292
- CVE-2024-36270
- CVE-2024-36904
- CVE-2024-38618
- CVE-2024-36014
- CVE-2024-36941
- CVE-2024-38637
- CVE-2024-38613
- CVE-2024-36286
- CVE-2024-36902
- CVE-2024-38599
- CVE-2024-39301
- CVE-2024-39475
- CVE-2024-36954
- CVE-2024-33621
- CVE-2024-38552
- CVE-2024-36950
- CVE-2024-38582
- CVE-2024-36015
- CVE-2023-52434
- CVE-2024-38659
- CVE-2024-36940
- CVE-2024-38607
- CVE-2024-39480
- CVE-2024-38583
- CVE-2023-52882
- CVE-2024-39467
- CVE-2024-39489
- CVE-2024-38601
- CVE-2024-27019
- CVE-2023-52752
- CVE-2024-36960
- CVE-2024-38549
- CVE-2024-38567
- CVE-2024-38587
- CVE-2024-38635
- CVE-2024-38598
- CVE-2024-38612
- CVE-2024-38579
- CVE-2024-27401
- CVE-2024-36946
- CVE-2024-36017
- CVE-2022-48772
- CVE-2024-36905
- CVE-2024-35947
- CVE-2024-38381
- CVE-2024-38565
- CVE-2024-38589
- CVE-2024-36939
- CVE-2024-38661
- CVE-2024-39488
- CVE-2024-36883
- CVE-2024-38621
- CVE-2024-37353
- CVE-2024-38780
- CVE-2024-36964
- CVE-2024-38627
- CVE-2024-36971
- CVE-2024-38615
- CVE-2024-38559
- CVE-2024-31076
- CVE-2024-26886
- CVE-2024-39493
- CVE-2024-27398
- CVE-2024-36886
- CVE-2024-38633
- CVE-2024-36959
- CVE-2024-38634
- CVE-2024-38560
- CVE-2024-38558
- CVE-2023-52585
- CVE-2024-37356
- CVE-2024-35976
- CVE-2024-36919
- CVE-2024-36933
- CVE-2024-38596
- CVE-2024-39276
- CVE-2024-27399
- CVE-2024-38600
- CVE-2024-38578
- CVE-2024-36934
[USN-6961-1] BusyBox vulnerabilities
- 4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6962-1] LibreOffice vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6963-1] GNOME Shell vulnerability (01:03)
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
- Captive portal detection would spawn an embedded webkit browser automatically to allow user to login etc
- But the page the user gets directed to is controlled by the attacker and can contain arbitrary javascript etc
- Upstream bug report claimed could then get a reverse shell etc - not clear this is the case since would still be constrained by the webkitgtk browser so would also need a sandbox escape etc.
- This update then includes a change to both not automatically open the captive portal page (instead it will show a notification and the user needs to click that) BUT to also disable the use of the webkitgtk-based embedded browser and instead use the users regular browser
[USN-6909-3] Bind vulnerabilities
- 2 CVEs addressed in Xenial ESM (16.04 ESM)
[USN-6964-1] ORC vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6837-2] Rack vulnerabilitie
- 3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS)
[USN-6966-1] Firefox vulnerabilities
- 13 CVEs addressed in Focal (20.04 LTS)
[USN-6966-2] Firefox regressions
- 13 CVEs addressed in Focal (20.04 LTS)
[USN-6951-3] Linux kernel (Azure) vulnerabilities
- 83 CVEs addressed in Bionic ESM (18.04 ESM)
- CVE-2022-48674
- CVE-2024-39471
- CVE-2024-39292
- CVE-2024-36270
- CVE-2024-36904
- CVE-2024-38618
- CVE-2024-36014
- CVE-2024-36941
- CVE-2024-38637
- CVE-2024-38613
- CVE-2024-36286
- CVE-2024-36902
- CVE-2024-38599
- CVE-2024-39301
- CVE-2024-39475
- CVE-2024-36954
- CVE-2024-33621
- CVE-2024-38552
- CVE-2024-36950
- CVE-2024-38582
- CVE-2024-36015
- CVE-2023-52434
- CVE-2024-38659
- CVE-2024-36940
- CVE-2024-38607
- CVE-2024-39480
- CVE-2024-38583
- CVE-2023-52882
- CVE-2024-39467
- CVE-2024-39489
- CVE-2024-38601
- CVE-2024-27019
- CVE-2023-52752
- CVE-2024-36960
- CVE-2024-38549
- CVE-2024-38567
- CVE-2024-38587
- CVE-2024-38635
- CVE-2024-38598
- CVE-2024-38612
- CVE-2024-38579
- CVE-2024-27401
- CVE-2024-36946
- CVE-2024-36017
- CVE-2022-48772
- CVE-2024-36905
- CVE-2024-35947
- CVE-2024-38381
- CVE-2024-38565
- CVE-2024-38589
- CVE-2024-36939
- CVE-2024-38661
- CVE-2024-39488
- CVE-2024-36883
- CVE-2024-38621
- CVE-2024-37353
- CVE-2024-38780
- CVE-2024-36964
- CVE-2024-38627
- CVE-2024-36971
- CVE-2024-38615
- CVE-2024-38559
- CVE-2024-31076
- CVE-2024-26886
- CVE-2024-39493
- CVE-2024-27398
- CVE-2024-36886
- CVE-2024-38633
- CVE-2024-36959
- CVE-2024-38634
- CVE-2024-38560
- CVE-2024-38558
- CVE-2023-52585
- CVE-2024-37356
- CVE-2024-35976
- CVE-2024-36919
- CVE-2024-36933
- CVE-2024-38596
- CVE-2024-39276
- CVE-2024-27399
- CVE-2024-38600
- CVE-2024-38578
- CVE-2024-36934
[USN-6968-1] PostgreSQL vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6967-1] Intel Microcode vulnerabilities
- 5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[LSN-0106-1] Linux kernel vulnerability
- 3 CVEs addressed in
[USN-6969-1] Cacti vulnerabilities
- 10 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)
[USN-6970-1] exfatprogs vulnerability
- 1 CVEs addressed in Jammy (22.04 LTS)
[USN-6944-2] curl vulnerability
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM)
[USN-6965-1] Vim vulnerabilities
- 5 CVEs addressed in Trusty ESM (14.04 ESM)
Goings on in Ubuntu Security Community
Reports of dual-boot Linux/Windows machines failing to boot (04:30)
- https://arstechnica.com/security/2024/08/a-patch-microsoft-spent-2-years-preparing-is-making-a-mess-for-some-linux-users/
- https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2022-2601
- https://discourse.ubuntu.com/t/sbat-self-check-failed-mitigating-the-impact-of-shim-15-7-revocation-on-the-ubuntu-boot-process-for-devices-running-windows/47378
- Microsoft released an update for Windows on 13th August 2024 - revoking old versions of grub that were susceptible to CVE-2022-2601
- How do you revoke grub?
- Secure Boot relies on each component in the boot chain verifying that the next component is signed with a valid signature before it is then loaded
- UEFI BIOS validates shim
- shim validates grub
- grub validates kernel
- kernel validates kernel modules etc
- UEFI specification has effectively a CRL - list of hashes of binaries which shouldn’t be trusted
- BUT there is only limited space in the UEFI storage - after the original BootHole vulnerabilities revoked a huge number of grub binaries from many different distros, some devices failed to boot as the NVRAM was too full
- Microsoft and Red Hat and other maintainers of shim decided on a new scheme, called SBAT - Secure Boot Advanced Targeting
- maintains a generation number for each component in the boot chain
- when say shim or grub gets updated to fix a bunch more security vulnerabilities, upstream bumps the generation number
- shim/grub then embeds the generation number within itself
- Signed UEFI variable then lists which generation numbers are acceptable
- shim checks the generation number of a binary (grub/fwupd etc) against this list and if it is too old refuses to load it
- Secure Boot relies on each component in the boot chain verifying that the next component is signed with a valid signature before it is then loaded
- In Ubuntu this was patched back in Jan 2023 and was documented on the Ubuntu Discourse - in this case we updated shim to a newer version which itself revoked an older grub,
grub,1
- Now Microsoft’s update revokes
grub,2
, ie sets the minimum generation number for grub to3
- You can inspect the SBAT policy by either directly reading the associated EFI variable or using
mokutil --list-sbat-revocations
cat /sys/firmware/efi/efivars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23 mokutil --list-sbat-revocations
sbat,1,2023012900 shim,2 grub,3 grub.debian,4
objdump -j .sbat -s /boot/efi/EFI/ubuntu/grubx64.efi | xxd -r
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.12,https://www.gnu.org/software/grub/ grub.ubuntu,2,Ubuntu,grub2,2.12-5ubuntu4,https://www.ubuntu.com/ grub.peimage,2,Canonical,grub2,2.12-5ubuntu4,https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/secure-boot/efi-use-peimage-shim.patch
rm -rf grub2-signed mkdir grub2-signed pushd grub2-signed >/dev/null || exit for rel in focal jammy noble; do mkdir $rel pushd $rel >/dev/null || exit pull-lp-debs grub2-signed $rel-security 1>/dev/null 2>/dev/null || pull-lp-debs grub2-signed $rel-release 1>/dev/null 2>/dev/null dpkg-deb -x grub-efi-amd64-signed*.deb grub2-signed echo $rel echo ----- find . -name grubx64.efi.signed -exec objdump -j .sbat -s {} \; | tail -n +5 | xxd -r popd >/dev/null || exit done popd >/dev/null
focal ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/ grub.ubuntu,1,Ubuntu,grub2,2.06-2ubuntu14.4,https://www.ubuntu.com/ jammy ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/ grub.ubuntu,1,Ubuntu,grub2,2.06-2ubuntu14.4,https://www.ubuntu.com/ noble ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.12,https://www.gnu.org/software/grub/ grub.ubuntu,2,Ubuntu,grub2,2.12-1ubuntu7,https://www.ubuntu.com/ grub.peimage,2,Canonical,grub2,2.12-1ubuntu7,https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/secure-boot/efi-use-peimage-shim.patch
- So if all the current LTS releases have a grub with a generation number higher than this, why are so many machines failing to boot?
- It is not just grub that is the issue - shim itself also got revoked in the same update https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2023-40547 - so shim 15.8 (ie. 4th SBAT generation of shim) is now required
- Unfortunately, the related updates for this shim in Ubuntu are still in the process of being released - https://bugs.launchpad.net/ubuntu/+source/shim/+bug/2051151
rm -rf shim-signed mkdir shim-signed pushd shim-signed >/dev/null || exit for rel in focal jammy noble; do mkdir $rel pushd $rel >/dev/null || exit pull-lp-debs shim-signed $rel-security 1>/dev/null 2>/dev/null || pull-lp-debs shim-signed $rel-release 1>/dev/null 2>/dev/null dpkg-deb -x shim-signed*.deb shim-signed echo $rel echo ----- find . -name shimx64.efi.signed.latest -exec objdump -j .sbat -s {} \; | tail -n +5 | xxd -r popd >/dev/null || exit done popd >/dev/null
focal ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.7-0ubuntu1,https://www.ubuntu.com/ jammy ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.7-0ubuntu1,https://www.ubuntu.com/ noble ----- sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim shim.ubuntu,1,Ubuntu,shim,15.8-0ubuntu1,https://www.ubuntu.com/
only noble has a new-enough shim in the security/release pocket - both focal and jammy have the older one - but the new 4th generation shim is currently undergoing testing in the -proposed pocket and will be released next week
until then, if affected, need to disable secure boot in BIOS then can either wait until the new shim is released OR just reboot twice in this mode and shim will automoatically reset the SBAT policy to the previous version, allowing the older shim to still be used
then can re-enable Secure Boot in BIOS
Once new shim is released it will reinstall the new SBAT policy to revoke its older version
One other thing, this also means the old ISOs won’t boot either
- 24.04.1 will be released on 29th August
- upcoming 22.04.5 release will also have this new shim too
- no further ISO spins planned for 20.04 - so if you really want to install this release on new hardware, would need to disable secure boot first, do the install, then install updates to get the new shim, and re-enable secure boot
Get in contact
240 episodes
All episodes
×Welcome to Player FM!
Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.