UEFI News and Commentary

Friday, August 04, 2017

So What Does Security In IoT With UEFI Really Look Like?

As usual, security continues to dominate the news about UEFI. DEFCON had several presentations related to firmware security. There is a good overview of the hardware and firmware attacks discussed over at Dark Reading. This included one by my friend Vincent Zimmer and his colleagues at Intel analyzing over 90 reported firmware vulnerabilities over the past 3 years. He discusses his experience on his blog. Another, by security researcher Alex Matrosov described exploits and called out specific computer models. Then there was some stuff on using CHIPSEC to detect improperly configured chipsets.

As often as I deal with security issues in firmware, I am still ignorant of how the types of exploits that are available and the tools that are used by cyber-security professionals. There are always new kits coming out, with new features. But where do you get them and how do you use them safely without making you and your computer system a target-rich environment? Recently the CS2AI of Sacramento hosted two lectures. The first lecture focused on giving the nuts and bolts (step-by-step) of setting up your own environment, including virtual machines, TOR and Kali and even configuring a cheap Raspberry Pi as an analysis tool. The second lecture focused on the tools available under Kali, such as password hash crackers (with an up-close hack that used it), Sparta and Wireshark for network analysis and then an introduction to using Tor to venture onto the dark net with Tor. Why the dark net? So that you can see how much it costs to buy a hack of your company or a company that you care about!

Next month will be wireless attacks and the tools that sniff out vulnerabilities. Good stuff.

Security today has a lifespan-in hours, or maybe in months or years. My firmware job is to keep your system secure for the duration of one boot.

Wednesday, June 07, 2017

UEFI Releases New Specifications and Adds ARM to the Board

For anyone who has been working on the UEFI specification, for the past few years, it should be no surprise to hear that UEFI has decided to welcome ARM onto the board of directors. This shows the growth of interest in firmware standards by the non-x86 world and also recognizes ARM's outstanding level of effort to improving the specifications. Dong Wei, who was the vice president of UEFI while at HP, now returns to the same role but now from ARM, where he is the senior director platform architecture. This seems like a smart move on both sides.

This announcement came on the heels of the release of a spate of new spec and test tool revisions. There are a whole bunch of goodies in here, from wifi and BlueTooth to new SMM (now called MM) models (including TrustZone!).

There are rumblings about another UEFI plugfest in the works. More on what's changes in the specs and other industry happenings later.

Thursday, June 01, 2017

UEFI Security In The News: Craigslist, Zimmer & Cyber-Security Meet Ups

Using a UEFI-based BIOS on a MacBook Pro/Air and forgot your password and live in New York, New Jersey or Connecticut? Craigslist to the rescue! From the ad:
REMOVAL PROCESS: the password removal process will NOT damage your Macbook or VOID your Apple warranty in any way we do not modify any hardware nor do we use any software to remove the password a professional external password analyser will be used to remove the EFI Firmware BIOS Password and/or the iCloud System Lock PIN Code the repair turnaround will take 1 HOUR
Not sure how this works and I don't have a Mac, but some people have done extensive reverse engineering to look at it and found it pretty solid. Barring access to a hardware flash programmer "...there is no way for an outsider to generate the codes to reset your Mac firmware. So please stop sending me emails and comments asking for it."

Meanwhile, everyone seems to be trying to hack the firmware, even to the point where firmware guys are starting to worry about how solid the firmware written by other guys really is. My friend and co-author Vincent Zimmer gives a pretty good round up of the current findings and presentations, including some of his own.

Meanwhile, the local chapter of CS2AI is sponsoring a series of security meetings that gathers local industry practitioners and educators together to discuss different topics surrounding IT and control-system security. Last time the focus was on "The Mind of a Cyber Attacker" The next topic will be Defensive Tools for Cyber-Security, hosted by Prof. Jun Dai at Sacramento State University. Recent sessions have been hosted by speakers from McAfee, Palo Alto Networks and Grimm. Good stuff, practical from the physical, hardware, software and network attacks.

Some OEMs are more paranoid than others. In the firmware world, that keeps us on our toes to engineer creative solutions that make systems buildable, shippable and usable but not vulnerable.

Sunday, May 21, 2017

Using C++ With EDK2, Part 1: new and delete

This is the first in a series of articles looking at what it takes to compile a UEFI C++ application under EDK2. This isn't an attempt to cover everything. I'm not a compiler library expert, so I'm not trying to port everything in the STL over. Nor am I a regular GCC user, so my efforts have been focused on Visual Studio 2015. Finally, I am focused on UEFI Shell applications, rather than normal UEFI apps or UEFI drivers.

I was initially intrigued by the fact that "#ifdef __cplusplus" occurs in several places. It appears in the StdLib header files, but that makes sense since they were originally a port from an environment that supported C++ and C. It also appears in the AutoGen.h files that are automatically created by the EDK2 build system for each module. It looks something like this:

