Software

Shim vulnerability causes Secure Boot security to fail when PC starts

Shim vulnerability causes Secure Boot security to fail when PC starts

And bootloader EFI (Extensible Firmware Interface) is a type of bootloader specifically designed to interact with UEFI firmware (Unified Extensible Firmware Interface). The latter replaces the traditional BIOS in modern computer systems. The bootloader is a crucial component in the boot process of an operating system, as it is responsible for load the system operating in memory and start execution of kernel.

Among the features that UEFI integrates there is also Secure Boot, which has also become a requirement essential for the installation of Windows 11. A security tool like Secure Boot aims to protect the system boot process from malware and unauthorized software by digitally verifying the integrity of key components during boot. With Secure Boot enabled, every component loaded at boot time on the device, including the bootloader, kernel, and drivers, must have a company digital recognized and accepted.

A software component like the EFI bootloader can boot a wide range of operating systems that support UEFI firmware but the entire “chain” of objects loaded at boot must also be digitally signed when Secure Boot is enabled.

The vulnerability in shim that rocks the entire Secure Boot

When they emerge vulnerability security issues that directly impact the functioning and security of Secure Boot, it is always a good idea to straighten the antennas. The risk could be that any attackers could arrange for the upload of arbitrary codenot digitally signed, at system startup.

Bill Demirkapi (Microsoft Security Response Center) discovered a critical flaw within shim, the software component that acts as an intermediary between the boot firmware and the operating system. The mechanism shim it is often used in cases where the operating system or booloader does not have a valid digital signature accepted by Secure Boot. Shim acts as a bridge between Secure Boot and third-party operating system or bootloader that may otherwise not be trusted.

It is precisely the solution that the Rufus developer has adopted to make it compatible with Secure Boot and ensure correct loading at startup of any software without the need to disable protection at the UEFI BIOS level.

Demirkapi explains that the CVE-2023-40547 vulnerability can be exploited to conduct a type attack buffer overflow and cause potentially malicious code to be loaded, bypassing the checks and restrictions normally imposed by Secure Boot.

The origin of the security problem and its consequences

As the Microsoft researcher explains, an attacker can use the method shim per retrieve files via HTTP or similar protocols. Vulnerable versions of shim they try to allocate a buffer based on the size specified in an HTTP header. The dependence on external data, which can be manipulated “artfully”, together with the presence of metadata linked to the architecture of the protocol itself, allows attackers to exploit a situation that can lead to attacks buffer overflow.

The result is that the system protected by Secure Boot, opening itself up to the execution of arbitrary code, can come under the control of the attacker. In fact, the latter becomes capable of carrying out operations not permitted by Secure Boot.

In the latest version of shim we already find traces of patch corrective that in the meantime the developers have already applied. However, the persistence of the bug in every bootloader Linux used over the past decade, highlights the broad implications of the flaw now labeled CVE-2023-40547.

The vulnerability in question not only tests the effectiveness of Secure Boot, but sounds like a new alarm bell that demonstrates how the security of modern IT platforms is anything but a given.

Credit immagine in apertura: Microsoft Bing Image Creator.

Leave a Reply

Your email address will not be published. Required fields are marked *