Currently browsing: General

VU#138043: A stack-based overflow vulnerability exists in the Microchip Advanced Software Framework (ASF) implementation of the tinydhcp server

Overview
A stack-based overflow vulnerability exists in the tinydhcp server in the Microchip Advanced Software Framework (ASF) that can lead to remote code execution.
Description
An implementation of DHCP in ASF fails input validation, thereby creating conditions for a stack-based overflow. The software is no longer supported by the vendor. Because this vulnerability is in IoT-centric code, it is likely to surface in many places in the wild.
CVE-2024-7490
There exists a vulnerability in all publicly available examples of the ASF codebase that allows for a specially crafted DHCP request to cause a stack-based overflow that could lead to remote code execution.
Impact
This vulnerability can be tested by sending a single DHCP Request packet to a multicast address. This vulnerability exists in the current version of ASF 3.52.0.2574 and all previous versions of the software. There are also multiple forks of the tinydhcp software in github that are also potentially susceptible to this vulnerability.
Solution
The CERT/CC is currently unaware of a practical solution to this problem other than replacing the tinydhcp service with another one that does not have the same issue.
Acknowledgements
Thanks to the reporter Andrue Coombes of Amazon Element55. This document was written by Timur Snoke.

Read more

VU#455367: Insecure Platform Key (PK) used in UEFI system firmware signature

Overview
A vulnerability in the user of hard-coded Platform Keys (PK) within the UEFI framework, known as PKfail, has been discovered. This flaw allows attackers to bypass critical UEFI security mechanisms like Secure Boot, compromising the trust between the platform owner and firmware and enabling manipulation of sensitive system settings.
Description
The UEFI standard establishes trust relationships using Public Key Infrastructure (PKI) between the platform owner, the platform firmware, and the operating system. Central to this process is the Platform Key (PK), which is designed to secure the connection between the platform owner and the platform firmware.

The platform owner enrolls the public half of the key (PKpub) into the platform firmware. The platform owner can later use the private half of the key (PKpriv) to change platform ownership or to enroll a Key Exchange Key. For UEFI, the recommended Platform Key format is RSA-2048.
(Section 7.2.1 of the UEFI 2.3.1 Errata C standard)

The PKFail vulnerability highlights a critical flaw in the UEFI ecosystem. While the Platform Key is expected to originate from the Original Equipment Manufacturer (OEM) using a secure hardware security module (HSM), in practice, much of the UEFI software and drivers are developed by a complex network of supply-chain partners and Independent BIOS Vendors (IBVs). These components are often shared across multiple OEMs. In some cases, temporary test software keys, or “softkeys,” which are hard-coded for ease of build and testing, inadvertently make their way into production firmware.
These softkeys, intended solely for compatibility testing and performance evaluation, are supposed to be untrusted and restricted in their usage. The current UEFI’s key verification process is limited – it only checks against the keys in the local database, with no verification against the root Certificate Authority (CA) or special validation of extended attributes. Although keys cannot be self-signed, the lack of stringent verification allows these untrusted keys to be mistakenly included in production firmware.
Recent audits have uncovered that many OEM devices shipped with hard-coded, untrusted keys in their production UEFI firmware. Despite these keys often having attributes like “DO NOT TRUST,” there is no programmatic safeguard or other validations (say attribute-based) to prevent their inclusion in final products. The compromise or leak of these private keys could have bad consequences, allowing attackers to sign malicious modules that execute with high privileges during the boot process, even if Secure Boot is enabled. This undermines the very purpose of signed software verification, leaving systems vulnerable to untrusted and malicious modules.
Compounding the issue, UEFI firmware is largely invisible to most Endpoint Detection and Response (EDR) software, making it difficult to audit and detect the use of compromised keys. Moreover, many UEFI implementations lack Remote Measurement or Auditing capabilities that could dynamically check the integrity of the key database via network resources.
Impact
An attacker with access to an undesired-yet-trusted test Platform Key’s private portion can exploit it to sign malicious UEFI software, enabling the execution of code with the highest privileges during the early boot phases of a UEFI Secure Boot-protected system. A successful attack could lead to the following impacts:

Invalidation or bypass of UEFI security features like SecureBoot.
Installation of persistent software that cannot be easily detected or erased, that can also persist across reboots and potentially surviving OS reinstalls.
Creation of backdoors and back communications channels to exfiltrate sensitive data.
Interruption of system execution leading to device damage or permanent shutdown.

