New faults Nifters Secure Boot, but no reason to panic. Why over here


GRUB2, one of the world’s most widely used programs to boot computers, has a vulnerability that could make it easier for attackers to run malicious firmware during startup, researchers said on Wednesday said. This will affect millions or possibly hundreds of millions of machines. While GRUB2 is primarily used in computers running Linux, attacks that exploit vulnerabilities can also be performed on many PCs running Windows.

The vulnerability, discovered by researchers at security firm Eclipseum, is another serious threat to UEFI Secure Boot, an industry-wide standard that uses cryptographic signatures to ensure that the software used during startup is connected to the computer. Trusted by the manufacturer. Secure Boot was designed to prevent the boot process from being hijacked by replacing attacker software with malicious software.

Stealth, more powerful, and harder to disinfect

So-called bootkits are among the most serious types of infections because they run at the lowest level of the software stack. This allows malware to be the most stolen from malware, avoid operating system reinstalls, and circumvent security built into the OS.

The boot hole, as the researchers have named the vulnerability, stems from a buffer overflow in the way that GRUB2 parses the text in grub.cfg into the boot loader’s main configuration file. By adding long text strings to a file, attackers can overfill the memory space allocated for the file and cause malicious code to spread to other parts of memory, where it is then executed.

The configuration file is not digitally signed, so the secure boot will not be detected when it has been maliciously altered. GRUB2 also does not use address space layout randomization, data execution prevention, and other anti-exploitation protections that are standard in operating systems. These omissions make it trivial for attackers who already have a foothold on the target computer to exploit the blame. From there, they can bypass a protection altogether, with many hoping to prevent bootkits from catching on.

In addition to the Eclipseum report, Debian provides a solid overview here.

But there are some major catches

The severity of the vulnerability, however, is offset by a few things. First, the attacker must have administrative rights over the computer or have physical access to the machine. Administrator-level control is increasingly difficult to obtain on modern OSes because major exploits are built to block their exploits. Physical access can be easier during border crossings or similar moments when a user loses physical possession of a computer. But the requirement stands in most other situations, making it unlikely that many users are affected. What’s more, physical possession greatly limits the scalability of attacks.

Two other factors that make a boot hole less intimidating: Attackers who already have administrative or physical control of the computer have advanced and other ways of infecting it with stolen malware. In addition, there are many other known techniques to circumvent safe boot.

“I argue that Secure Boot is not the foundation of PC security today, because it is rarely effective, and by them [Eclypsium’s] It has been easy to ignore for over a year now, there is no improvement in long-term vision, claims myself, ”HD Moore, vice president of research and development at Etredis Partners and an expert in software exploitation, told me. “I’m not sure what buffer overflow is useful in GRUB2, because there are other problems if grub.cfg is unsigned.” This may be useful as a malware vector, but still, no reason to exploit buffer overflow. Is when a custom grub.cfg file can be used to load the actual OS. “

Other researchers seem to agree with the assessment. CVE-2020-10713, as the vulnerability is monitored, has a critical rating of “Moderate.”

Eclipseum claims that Moore in February included the revocation of Kaspersky Lab, a bootloader security firm that was used in rescue disks to start a disabled computer. The repeal caused so many problems that Microsoft, which oversees the verification process, withdrew the change. The repeal underscores not only the difficulty of plugging the boot hole (such as more about the latter), but also the fact that it is already possible to circumvent the secure boot.

Not scary doesn’t mean serious

Exploitation constraints and limitations do not mean that vulnerability is not worth taking seriously. The safe boot was precisely built for the scenario required to exploit the boot hole. The risk is increased by the number of affected computer and software manufacturers. Eclipseum has a complete list of affected people. They are:

  • Microsoft
  • Integrated Extensible Firmware Interface Forum
  • Oracle
  • Red Hat (Fedora and RHEL)
  • Canonical (Ubuntu)
  • SuSE (SLES and OpenSUSE)
  • Debian
  • Cytrix
  • VMware
  • Various computer manufacturers
  • Software vendors, including security software

A more serious consideration is that the challenge in pursuing the update does not permanently prevent a machine from starting, a phenomenon often referred to as “bricking”. As the Kaspersky incident suggests, the risk is real and can have terrible consequences.

Messing up is a mess in itself

The fix includes a multistep process that in many cases will not be trivial, or fast. First, GRUB2 should be updated to fix the vulnerability and then distributed to manufacturers or administrators of large organizations. There, engineers must thoroughly test the update on each computer model that it supports to ensure that the machine does not brick. Updates have to be fixed for machines that do. Only after this the update will be ready to install generally.

Nevertheless, it would be trivial for attackers with the above privileges to revert GRUB2 to its weaker version and exploit buffer overflow. Although GRUB2 is not usually installed in Windows machines, privileged attackers can usually install it. To close this drawback, computer manufacturers must cancel cryptographic signatures validating the “shim” firmware loading the older version or older version.

This step also comes at the risk of brick making machines. If signatures are revoked before the GRUB2 version is installed – or in the case of Windows machines, signatures for other boot components – before adequate testing, millions of computers are also at risk of being brick.

To circumvent this possibility, Microsoft, Red Hat, Canonical, and other OS and hardware manufacturers are typically offering two-step improvements. First, the GRUB2 update will be released and it will be considered safe to install only after testing. Then, after the previous months period, the signatures will be revoked. The vulnerability will be patched only after the second phase is completed.

Microsoft, which operates the Certificate Authority certifying UEFI signatures, duly authorized by the manufacturers, issued the following statement:

We are aware of a vulnerability in the GRAND Unified Boot Loader (GRUB) commonly used by Linux. To exploit this vulnerability, an attacker would need administrative privileges or physical access to a system where Secure Boot is configured to rely on the Microsoft UEFI CA. We are working to complete validation and compatibility testing of a required Windows Update package.

A Microsoft spokesman said the company would provide IT administrators, who urgently needed a “mitigation option to install the test-free update”. In an unspecified time, the spokesperson said, Microsoft will make a definitive release for general availability. Microsoft has released a knowledge base article here.

Advice from other affected companies is too much to provide in an early version of this article. At the moment, readers should check the websites of the affected companies. This post will be updated later to provide the link.

For now, there is nothing to panic. The standing requirements for exploits moderate the severity of this vulnerability. And as already mentioned, safe boot is already vulnerable to other bypass techniques. This does not mean that there is no reason to take this vulnerability seriously. Patch it as soon as possible, but after thorough testing, either by experienced users or affected OS and software manufacturers. In the meantime, don’t lose any sleep.

Leave a Reply

Your email address will not be published.