This code review was necessary because revoking trust in the vulnerable versions of GRUB2 is a complicated process that requires a big industry collaborative effort, so doing it every few months when a new flaw is found is not practical. Problems with Secure Boot trust revocation After the company privately reported the vulnerability, a security audit of the GRUB2 code base was performed by security teams from Oracle, Red Hat, Canonical and VMware, resulting in dozens of other vulnerabilities and dangerous code operations being found and fixed. The vulnerability found by Eclypsium is tracked as CVE-2020-10713 and is rated 8.2 (high) in the Common Vulnerability Scoring System (CVSS), but it’s not the only one. This will not break the trust chain, because the Linux shim bootloader and GRUB2 will have signatures that are valid and linked to the Microsoft Secure Boot key inside UEFI. Then they can configure GRUB2 to initialize Windows and exploit the vulnerability to gain persistence and control of the OS. This means that if attackers want to install a bootkit on a Windows computer with Secure Boot enabled, they can replace the Windows bootloader with a signed shim from a Linux distribution and a version of GRUB2 that has this vulnerability. The GRUB2 vulnerability found by Eclypsium, however, can have a much more widespread impact because of GRUB’s versatility: It can be used to initialize different operating systems, including Windows, for example, in dual-boot or multi-boot configurations. Secure Boot is not a perfect solution and vulnerabilities in certain UEFI implementations in the past have allowed attackers to bypass the verification, but those attacks were generally limited to specific computer manufacturers or UEFI variants. A cybercriminal gang known as FIN1 used a utility to modify the system Volume Boot Record (VBR) and start their Nemesis backdoor before Windows or security software had a chance to fully initialize. For example, the Petya and NotPetya ransomware programs were known for encrypting or the Master Boot Record (MBR) of computers. Such attacks still exist and can target systems that don’t have Secure Boot enabled. Boot-level attacks, known as boot rootkits or simply bootkits, used to be quite common a decade ago and were one of the primary reasons why Secure Boot was created. This gives them a highly privileged position and persistence on the system, as well as total control over the OS and its kernel. Once Secure Boot is turned on a computer, every boot component needs to be signed with a key that is tied back to this CA for the operating system to start, which means that Linux distributions need to have their bootloaders signed by Microsoft, too.īy adding specifically crafted content in the configuration file, attackers can exploit the vulnerability to execute malicious code in the context of the trusted bootloader before the operating system starts. This is known as the Microsoft 3rd Party UEFI Certificate Authority (CA). Secure Boot is a feature of the Unified Extensible Firmware Interface (UEFI), which has replaced the legacy BIOS firmware in all modern computers.Īlmost all UEFI implementations ship with a root key that belongs to Microsoft and establishes the root of trust for the entire platform. Secure Boot is a standardized mechanism for cryptographically verifying the integrity of all components involved in the process of booting up a computer until the operating system is initialized and takes over execution. What is Secure Boot and how does it work? It’s reasonable to expect that some systems will never be updated and will remain vulnerable to boot-level malware and rogue firmware modifications. Getting the patches that were announced today installed on all impacted computers and devices will require manual testing and deployment and will likely take a long time. The flaw is located in the GRUB2 Linux bootloader, but because of how Secure Boot is implemented, it can be used to compromise the booting process of Windows and other systems as well. Operating system maintainers, computer manufacturers, security and virtualization software vendors have worked together over the past few months to coordinate a unified response to a vulnerability that allows attackers to bypass boot process integrity verification, one of the key security features of modern computers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |