 |
| (Credit: https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot) |
When it was discovered that GRUB2 contained various vulnerabilities that would allow UEFI Secure Boot to be bypassed and which became known as the “BootHole” vulnerability (CVE-2020-10713), the recommendation was that all operating systems using GRUB2 with Secure Boot must release new installers and bootloaders.
I reviewed 'isorespin.sh' at that time as one of it's key features is the option to add a GRUB2 bootloader to allow ISOs to boot on the many Intel devices limited by their BIOS requiring a 32-bit bootloader to boot a 64-bit OS.
My initial 'fix' was based around Ubuntu's response by recompiling and adding the latest fixed GRUB2 bootloader from 'groovy' (Ubuntu 20.10) and let the Ubuntu package manager 'apt' install the appropriate GRUB2 binaries to the ISO whilst being respun.
This initially worked, however after receiving what can only be described as some abusive 'hate' email from a user complaining that 'isorespin.sh' fails when installing the 32-bit binaries, I investigated and found that Canonical had effectively removed the earlier 32-bit GRUB2 packages with vulnerabilities.
The original 'isorespin.sh' process was to download the 32-bit GRUB2 packages whose version matched the 64-bit GRUB2 packages in the ISO and update the relevant package file with the details of these packages. However in Canonical's process when a package is replaced by a newer version at some point older versions get archived so the 'isorespin.sh' download process needs to perform the download from the archive location. At this point the package information is still typically available in the package manager's cache so it is still possible to update the relevant package file.
But in order to add the other functionality in 'isorespin.sh' such as updating the kernel or installing a package as part of respinning an ISO it is also necessary to update the package manager's cache. The issue that "BootHole" subsequently created for 'isorespin.sh' was that because the cache was now updated, the earlier versions of the GRUB2 packages with the vulnerabilities were (obviously) no longer included to prevent them from being selected and installed. The consequence was that because the downloaded earlier versioned 32-bit GRUB2 packages were no longer supported, when they were further processed either by 'isorespin.sh' or as part of ISO installation, errors occurred.
Part of the problem in fixing these errors was wanting to mimic the original ISO's ability to be installed either with or without a network connection and also address the "BootHole" vulnerability as part of respinning the ISO. A new issue was encountered because by simply downloading the latest and therefore fixed 32-bit GRUB2 packages left their package dependencies untouched. This leads to package incompatibility when trying to install these later versioned packages.
To address this I've made the decision to continue to download the 32-bit GRUB2 packages whose version matches that of the ISO thereby keeping the integrity of the ISO. However in recognising that any package in the ISO's pool structure could be superseded by security updates I also then ensure that all of the pool packages are updated to their respective current version at time of respinning the ISO. This also means that their versions are reflected in the ISO's package manager's cache. Finally to correct the GRUB2 package dependencies I also update any GRUB2 packages currently installed in the ISO's filesystem.
Whilst this addresses the vulnerabilities caused by "BootHole" it does mean that if the Ubiquity installer installs other packages from the pool structure it may still result in package dependency issues. The workaround if this occurs is to either individually update the affected packages when respinning the ISO or use the '--dist-upgrade' option to upgrade all installed packages.
This newest version (8.6.4) is now available from 'isorespin.sh'.
Please donate if you find the script useful using the following link http://goo.gl/nXWSGf as everything helps with development costs.
3 comments:
Hello,
What does this mean if we have installed an old image (example linuxium-atom-ubuntu-18.04.1-desktop-amd64.iso) ?
When we are performing an update (apt-get update), is the new version of 32-bit GRUB2 packages is upgraded and we are safe from this vulnerability ?
Thanks
As you have already installed the ISO running 'apt update' will always get you (or keep you at) the latest GRUB2 packages so this vulnerability would not affect you.
For reference, this update to the 'isorespin.sh' script was to ensure a respun ISO included the latest GRUB2 packages at the time of respinning the ISO.
For example, the original ubuntu-18.04.1-desktop-amd64.iso has Canonical's 2.02-2ubuntu8.2 32-bit GRUB2 packages which have the vulnerability as it wasn't fixed until 2.02-2ubuntu8.16. If you respin that ISO now with version 8.6.4 or later of 'isorespin.sh' it will automatically update the 32-bit GRUB2 packages to 2.02-2ubuntu8.23 (as of today) to ensure that you don't/can't install a version of the 32-bit GRUB2 packages with the vulnerability. Incidentally, it does likewise for the 64-bit GRUB2 packages which will be (currently) upgaded to 2.04-1ubuntu44.1.2. All of which is only relevant when performing an offline installation of a respun ISO as when connected to the internet an installation of any ISO will automatically upgrade the GRUB2 packages.
Thanks for your answer.
Post a Comment