Richard Wilkins of Phoenix Technologies has an article in Embedded Computing about UEFI-based IoT security:
[…]This article is focused on system startup/firmware and the potential security problems for IoT devices in that space. And most important, what to do about them.[…]
PS: RANT… for some reason, one sentence jumped out at me:
“So why isn’t everyone using UEFI firmware? If the UEFI architecture provides the “solution” to these security threats, why isn’t everyone using it?”
I think the answer: UEFI is *A* solution, there are other solutions. Coreboot with Heads is another solution. Coreboot with Verified Boot is another solution. Using TXT and TPM measurements are other layers. Hypervisors/TEEs/SEEs are another layer. Separate security processors are another way. What is the right way, why isn’t everyone using one way? While I am a UEFI Forum member, I don’t think UEFI everyone should be using it. I welcome firmware diversity. 🙂 IMO, there are multiple implementations of signed code, signed updates, and a signed boot-up process, controlled by multiple (not a single) organization. I’m still hoping to see some professor gets a grad student to write a report doing a proper comparision of the various modern firmware security implementations’ strengths, so someone can start to make a reasonale decision as to which firmware security architecture is the solution for them.
I just noticed a new UEFI bootkit on Github which I’d never heard of:
“UEFI-Bootkit: A small bootkit designed to use as little ASM as possible. Thanks to pyro666”
I sent a FYI to the UEFI Security group before posting about it to this blog, in the name of responsible disclosure. Dick Wilkins of Phoenix Technologies– and of the UEFI Forum’s Security Response Team (USRT) — replied with his input on the code:
“I just took a quick look at this code in github. It looks like the typical UEFI application that changes the configuration and could cause unexpected things to boot. The unexpected stuff could damage the system and then continue to boot up normally but compromised. This is exactly why Secure Boot was needed. If Secure Boot is disabled (or not implemented), there are many ways to insert code into the boot path and compromise a system. If Secure Boot is enabled, this code and any code like it would not be properly signed and would never run. There is nothing new here. This is why end users must be discouraged from disabling secure boot and running non UEFI Secure Boot aware systems.”
The PDFs of the presentations from last months’ UEFI Forum plugfest have been uploaded to uefi.org.
(scroll about half-way through the page, after the Youtube videos…)
* System Prep Applications – Powerful New Feature in UEFI 2.5 – Kevin Davis (Insyde Software)
* Filling UEFI/FW Gaps in the Cloud – Mallik Bulusu (Microsoft) and Vincent Zimmer (Intel)
* PreBoot Provisioning Solutions with UEFI – Zachary Bobroff (AMI)
* An Overview of ACPICA Userspace Tools – David Box (Intel)
* UEFI Firmware – Securing SMM – Dick Wilkins (Phoenix Technologies)
* Overview of Windows 10 Requirements for TPM, HVCI and SecureBoot – Gabe Stocco, Scott Anderson and Suhas Manangi (Microsoft)
* Porting a PCI Driver to ARM AArch64 Platforms – Olivier Martin (ARM)
* Firmware in the Data Center: Goodbye PXE and IPMI. Welcome HTTP Boot and Redfish! – Samer El-Haj-Mahmoud (Hewlett Packard)
* A Common Platforms Tree – Leif Lindholm (Linaro)
This’ll be a very short blog, as I’m busy reading 9 new PDFs… 🙂 I’ll do blogs on some these specific presentations in the coming days.