[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 16/08/2020 16:03, Sebastian wrote:
I have read the article you linked to - somehow I am sceptical of the terms 'Secure Boot' and 'Microsoft CA' being used together... It is not the more diverse set of authorities that the Web has benefited from.To close this vulnerability, you need to deploy the revocation update. Make sure that all bootable media has received OS updates first, roll it out slowly to only a small number of devices at a time, and incorporate lessons learned from testing as part of this process.Clearly, MX Linux revoked the certificate without checking that GRUB had been updated. Now I know why I was confused - I have never used a PC with UEFI/Secure Boot and the idea that certificates could be revoked universally within UEFI, affecting even 'remote' media like Live USB discs, is completely alien to me! Thus, thanks to you and Neil I am just a little bit better prepared for when I will be using a UEFI PC.With the sole exception of one bootable tool vendor who added custom code to perform a signature verification of the grub.cfg config file in addition to the signature verification performed on the GRUB2 executable, all versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable.I would have liked to have known which vendor that was. The article is quick to 'name and shame' the vulnerable vendors but the person(s) with that foresight to check the config file deserves to be credited. Those who patch problems after they have occurred are held up as heroes; those who patch problems proactively are conversely underappreciated. I'm glad to hear that Neil is now back to full operational capability and can light the green light for his wife's computer! Best wishes, Sebastian Freenode: 'seabass' PS. I do love Vim! In pasting the article into this email with the prefix '>>', Vim automatically colours the quote. Then, by typing 'gqip' to format the file into consistent line lengths it puts the extra '>'s just where they need to be for me. I'm not going back to webmail! :)
Here's the report from the original researchers who found and published it: https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/For details on vulnerabilities if you want to follow them up check the official databases for details:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-10713 https://www.kb.cert.org/vuls/id/174059Usually there'll be links to the original source and as much follow up information as you can use there - if you're really lucky even a functional PoC (or wait for metasploit to provide a module).
Secure Boot is a subset of UEFI but not critical so don't let it hold you back - the vast majority of modern-ish PCs support dual BIOS/UEFI firmware stacks which you can toggle between at will so you probably already have the capability on your computer(s) already. Agreed the Microsoft CA bit is a little sketchy - maybe you're too young to remember all the bitter fighting about it when UEFI was first introduced? - but the Secure Boot standard actually mandates that it can be manually disabled so normally it's just turned off on opensource systems. That being said all major linux distros now incorporate EFI shims to boot the signed kernels they provide so Ubuntu, Fedora, SUSE etc work fine with it.
Well, until this bug they did :] -- The Mailing List for the Devon & Cornwall LUG https://mailman.dcglug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq