The BMC in OpenBMC stands for 'Burglarize My Computer' – thanks to irritating security flaw

Pantsdown vulnerability affects various BMC stacks as well as OpenBMC on systems using two particular Aspeed chips

An oversight in the firmware for various baseband management controllers (BMCs) can be exploited by miscreants to bury spyware deep inside a server, potentially poisoning it for the next owner.

Malware successfully abusing this security blunder can remain invisible to hypervisor, operating system, and antivirus software, can survive reboots and disk wipes by hiding in the BMC flash memory, potentially infect the OS, and get up to all sorts of other mischief. It requires root-level access to exploit this particular flaw. It affects at least some x86-64 and IBM OpenPOWER boxes, we're told, and is not tied to any particular host CPU architecture.

One attack scenario would involve an admin reprogramming the BMC chipset so that the next owner of the machine is secretly snooped on by spyware. A system tainted this way could be a bare-metal server in a cloud or data center, cycled through customers as required, or a box resold to a victim. Whoever was using the machine next would likely be none-the-wiser that bootkit-level malware was lurking in the endpoint's motherboard firmware.

The impact of the security hole will depend greatly on how an organization's data center is architectured. Large cloud providers, for instance, typically use their own customized BMC firmware that may not be susceptible to this particular attack, or assume the BMC is under the server admin's control anyway and partition the box accordingly from the rest of the network. Smaller platforms and corporations may not have as tight security, and may be vulnerable to this attack.

Christopher Lee as Dracula

You dirty DRAC: IT bods uncover Dell server firmware security slip

READ MORE

BMCs are typically chipsets on server motherboards that are a computer within the computer: they can manage hardware, power-cycle the box, change or reinstall the operating system, and so on, remotely over the network or some other communications channel, allowing sysadmins to perform maintenance from afar without having to get up and pull a machine out of the rack.

As such, the BMCs wield a lot of power.

Bug-hunter Stuart Smith of IBM's Linux Technology Center claimed on Wednesday that the flaw is present in multiple BMC firmware stacks, including the Linux Foundation's OpenBMC, SuperMicro's BMC code, and AMI BMC firmware.

Dubbed "pantsdown" for useless branding purposes, the vulnerability CVE-2019-6260 is specifically locked to BMC chips made by Aspeed Technology: the AST2400 and AST2500 in particular. If your machine sports these controllers, and you're running a vulnerable BMC firmware stack, you should ask your vendor about patches.

The problem is that these controllers expose their private physical memory and IO ports to the host processor, via Advanced High-performance Bus (AHB) bridges, allowing software on the host server to fix and debug the BMC during development. These accesses occur with virtually no security.

"The LPC, PCIe and UART AHB bridges are all explicitly features of Aspeed’s designs: they exist to recover the BMC during firmware development, or to allow the host to drive the BMC hardware if the BMC has no firmware of its own," said Smith. "The typical consequence of external, unauthenticated, arbitrary AHB access is that the BMC fails to ensure all three of confidentiality, integrity, and availability for its data and services."

That means a rogue admin, or malware that's managed to get superuser privileges, can access the BMC directly via the server's internal buses, and screw around with it by rewriting its firmware code, changing settings in RAM, siphoning off its memory, opening configuration consoles, and so on, if the system is vulnerable. Really, the BMC firmware should program the controller to lock down these hardware interfaces so they cannot be exploited from the host processor.

Two execs in a server room. Has to have happened some time heh. Photo by Shutterstock

Can we talk about the little backdoors in data center servers, please?

READ MORE

An Aspeed spokesperson acknowledged there is a security issue with its controllers. IBM is also aware of the hole in some of its OpenPOWER servers as a result. We note Smith's post has a list of workarounds for the pair of system-on-chips, along with proposed patches for OpenBMC, that you should check out as it goes into the issue in greater depth.

The Linux Foundation says the OpenBMC team is in the process of writing a security alert of its own, which you should keep an eye out for as it should explain the next steps needed to address the vulnerability. OpenBMC versions up to at least 2.6, running on the aforementioned Aspeed chips, are at risk, according to Smith.

A spokesperson for AMI confirmed its products are affected, and a fix is due to land in February. So far, it's early days: finalized baked patches and official advisories aren't available right this second, it appears. IBM customers affected by this security snafu can try updating to the latest op-build, as version 2.0.11 onwards contain necessary fixes, we're told.

In most cases, the vulnerability is not a huge risk, as it requires privileged superuser access to exploit, and if a bad person has root on your server, it's pretty much game over anyway. However, as we said, some bare-metal cloud deployments could be vulnerable to attack.

Additionally, Smith noted, a miscreant could potentially brick the BMC until the next reboot by disabling its clock signal from the CPU, or just randomly power-cycle the machine to knock services offline. He also credited Andrew Jeffery, Benjamin Herrenschmidt, Jeremy Kerr, Russell Currey, and others, for their help in researching this BMC headache.

Smith said he plans to publish a proof-of-concept application, through IBM, in the near future. The PoC will require root, and is designed to allow vendors and admins to test if their servers are vulnerable. Then folks will know who to pester for fixes. ®




Biting the hand that feeds IT © 1998–2019