Sign up to save your podcasts
Or
Share Episode 235
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Episode 235
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
[USN-6951-2] Linux kernel (Azure) vulnerabilities
[USN-6961-1] BusyBox vulnerabilities
[USN-6962-1] LibreOffice vulnerability
[USN-6963-1] GNOME Shell vulnerability (01:03)
to allow user to login etc
contain arbitrary javascript etc
this is the case since would still be constrained by the webkitgtk browser so would also need a sandbox escape etc.
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
[USN-6964-1] ORC vulnerability
[USN-6837-2] Rack vulnerabilitie
[USN-6966-1] Firefox vulnerabilities
[USN-6966-2] Firefox regressions
[USN-6951-3] Linux kernel (Azure) vulnerabilities
[USN-6968-1] PostgreSQL vulnerability
[USN-6967-1] Intel Microcode vulnerabilities
[LSN-0106-1] Linux kernel vulnerability
[USN-6969-1] Cacti vulnerabilities
[USN-6970-1] exfatprogs vulnerability
[USN-6944-2] curl vulnerability
[USN-6965-1] Vim vulnerabilities
Goings on in Ubuntu Security Community
Reports of dual-boot Linux/Windows machines failing to boot (04:30)
versions of grub that were susceptible to CVE-2022-2601
next component is signed with a valid signature before it is then loaded
shouldn’t be trusted
BootHole vulnerabilities revoked a huge number of grub binaries from many
different distros, some devices failed to boot as the NVRAM was too full
called SBAT - Secure Boot Advanced Targeting
vulnerabilities, upstream bumps the generation number
list and if it is too old refuses to load it
Discourse - in this case we updated shim to a newer version which itself
revoked an older grub, grub,1
for grub to 3
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
than this, why are so many machines failing to boot?
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
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
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
View all episodes
By Ubuntu Security Team
4.8
1010 ratings
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
[USN-6951-2] Linux kernel (Azure) vulnerabilities
[USN-6961-1] BusyBox vulnerabilities
[USN-6962-1] LibreOffice vulnerability
[USN-6963-1] GNOME Shell vulnerability (01:03)
to allow user to login etc
contain arbitrary javascript etc
this is the case since would still be constrained by the webkitgtk browser so would also need a sandbox escape etc.
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
[USN-6964-1] ORC vulnerability
[USN-6837-2] Rack vulnerabilitie
[USN-6966-1] Firefox vulnerabilities
[USN-6966-2] Firefox regressions
[USN-6951-3] Linux kernel (Azure) vulnerabilities
[USN-6968-1] PostgreSQL vulnerability
[USN-6967-1] Intel Microcode vulnerabilities
[LSN-0106-1] Linux kernel vulnerability
[USN-6969-1] Cacti vulnerabilities
[USN-6970-1] exfatprogs vulnerability
[USN-6944-2] curl vulnerability
[USN-6965-1] Vim vulnerabilities
Goings on in Ubuntu Security Community
Reports of dual-boot Linux/Windows machines failing to boot (04:30)
versions of grub that were susceptible to CVE-2022-2601
next component is signed with a valid signature before it is then loaded
shouldn’t be trusted
BootHole vulnerabilities revoked a huge number of grub binaries from many
different distros, some devices failed to boot as the NVRAM was too full
called SBAT - Secure Boot Advanced Targeting
vulnerabilities, upstream bumps the generation number
list and if it is too old refuses to load it
Discourse - in this case we updated shim to a newer version which itself
revoked an older grub, grub,1
for grub to 3
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
than this, why are so many machines failing to boot?
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
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
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