Skip to content
PIXIEFAIL

New UEFI vulnerabilities send firmware devs industry wide scrambling

PixieFail is a huge deal for cloud and data centers. For the rest, less so.

Dan Goodin | 79
Credit: Nadezhda Kozhedub
Credit: Nadezhda Kozhedub
Story text

UEFI firmware from five of the leading suppliers contains vulnerabilities that allow attackers with a toehold in a user's network to infect connected devices with malware that runs at the firmware level.

The vulnerabilities, which collectively have been dubbed PixieFail by the researchers who discovered them, pose a threat mostly to public and private data centers and possibly other enterprise settings. People with even minimal access to such a network—say a paying customer, a low-level employee, or an attacker who has already gained limited entry—can exploit the vulnerabilities to infect connected devices with a malicious UEFI.

Short for Unified Extensible Firmware Interface, UEFI is the low-level and complex chain of firmware responsible for booting up virtually every modern computer. By installing malicious firmware that runs prior to the loading of a main OS, UEFI infections can’t be detected or removed using standard endpoint protections. They also give unusually broad control of the infected device.

Five vendors, and many a customer, affected

The nine vulnerabilities that comprise PixieFail reside in TianoCore EDK II, an open source implementation of the UEFI specification. The implementation is incorporated into offerings from Arm Ltd., Insyde, AMI, Phoenix Technologies, and Microsoft. The flaws reside in functions related to IPv6, the successor to the IPv4 Internet Protocol network address system. They can be exploited in what’s known as the PXE, or Preboot Execution Environment, when it’s configured to use IPv6.

PXE, sometimes colloquially referred to as Pixieboot or netboot, is a mechanism enterprises use to boot up large numbers of devices, which more often than not are servers inside of large data centers. Rather than the OS being stored on the device booting up, PXE stores the image on a central server, known as a boot server. Devices booting up locate the boot server using the Dynamic Host Configuration Protocol and then send a request for the OS image.

PXE is designed for ease of use, uniformity, and quality assurance inside data centers and cloud environments. When updating or reconfiguring the OS, admins need to do so only once and then ensure that hundreds or thousands of connected servers run it each time they boot up.

A diagram showing how PXE boot works when using IPv6.

By exploiting the PixieFail vulnerabilities, an attacker can cause servers to download a malicious firmware image rather than the intended one. The malicious image in this scenario will establish a permanent beachhead on the device that’s installed prior to the loading of the OS and any security software that would normally flag infections.

The vulnerabilities and proof-of-concept code demonstrating the presence of the vulnerabilities were developed by researchers from security firm Quarkslab, which published the findings Tuesday.

The network presence required to exploit most of the vulnerabilities is relatively minor. Attackers need not establish their own malicious server or gain high-level privileges. Instead, the attacker only needs the ability to view and capture traffic as it traverses the local network. This kind of access may be possible when someone has a legitimate account with a cloud service or after first exploiting a separate vulnerability that gives limited system rights. With that, the attacker can then exploit PixieFail to plant a UEFI-controlled backdoor in huge fleets of servers.

Quarkslab Chief Research Officer Iván Arce said in an interview:

An attacker doesn't need to have physical access neither to the client nor the boot server. The attacker just needs to have access to the network where all these systems are running and it needs to have the ability to capture packets and to inject packets or transmit packets. When the client-{based server] boots, the attacker just needs to send the client a malicious packet in the [request] response that will trigger some of these vulns. The only access that the attacker needs is access to the network, not physical access to any of the clients, nor to the boot server or DHCP server. Just capture packets or send packets in the network, where all these servers are running.

For PixieFail to be exploited, PXE must be turned on. For the overwhelming number of UEFIs in use, PXE isn’t turned on. PXE is generally used only in data centers and cloud environments for rebooting thousands or tens of thousands of servers. Additionally, PXE must be configured to be used in combination with IPv6 routing.

A motley bunch

PixieFail is a motley mix of different vulnerability types, ranging from buffer overflows and integer underflows, both of which allow for remote code execution, to the lack of standard but crucial security practices, such as a properly functioning pseudorandom number generator. There was also a TCP implementation that didn’t follow a basic IETF RFC that has been recommended since 2012. The nine vulnerabilities are:

The makers of the affected UEFIs are in the process of getting updates pushed out to customers. And from there, those customers are making patches available to their customers, who usually are end users. AMI confirmed the vulnerability affects its Optio V line of firmware and said it has made patches available to its customers. AMI provided a public advisory here and customer-only ones here and here.

Microsoft, meanwhile, issued a statement that said the company was taking “appropriate action” without saying what that was. Microsoft also claimed—in error, Arce said—that exploiting the vulnerability required the attacker to first establish a malicious server on the affected network. Arce says no such requirement exists.

