A Secure Development Lifecycle for Firmware: Your Unanswered Questions, Answered

The UEFI Forum recently hosted a new webinar as part of its educational webinar series titled “How to Create a Secure Development Lifecycle for Firmware.” Presenters discussed how, while firmware is software for your hardware, it operates in a different environment than most software, and thus vulnerabilities can have a greater impact. A secure development lifecycle can help combat these vulnerabilities and the associated challenges that follow an attack. You can watch the recorded presentation and view the webinar slides to learn more.

The following questions were asked by attendees of the live webinar and answered by featured panelists.

Q: What is your opinion on unit testing vs. general fuzz testing if you had to pick only one?

A: Our opinion is that you don’t pick just one testing method. Attackers use a variety of methods, so there is no single testing approach that provides total coverage.

Fuzz testing is a great example. At an OS level, fuzz testing may be considered part of integration testing for an application that takes user inputs (example: malformed URLs in a web browser). For firmware components like UEFI PI drivers, fuzz testing is a valid unit test to exercise interfaces between other UEFI PI modules (example: trying to generate a buffer overflow by passing malformed data to a UEFI protocol).

Q: What is a DediProg?

A: DediProg is a brand name for an IC Programming tool commonly used by firmware developers.   (Available from www.dediprog.com). This device is plugged into to a connector on a development motherboard and allows the developer to load initial or replacement firmware on a board under test. When a board design moves from development to production, the DediProg connector is typically removed or designed away entirely on boards shipped to customers.

Q: Can consumers audit the firmware? If so, how?

A: There are a variety of tools that can allow a consumer to inspect firmware images. CHIPSEC and UEFI Tool are two tools that can analyze a firmware image and allow a consumer to inspect its contents.  CHIPSEC has a blacklist of UEFI modules which include a tool that will check a ROM image for blacklisted modules.

Q: How do Baseboard Management Controllers (BMC) create threats to UEFI? Can you please give some examples?

A: The firmware associated with BMCs is typically updated even less frequently than that of the Platform Firmware (BIOS). It may also run on less secure, older designed microprocessors. There have been many successful attacks on BMCs. A presenter at a recent BlackHat conference showed an operating system successfully attacking the local BMC and then using that BMC to attack all the other BMCs on the private, air-gapped, backend management network. Many BMCs are given rights to update local UEFI firmware and may bypass checks done for other types of firmware updates.

Q: Are measurements used immediately on modern UEFI platforms or only for remote attestation?

A: The UEFI secure boot code uses “measurements” of code before it is executed to ensure damaged or modified code is not executed. Most UEFI implementations will also store measurements of code and settings into the PCR registers of a TPM device. This device and these measured values may be used to protect platform secrets (i.e. bitlocker passwords) as well as be used for various types of remote attestation. The Trusted Computing Group (TCG, not affiliated with the UEFI Forum) is working on a specification for how to enable the remote attestation described in the proposed NIST 800-155 guidelines.  

Q: Can you give a high-level overview of how UEFI firmware works with Intel® Boot Guard?

A: There is an overview of Intel Boot Guard in the EDK II “Understanding the UEFI Secure Boot Chain” technical briefing.

https://edk2-docs.gitbooks.io/understanding-the-uefi-secure-boot-chain/secure_boot_chain_in_uefi/intel_boot_guard.html

Q: My employer is worried about manufacturing attacks, as manufacturing is core to our business. Considering that UEFI Secure Boot just checks signed binaries that are loaded from BDS phase on, how do you protect a platform from an employee that added a UEFI driver that is not signed at the BIOS image during manufacturing (at BIOS compilation process for example)?

A: There are two versions of this attack: The first type is a bad actor inside the company (“the attack is coming from inside the house”) and the second type is someone modifying the official firmware by trying to insert a malformed driver (an attack the official release). The second type of attack is easier to address if the original manufacturer properly signed the image (broken signature in UEFI Capsule Update will stop this update). The first case is more difficult, since it’s a physical security issue for the company and harder for external methods like UEFI Secure Boot to catch. UEFI Secure Boot is part of a complete platform security solution.

Q: What is your preferred methodology for SDL: Waterfall, Agile or DevOps and why?

A: Most software development has been moving to an Agile approach to code creation. This approach works well as it gets functional code to the customer quickly and then updates and adds functionality with frequent new releases. On the other hand, Agile development does not work well for safety-critical code, security-critical code, or code that has real-time requirements and manipulates hardware directly. The detailed design and up-front planning of the Waterfall approach to development is typically better in these cases. Platform firmware falls into the last two categories where more traditional, waterfall project approaches are generally more successful. The DevOps technique for code development typically combines Agile and IT operations together to develop new code. This does not fit well for firmware.

Q: What is your opinion about using formal methods such as model checking to verify security properties in firmware?

A: Formal methods are a good approach, however they’re a very targeted approach and a lot of assumptions need to be made. This can’t happen for all parts of firmware, but for security-critical pieces they are a good approach. Formal methods are a less mature approach at this point, it’s an area in development. It’s very difficult to do large quantities of code, but for a critical, small section of code, it could be a good idea to apply to that kind of validation/checking/code reviews etc. of management mode code.

Q: How prevalent, applicable and practical is the use of fuzzers and fuzz testing for low level firmware components in SDL?

A: Most fuzz techniques available were originally designed for upper level software. The place where we found the best application is in unit testing specific components, before they’re integrated into UEFI. Because of the driver model in UEFI, you tend to have dozens of individual components that are compiled for UEFI PI (PEI & DXE phases). Using fuzzers in unit testing is most effective on verifying low-level UEFI PI interfaces prior to integration. Some of the instructions, such as the hardware-based instructions, aren’t modeled within fuzzers or symbolic execution environments. It takes time to execute and doesn’t require a special hardware emulation, but you can potentially “brick” the system and require a hardware flash programmer to recover. It’s an area that’s being explored, but it’s harder when you start to interface with the hardware.

If you’re interested in using fuzzers for UEFI component unit testing, please check out the “Host-based Firmware Analyzer (HBFA)” at TianoCore. https://github.com/tianocore/tianocore.github.io/wiki/Host-Based-Firmware-Analyzer