Solution

Update UEFI Firmware: Ensure you install the latest stable version of UEFI firmware provided by your PC vendor or the reseller of your computing environment. Refer to the Vendor Information section below for specific resources and updates from vendors addressing these vulnerabilities.
Use Researcher Tools for Impact Assessment: Utilize tools and information provided by Binarly to assess the impact of untrusted Platform Keys on your systems. These resources can help you conduct a thorough analysis of affected systems.
Leverage Automatic Firmware Updates: If your operating system supports automatic or managed firmware updates (e.g., Linux Vendor Firmware Service, LVFS), regularly check for updates using fwupdmgr get-updates and apply them with fwupdmgr update or use Windows OEM supported mechanisms as appropriate. Keeping your firmware up to date is crucial in mitigating the risks associated with PKfail.

Acknowledgements
Thanks to Binarly for disclosing this vulnerability. This document was written by Vijay Sarvepalli.

Read more

VU#730793: Heimdal Kerbos vulnerable to remotely triggered NULL pointer dereference

Overview
The Heimdal Software Kerberos 5 implementation is vulnerable to a null pointer dereferance. An attacker with network access to an application that depends on the vulnerable code path can cause the application to crash.
Description
A flawed logical condition allows a malicious actor to remotely trigger a NULL pointer dereference using a crafted negTokenInit token.
Impact
An attacker can use a specially crafted network packet to cause a vulnerable application to crash.
Solution
The latest version of code in the Heimdal master branch fixes the issue. However, the current stable release 7.7.0 does not include the fix.
Acknowledgements
Thanks to the International Continence Society for reporting this issue.
This document was written by Kevin Stephens.

Read more

VU#309662: Signed third party UEFI bootloaders are vulnerable to Secure Boot bypass

Overview
A security feature bypass vulnerability exists in signed 3rd party UEFI bootloaders that allows bypass of the UEFI Secure Boot feature. An attacker who successfully exploits this vulnerability can bypass the UEFI Secure Boot feature and execute unsigned code during the boot process.
Description
UEFI firmware is software written by vendors in the UEFI ecosystem to provide capabilities in the early start up phases of a computer. Secure Boot is a UEFI standard that can be enabled and used to verify firmware and to protect a system against malicious code being loaded and executed early in the boot process, prior to the loading of the operating system.
Security researchers at Eclypsium have found three specific UEFI bootloaders that are signed and authenticated by Microsoft to be vulnerable to a security feature bypass vulnerability allowing an attacker to bypass Secure Boot when it is enabled. The vulnerable bootloaders can be tricked to bypass Secure Boot via a custom installer (CVE-2022-34302) or an EFI shell (CVE-2022-34301 and CVE-2022-34303). As a vulnerable bootloader executes unsigned code prior to initialization of the the Operating System’s (OS) boot process, it cannot be easily monitored by the OS or common Endpoint Detection and Response (EDR) tools.
The following vendor-specific bootloaders were found vulnerable:
Inherently vulnerable bootloader to bypass Secure BootNew Horizon Datasys Inc (CVE-2022-34302)

UEFI Shell execution to bypass Secure BootCryptoPro Secure Disk (CVE-2022-34301)
Eurosoft (UK) Ltd (CVE-2022-34303)

Impact
An attacker can bypass a system’s Secure Boot feature at startup and execute arbitrary code before the operating system (OS) loads. Code executed in these early boot phases can provide persistence to an attacker, potentially loading arbitrary kernel extensions that survive both reboot and re-installation of an OS. It may also evade common OS-based and EDR security defenses.
Solution
Apply a patch
Apply your vendor-provided security updates that address these vulnerabilities to block vulnerable firmware from bypassing Secure Boot. Microsoft has provided details with their KB5012170 article released on August 9th 2022. Note, these updates can be delivered from your OEM vendor or the OS vendor to install an updated Secure Boot Forbidden Signature Database (DBX) .
Enterprise and Product Developers
As DBX file changes can cause a system to become unstable, Vendors are urged to verify the DBX updates do not cause the machine to be unusable. Enterprises and Cloud Providers that manage large number of computers are also urged to do the required security updates and ensure DBX files are implemented reliably without any risk of boot failure.
Acknowledgements
Thanks to Mickey Shkatov and Jesse Michael of Eclypsium who researched and reported these vulnerabilities.
This document was written by Brad Runyon & Vijay Sarvepalli.

Read more