"An attack only needs to be able to send packets on that network," he said. "Also, the proof of concept code which we provided to all vendors, including Microsoft, does not set up any server."

Microsoft didn’t have a response to Arce’s analysis. Microsoft also noted the requirement of using PXE over an IPv6 network.

“As a security best practice, we recommend disabling unused boot capabilities, only using PXE or other protocols on trusted networks, and using TLS over the internet,” Microsoft officials added.

Officials with Arm Insyde and Phoenix didn’t respond or didn't have a comment.

As noted, PixieFail isn’t something most people need to worry about. The vulnerabilities, however, are most definitely something that cloud environments and data centers should greatly care about. After all, exploits allow someone with limited network access to suddenly backdoor any server in a network the next time it reboots. Over the course of a matter of weeks, that could lead to an entire fleet of infected machines.

Out of an abundance of caution and in keeping with security in-depth principles, all end users should patch the vulnerabilities as well, but the urgency in this case is fairly relaxed. Users generally should look to their device or motherboard maker for an update.

Update: A little more than 13 hours after this post went live, Microsoft officials updated their statement to add: "If an attacker is able to capture and transmit packets on the network (this is, the ability “to serve” packets), they can pretend to be a 'server.'"

Listing image: Nadezhda Kozhedub

Photo of Dan Goodin
Dan Goodin Senior Security Editor
Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at @dangoodin on Mastodon. Contact him on Signal at DanArs.82.
79 Comments
Staff Picks
B
Ummm.... Not just data centers.

PXE is heavily used for large desktop deployment environments as well. System Center and other bulk deployment platforms use it to boot off the LAN to dump a machine with a new image. Anyone running such an environment is probably at risk as well.
a
Ummm.... Not just data centers.

PXE is heavily used for large desktop deployment environments as well. System Center and other bulk deployment platforms use it to boot off the LAN to dump a machine with a new image. Anyone running such an environment is probably at risk as well.

Indeed. AMI and phoenix provide quite a lot of desktop PC EFI firmware, and they're on the vulnerable list, so that's going to be a giant headache to patch especially when you have a variety of hardware from different waves of purchasing.

On the other hand, in that sort of environment the users already have physical access to the PCs which opens up so many other methods of attack, this is just one more on the pile of what an in-house staff member could do if they were so inclined and had the capability. At least those networks tend to be only accessible by someone on the premises, so even with a network-level attack (as opposed to a physical access one) it's not like random people outside the org have access, unlike a cloud hosting service. Nor is PXE in constant use every time a PC boots, as the OS is local, only for reimaging, nor indeed are we using IPv6 internally for PC networks, which is where this PXE vulnerability is.

(IPv4 is ample for a network our size, and our ISP still does not support IPv6 - we have a test network with a 6-in-4 gateway so we're ready for when it's eventually needed)

We also only have our PXE deployment on a small subsection of VLANs, not the whole org, and certainly not on the general-access VLANs such as those used by BYOD laptops, so hopefully the vector for an infected personal device doing something automated is limited, but still, sigh.
B
Desktop deployments are a less scary vector because they're at-request and usually monitored. If you're a support tech, you usually know if a machine you're imaging has PXE-booted the wrong image.

The danger for this is datacentre and/or thin-client, where machines boot autonomously. Datacentre's even worse because you might boot machines autonomously and headlessly, so the chance of a malicious machine gets even worse.

That said, you should only have PXE services on a secure VLAN, just like you should have management interfaces on a separate VLAN. At this stage, you should also have network-access control in your buildings (wired & wireless 802.1x, mac-locked ports where .1x isn't an option) as well.
Yes, we're probably doing it wrong and this might be a sufficient trigger to redo our model.

Basically we've got large venues full of PCs that are re-imaged every three to six months. By default the PC does a network boot check, driven by DHCP variables, that uses PXE to check with System Center if there is a deployment advertisement for that machine. If yes, then dump the advertised task sequence, if not, exit PXE and boot the first disk. Our servers have network boot disabled, we do know that risk. ;)

Budget constraints = no NAC/NAP solution, therefore no regular deployment VLAN because of static VLANs on the ports. Yes we should be doing press F12 to select boot device and defaulting to hard disk, but would probably get pushback from the interns who would then have to run around to 200 machines and manually intervene.

This probably needs to change soon. I'm thinking something in the task sequence that can switch the UEFI to boot first disk/Windows Boot Manager first and then the ability to change that remotely when re-imaging is necessary.

Suggestions would be appreciated. This evolved out of System Center's recommended process from several years ago.