New 'PixieFail' Vulnerabilities in UEFI Firmware Threaten Enterprise Systems
The vulnerabilities, dubbed PixieFail, impact the IPv6 network stack in EDK II and could enable remote attackers to break into systems during early boot processes.
The Extensible Firmware Interface (EFI) and its successor, the Unified Extensible Firmware Interface (UEFI), are specifications that define interfaces between the operating system and the platform firmware. UEFI firmware provides an interface for booting the device and launching the operating system. EDK II is an open source implementation of UEFI developed by the TianoCore community and serves as a codebase for many commercial UEFI firmware products.
The PixieFail vulnerabilities specifically impact the IPv6-based Preboot Execution Environment (PXE) boot functionality in EDK II’s network stack implementation (NetworkPkg). PXE boot enables booting devices over the network, which is commonly used in data centers and other environments to centrally provision large numbers of systems.
The vulnerabilities arise from flaws in EDK II’s implementation of various IPv6 network protocols that support PXE boot, including ICMPv6, DHCPv6, DNS, and more.
According to the researchers, the vulnerabilities could be exploited by attackers on the local network or in some cases remote networks to:
- Launch denial of service attacks
- Leak sensitive information
- Hijack network sessions
- Execute arbitrary code
- Poison DNS caches
Quarkslab reported the vulnerabilities to CERT/CC in August 2023, which then coordinated disclosure to affected vendors. The disclosure was initially set for November 2023 but was postponed several times over the following months to allow vendors time to develop fixes. The researchers have expressed frustration over the lack of commitment from vendors to address the issues in a timely manner.
The vulnerabilities discovered include:
- CVE-2023-45229 - An integer underflow flaw when handling DHCPv6 packets that could cause out-of-bounds memory access
- CVE-2023-45230 - A buffer overflow when handling long server ID options in DHCPv6 responses
- CVE-2023-45231 - Out of bounds read due to lack of validation of ND redirect message options
- CVE-2023-45232 - Infinite loop when parsing unknown IPv6 destination options
- CVE-2023-45233 - Infinite loop when handling IPv6 destination options with specific padding (PadN) values
- CVE-2023-45234 - Buffer overflow when handling improperly sized DNS server options in DHCPv6 responses
- CVE-2023-45235 - Buffer overflow when copying oversized server ID options from DHCPv6 proxy responses
- CVE-2023-45236 - Predictable TCP sequence numbers enable session hijacking attacks
- CVE-2023-45237 - Use of weak pseudo random number generator creates predictable values and enables information leaks
The vulnerabilities highlight the security risks posed by the complex firmware supply chain, where open source code like EDK II is used in commercial firmware products from various vendors. Dependency on the open source project for fixes also slowed the response from vendors. TianoCore has produced patches for the first 7 vulnerabilities but they are still undergoing testing and validation at the time of disclosure.
Several major firms likely use firmware derived from EDK II in their products based on the list of affected vendors shared by CERT/CC. These include HP, Intel, Lenovo, Dell, Cisco, Samsung, American Megatrends Inc. (AMI), Phoenix Technologies, Microsoft, VMware, Insyde Software, and likely many others. Most have remained silent on their vulnerability status and plans for fixes.
Administrators of sensitive systems are advised to take precautions in light of the flaws by restricting network access to vulnerable devices during boot, using heuristics to detect exploitation attempts, and monitoring systems for abnormal crashes or boot failures. Applying firmware updates containing security fixes when they become available from device manufacturers is highly recommended.
The PixieFail vulnerabilities provide another example of the security risks introduced by the complex interdependencies between open source and commercial software in the firmware supply chain. Increased investment in secure firmware development practices and improved response coordination between open source projects and downstream vendors are clearly needed. Kudos to the researchers at Quarkslab for their efforts to responsibly disclose these issues and spur action across the industry.