3 ms·
Ubuntu had this as well, but got a release out quickly so it seems to have not been too huge an issue. Bug report: https://bugs.launchpad.net/cloud-init/+bug/1
by fideloper 6y ago
Ubuntu had this as well, but got a release out quickly so it seems to have not been too huge an issue.
Bug report: https://bugs.launchpad.net/cloud-init/+bug/1877491 https://bugs.launchpad.net/cloud-init/+bug/1877491
Description/remediation: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass?_ga=2.62301103.2044889230.1596151413-1800768090.1596151413 https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2Secu...
- gruez 6y ago>Currently, we populate the debconf database variable grub-pc/install_devices by checking to see if a device is present in a hardcoded list [1] of directories: Is there a reason why this patch was silently applied? For something as risky as breaking the boot process, you'd think you want user confirmation before proceeding. It can obviously be done, eg. https://d11a6trkgmumsb.cloudfront.net/original/3X/f/5/f55e369ca3bd66b980e00a0f56ae0f332371fc52.png https://d11a6trkgmumsb.cloudfront.net/original/3X/f/5/f55e36.... Also, recovering from this might be easy if you're technically inclined, but it could be worse if you have FDE enabled with the boot keys sealed in TPM. Changing the boot loader or the secure boot settings in that case might lead to the TPM refusing to release the disk encryption keys, which could lead to permanent loss of data.