Project ONIE: UEFI support, and Firmware Update Mechanism

Yesterday Curt Brune of Cumulus Networks announced the latest release of Project ONIE, by the Open Compute Project:

This release contains a number of new hardware platforms, along with the usual enhancements and bug fixes. Some firmware excerpts from the announcement:

Updated x86 design specification to cover UEFI support:

Support for UEFI firmware machines:
42c7448 UEFI: initial support for ONIE on UEFI
a16e630 kvm_x86_64 vm: Update INSTALL instructions for UEFI

Firmware Update Mechanism:
a8e712b pending firmware update discovery mechanism
477cd47 x86 firmware update: add onie-fwpkg CLI tool

More Information:

Cumulus ONIE firmware vulnerability

Last week at Black Hat Briefings, Gregory Pickett gave a presentation focusing on firmware security issues of the Cumulus ONIE:

Staying Persistent in Software Defined Networks
Gregory Pickett
“The Open Network Install Environment, or ONIE, makes commodity or WhiteBox Ethernet possible. By placing a common, Linux-based, install environment onto the firmware of the switch, customers can deploy the Network Operating Systems of their choice onto the switch and do so whenever they like without replacing the hardware. The problem is, if this gets compromised, it also makes it possible for hackers to install malware onto the switch. Malware that can manipulate it and your network, and keep doing it long after a Network Operating System reinstall. With no secure boot, no encryption, no authentication, predictable HTTP/TFTP waterfalls, and exposed post-installation partition, ONIE is very susceptible to compromise. And with Network Operating Systems such as Switch Light, Cumulus Linux, and Mellanox-OS via their agents Indigo and eSwitchd not exactly putting up a fight with problems like no authentication, no encryption, poor encryption, and insufficient isolation, this is a real possibility. In this session, we’ll cover the weaknesses in ONIE, ways to reach the platform through these Network Operating Systems, and what can happen if we don’t properly protect the Control Plane these switches run on. I’ll even demonstrate with a drive-by web-attack that is able to pivot through a Windows management station to reach the isolated control plane network, and infect one of these ONIE-based switches with malware, malware that’s there even after a refresh. You’ll even get the source code to take home with you to see how easily it’s done. Finally, we’ll talk about how to compensate for these issues so that your network doesn’t become infected with and manipulated by this sort of persistent firmware-level malware.”

The slides, whitepaper, and sample code are now online:

Click to access us-15-Pickett-Staying-Persistent-In-Software-Defined-Networks-wp.pdf

Click to access us-15-Pickett-Staying-Persistent-In-Software-Defined-Networks.pdf

Also last week, Nolan Leake of Cumulus Networks wrote a story from the other side of a Black Hat vulnerability, of his interactions with Gregory:

Gregory Pickett of Hellfire Security reached out to me last Wednesday about some interesting research he is presenting tomorrow at Black Hat USA. There are two parts to his research: a security bug in Cumulus Linux (that we already patched) and other network operating systems, and a serious design issue with how all network switches are designed and built. […] The much more serious issue he will present is the exploitability of firmware in all network switches. This same exploitability has been known about in servers, laptops and PCs for years (and in some cases mitigated with technologies like Trusted Platform Modules), but its application to networking devices is new. […]”

Read the full blog here:

And of course, if you use Cumulus products, make sure you’ve applied their recent updates!