#ifdef __cplusplus
extern "C" {


extern GUID  gEfiCallerIdGuid;
extern CHAR8 *gEfiCallerBaseName;

// Guids
extern EFI_GUID gEfiAuthenticatedVariableGuid;
extern EFI_GUID gEfiVariableGuid;

// Definition of PCDs used in this module
#define _PCD_TOKEN_PcdFlashNvStorageVariableBase  5U
PeimInitializeVariableServices (
  IN       EFI_PEI_FILE_HANDLE  FileHandle,
#ifdef __cplusplus

That is, all of the C symbols that are automatically included into the build have the extern "C" linkage specifier placed around them so that they will handle calls from either C or C++ source code. So someone was thinking about C++.

For my solution, which is checked in on SourceForge here, I started simply by handling the necessary support for the new and delete operators, with no support for exceptions. This C++ library depends on the StdLib C library that comes with EDK2. For the most part, the C headers would work just fine, but two critical files (MdePkg/Include/Base.h and StdLib/Include/sys/EfiCDefs.h) generate errors when pulled in to C++ code. For now, I simply created new, slightly modified versions to work around the minor issues. This requres that your .inf file list the new library before listing the StdLib.


This changes the include order so that, if there is a modified version for the C++ library, it will be preferred over the one in StdLib.

So far, only the new header file declares anything of substance. The others (wchar.h, stdlib.h, stdio.h) just provide wrappers for the StdLib that bring in the versions of Base.h and EfiCDefs.h that work with the library.

But the results are pretty nice. Assuming you don't need exception handling or the C++ standard library, you can use all of the normal C++ features, such as classes and inheritance and templates.

This is just the starting point. Over the next articles, I will expand the support for both the C++ and C libraries.

Wednesday, April 26, 2017

Maze Game Source Code

Feeling frustrated by the fact that I used bitmaps for all source code in the simple maze game articles I posted? Fret no more, the code has been checked in under BSD license here:


Look in Applications\Maze

Tuesday, April 11, 2017

Control Systems, UEFI & Cyber-Security

A few weeks ago, I had a chance to attend the meeting sponsored by the Control System Cyber Security Association International (CS2AI), They are working with experts like Dr. Jun Dai (professor at Sacramento State) and Martin Noufer (McAfee, Intel) to develop emphasize and develop security expertise.

The session started with an excellent overview of IoT security by Rahner James, who works with cyber-security solutions firm GRIMM and teaches a computer forensics course locally. His excellent presentation (which can be found here), his knowledge of industry war stories and his collection of fascinating little testing "devices" gave us insight into the range of possible attacks (hardware, software, social) and possible goals (theft, disruption). The large number of IoT devices and the low profit margins mean a high probability that there are a substantial number of devices on the net that are easily hackable.

One of the key points that was raised during the discussion that followed is how little help is given to software engineers to understand and defend against security issues in IoT devices. Market pressures demand quick deliver of functional (but not necessarily secure) hardware. Open source provides access to amazing security primitives, but also gives access to catastrophic security holes. The real answer is education, one of CS2AI's goals.

Education is certainly needed when it comes to UEFI and security. UEFI isn't for everybody in the IoT space, because of RAM and ROM size, but it does have a thorough security story with Secure Boot, Capsule Update and even User Identity. Working with well-designed hardware, UEFI helps guard the integrity of the flash device in which the firmware resides and the memory in which it executes. My colleague, David Chen, gave an excellent overview of some of these topics at the recent UEFI Plug-Fest in Nanjing. Others talked about SMM security, ARM security and flash update security.

The presentation we saw claimed that in 2020 there will be 50 billion IoT devices. Security for these devices is become a board-of-directors conversation topic: are our devices secure? What will you say when they ask you? What will you do when you're wrong?

[1] See Matthew Garrett's summary here.
[2] See a quick summary about AMD's stuff here.

Wednesday, March 29, 2017

UEFI Plugfest 2017 in Nanjing

My colleague from Insyde, David Chen, talking about security in UEFI
The UEFI Forum hosted a plug-fest and educational seminar in Nanjing, China this week. I have many fond memories of visiting this historic city over a period of 2-3 years.

For those that don't know, a plug-fest is an occasion where folks who provide the different parts of an industry standard ecosystem get together to make sure that they all play nicely together. So, for UEFI, this includes motherboard, plug-in card, OS, system application and BIOS vendors.

These events, along with the SCT (Self-Certification Test) tools, help the wildly diverse group of folks who use UEFI specifications to increase the chances that the blind-date scenario that is the PC industry works harmoniously.

The presentations are being posted on-line here. Insyde posted a few other pictures from the event here.

Sample Chapter from Harnessing the UEFI Shell

Not to be out-done by the Beyond BIOS book, another UEFI book has made an appearance: Harnessing the UEFI Shell. Two of the likely suspects (Zimmer and Rothman) are involved with both new editions (as they should be!) and I joined them on the latter since I write a lot of shell apps.

You can get a glimpse inside a sample chapter and the table of contents.