DarkReading article on firmware protection

Yuriy and John of the Intel CHIPSEC team are quoted in a new Dark Reading article on firmware security.

[…] Yuriy Bulygin and John Loucaides, security researchers at Intel Security, point out that hackers attack firmware because they know many security and IT managers aren’t paying attention to it. They say security teams are so overwhelmed by the prevailing threat landscape, that they have their hands full just deploying the basics, like firewalls, intrusion prevention systems and sandboxes. […]



CHIPSEC training at REcon

The Intel CHIPSEC team doesn’t give training often, so when they do, it is worth mentioning.

Like last year, CHIPSEC will be offering training at REcon!

A variety of attacks targeting system firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, OS loaders and secure booting. This training will detail and organize objectives, attack vectors, vulnerabilities and exploits against various types of system firmware such as legacy BIOS, SMI handlers and UEFI based firmware, mitigations as well as tools and methods available to analyze security of such firmware components. It will also detail protections available in hardware and in firmware such as Secure Boot implemented by modern operating systems against bootkits. The training includes theoretical material describing a structured approach to system firmware security analysis and mitigations as well as many hands-on exercises to test system firmware for vulnerabilities. After the training you should have basic understanding of platform hardware components and various types of system firmware, security objectives and attacks against system firmware, mitigations available in hardware and firmware. You should be able to apply this knowledge in practice to identify vulnerabilities in BIOS and perform forensic analysis of the firmware.



LUV-live 2.0-RC4 released

Ricardo Neri of Intel announced Linux UEFI Validation (LUV) v2.0-rc4 release, with lots of changes, new versions of CHIPSEC, BITS, FWTS, and multiple UEFI improvements in LUV. IMO, one of the most important features it that LUV-live’s CHIPSEC should properly log results now! Excerpts from Ricardo’s announcement:

This release touches many areas. Here are some highlights:

Naresh Bhat implemented changes to build from Linus’ tree when building LUV for ARM. While doing this, he got rid of the leg-kernel recipe. Now the kernel is built from linux-yocto-efi-test for all architectures. Also, he took the opportunity to remove some of the LUV-specific changes we had in the meta layer (i.e., our genericarmv8 machine). It always good to restrict ourselves to the meta-luv layer, unless we plan to upstream to the Yocto Project. Now LUV for aarch64 is built using qemuarm64.

It was reported that CHIPSEC was not running correctly in LUV due to missing configuration files and Python modules. This release includes a major rework of CHIPSEC integration into LUV. It ran correctly on all the systems in which we tested. Also, we bumped to v1.2.2; the CHIPSEC latest release.

This release includes new functionality to build BITS from its source rather than just deploying its binaries. BITS is a challenging piece of software when it comes to integration into a bitbake recipe. The build process was broken into several steps. This work help for future work to customize BITS for other CPU architectures and netboot.

The UEFI specification v2.5 includes a Properties Table for the memory map. Under this feature, it is possible to split into separate memory sections the code and data regions of the PE/COFF image. Unfortunately, kernels previous to v4.3 crash if this features is enabled. We have backported a fix pushed to Linux v4.3. We will be bumping the kernel for x86 to 4.3 in our next release.

The EFI stub feature in the kernel allows to run the kernel as an EFI application. Also, it allows the kernel to parse the memory map directly from the firmware rather than taking the map from the bootloader. This is clearly advantageous in case of bugs in the bootloader.

Now that LUV support storing the results of multiple bots, it may happen that disk runs out of space. Gayatri Kammela made updates to increase the size of the results partition and issue a warning when available space runs below 2MB.

Finally, keeping up with the latest changes in the Yocto Project has paid off handsomely. This release is based on Jethro, the latest version of the Yocto Project. Rebasing to this new version as done with very little effort. In the LUV tree you can find the jethro and jethro-next branches; the bases of this release. The fido and fido-next branches are still maintained.

We have bumped the following test suite versions:

 *FTWS is now V15.12.00
 *CHIPSEC is now v1.2.2
 *BITS is 2005

Time to update your LUV-live images! It is a Release Candidate, so please help the LUV team by testing it out and pointing out any issues on the LUV mailing list. This version of CHIPSEC includes VMM tests, so time to test LUV-luv in your virtual machines, not just on bare-metal boxes.

Many people contributed to this release, including: Ricardo Neri, Naresh Bhat, Darren Bilby, Megha Dey, Gayatri Kammela, John Loucaides, Sai Praneeth Prakhya, and Thiebaud Weksteen. It was nice to see the LUV and CHIPSEC teams work together in this release!

More information:



Intel ATR on firmware security threats

Jim Walter, Director of Advanced Threat Research for Intel Security, with contributions from Yuriy Bulygin and John Loucaides, wrote a blog for Dark Reading that summarizes some recent firmware attacks.

Vulnerable From Below: Attacking Hypervisors Using Firmware And Hardware
Malicious attacks with firmware privileges can compromise an entire system, so it is especially important to apply measures to reduce the risks.

Read the full article here:





Intel firmware security research at WOOT

Usenix WOOT 2015 is happening in Washington D.C. later this month. It has a very interesting UEFI security talk:

Symbolic execution for BIOS security
Oleksandr Bazhaniuk, John Loucaides, Lee Rosenbaum, Mark R. Tuttle, Vincent Zimmer, Intel Corporation
May 25, 2015

We are building a tool that uses symbolic execution to search for BIOS security vulnerabilities including dangerous memory references (call outs) by SMM interrupt handlers in UEFI-compliant implementations of BIOS. Our tool currently applies only to interrupt handlers for SMM variables. Given a snapshot of SMRAM, the base address of SMRAM, and the address of the variable interrupt handler in SMRAM, the tool uses S2E to run the KLEE symbolic execution engine to search for concrete examples of a call to the interrupt handler that causes the handler to read memory outside of SMRAM. This is a work in progress. We discuss our approach, our current status, our plans for the tool, and the obstacles we face.

There might be other interesting talks happening there, but none have BIOS/UEFI/firmware in their title/abstract, so I missed them. 🙂