Security Week 32: Vulnerability in GRUB2

On July 29, Eclypsium published a study of a new vulnerability in the Grub2 bootloader, which is widely used in Linux-based systems - from laptops and IoT devices to servers. The essence of the vulnerability is quite simple: errors in the processing of the text configuration file grub.cfg lead to a buffer overflow and open the possibility of arbitrary code execution. The consequences are also clear: hacking the system at an early stage of boot provides full control over it, making it difficult to detect the problem. The vulnerability was assigned the identifier CVE-2020-10713... This is not the only vulnerability closed in Grub2 lately: after notifying maintainers of popular distributions, at least 7 more similar problems with a CVSS threat rating from 5.7 to 6.4 were fixed in the bootloader code. The original vulnerability received 8.2 points according to the same assessment method.



To exploit a vulnerability, an attacker needs a high level of access to the system. So high that in most scenarios it seems that it is not necessary to additionally hack Grub2. The options for when this actually benefits an attacker remains to be explored. The main problem with this vulnerability lies in the complex relationship between Grub2 and UEFI Secure Boot, a universal hardware initialization tool that, among other things, ensures that only verified code with a digital signature will be launched in the next stages. Due to the nature of the license under which Grub2 is distributed, there is an intermediary between UEFI and Grub2 known as shim - a small bootloader that checks the version of Grub2. The re-release of these same shim, and at the same time the UEFI update of a huge number of systems, blocking old shim, is,in simple terms, the industry's Giant Headache.



The technical features of the vulnerability are described in sufficient detail (but without examples of exploitation) in the Eclypsium report. The Grub2 code for parsing the textual configuration file handles the situation when the input line is too long. An error in your code could cause the data to be loaded anyway and a buffer overflow. In this case, it is not vulnerability that is more important, but its consequences. Previously, there have already been situations when an unprotected version of Grub (due to a configuration error) had to be added to the so-called UEFI Revocation List- a list of shim that the updated system will refuse to run. This list needs to somehow be delivered to a specific system, which can be done either by the hardware vendor or by the operating system developer, for example, Microsoft, which, among other things, is responsible for certifying the boot code, including for Linux systems. Any mistake in an update applied at an early stage can render the computer or server completely inoperable.



In other words, a Grub update covering newly discovered vulnerabilities is not enough to fix the problem. It is required to prevent the execution of older versions of Grub2 by adding their associated shim to the UEFI Revocation List. According to Eclypsium, more than 80 intermediate bootloaders will need to be blocked, and this will already exclude the possibility of running arbitrary code if the update somehow gets to a specific motherboard with a specific version of UEFI. And by the way, since the vulnerability was found in generic, platform-independent code, devices on the arm64 architecture are also affected.



In addition, the disaster recovery systems for computers or servers will need to be updated, otherwise the recovery tool may not work in the future. You will need to test both Grub patches, new intermediate loaders, and Revocation List updates. Even a simple Grub2 update already causes problems: see the report on Habré about the inoperability of servers running CentOS after installing the RHSA-2020 bug fix: 3216that covers this vulnerability. It will take a long time to solve the problem, and that is why the Grub2 code was checked for similar vulnerabilities so that you did not have to go through this process several times. On the one hand, this vulnerability does not pose a real danger right now. On the other hand, it includes a complex mechanism of interaction between software and hardware developers, which in this case is inevitable. Good confirmation of the conventional wisdom that security is a process, not a result.

What else happened

Garmin is addressing the consequences of an attack on its own infrastructure detailed in the previous digest . As of August 3, Garmin Aviation services, including FlyGarmin, have been fully restored. The functionality of the Garmin Connect cloud service for the company's smartwatches has been partially restored . The website Bleeping Computer, again citing anonymous sources, reports that the company has received a key to decrypt data affected by the ransomware Trojan. How exactly is not clear, but there are few possible options here. Kaspersky Lab experts have published a detailed analysis of the WastedLocker sample, which (most likely) attacked Garmin.



Another major extortion attackoccurred at the travel company CWT. Attackers are demanding a ransom of $ 4.5 million.



In the US, suspects have been arrested for hacking dozens of Twitter accounts in mid-July . The burglars were so quickly identified thanks to their carelessness. For example, one email address was used on a hacker forum and on a cryptocurrency exchange, and a hack of the forum allowed us to associate an account with a real IP. More details are in the ZDNet publication and on Habré .



A vulnerability in Grandstream VoIP adapters allows them to be hacked at the initial configuration stage, including using a prepared SIP packet.



Zoom closedA "childish" vulnerability that allowed cracking passwords to access the teleconference. Passwords in Zoom are six-digit, and the number of attempts to enter is not limited in any way - it could be cracked by brute force, knowing only the meeting ID (usually constant).



A fresh ten-point vulnerability was found in the wpDiscuz plugin for processing comments on sites running Wordpress with the ability to execute arbitrary code. Affected 70 thousand sites.