Black Hat USA 2017 - Firmware is the new black?

Happy to be back from Black Hat in Las Vegas. I usually capture photos of my journey, but I must have lost my head on this trek

since I only captured a couple notable shots, including

and

Regarding the event itself, our presentation for https://www.blackhat.com/us-17/briefings.html#firmware-is-the-new-black-analyzing-past-three-years-of-bios-uefi-security-vulnerabilities can be found at https://github.com/rrbranco/BlackHat2017. I can  nowsafely hang my badge

among my dog pile of other badges.

In that archaeological pile I can find residue of preceding security conf presentations - ToorCamp https://twitter.com/toorcamp?lang=en 2012, BSides https://twitter.com/bsidesseattle?lang=en 2013, ToorCamp (again) https://twitter.com/toorcamp?lang=en  2014, and CanSecWest https://twitter.com/cansecwest?lang=en 2015.   

I was honored to be among the list of other speakers.

Surprisingly, I wasn't the last name on the list.

My Intel colleagues included Rodrigo from the offense side, I treated defense, and Bruce talked about response.

The talk began with an overview of the ecosystem, including the supply chain that often begins with the open source upstream. Within that upstream many of the core protection, detection and recovery UEFI-based EDKII features were reviewed. This section of the talk culminated in many of the open source EDKII platforms upon which these protect/detect/recover features can be integrated. 

These platforms allows for marrying the rich set of core components https://github.com/tianocore/edk2 with representative platforms https://github.com/tianocore/edk2-platforms. The most evolved includes the first Intel(R) Core-based open source platform using EDKII platform code, described in https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Docs. The chipsec https://github.com/chipsec/chipsec project was also reviewed as one means by which to assess if the platform was configured correctly.

After the ecosystem and defense intro, the talk moved into the data set of issues and a proposed methodology. This portion of the talk generated the most interest, at least as evidenced by the number of people taking screen shots of the content.  This taxonomy included:

and a histogram of issue appearances

This class of information can help inform test strategies and investigation into new defenses.

After the data review, a cursory discussion of threat modeling was presented. This class of erudition also informs what type of defenses and testing needs to occur. Like the former topics, this portion of the talk wasn't intended to be complete so much as argue for the need to have this type of review with the broader research and platform building community.

And for any large effort, the collaborators for the deck and our colleagues are the most important part of the adventure.

The talk was picked up by the press ahead of time https://www.darkreading.com/vulnerabilities---threats/7-hardware-and-firmware-hacks-highlighted-at-black-hat-2017/d/d-id/1329442. We were approached by other publications to give an interview but interleaving day-job and conference ate up the available hours, I fear. Thanks to a Charlie Miller tweet https://twitter.com/0xcharlie/status/890692193383350272 at least there's some evidence that we made it to the stage

To close today's blog, this should not be the end of this material for 2017. I promised to reprise this talk for https://www.dc206.org/ at the lodge https://www.blacklodgeresearch.org/ in my backyard here in WA

    The TENTATIVE schedule for DC206 Meetings:

    Sep: Josh, Coffee Roasting

    Oct: Taylor, intro to Bash
    Nov: Vincent Zimmer of Intel, UEFI security
    Dec+: CfP open

Hopefully I can recruit my co-presenters to trek up I-5 to help out, too.

Regarding a prediction for 2015

Given it is the final day of 2014, I thought that my final blog of 2014 would treat the year.next which commences in a few hours, maybe with another one of my infamous TL:DR-style postings? Specifically, I'd like to build upon missive from Tim Lewis at http://uefi.blogspot.com/2014/10/security-to-eclipse-user-features-as.html wherein he shared his belief that security concerns in the platform firmware will predominate as the top user story of 2015. Given the sampling below from 2014, he may be observing an unenviable trend line.

Regarding that trend, there have been talks at several venues in 2014, such as the Black Hat (BH) talks a few months ago https://www.blackhat.com/docs/us-14/materials/us-14-Kallenberg-Extreme-Privilege-Escalation-On-Windows8-UEFI-Systems.pdf. This talk had an associated CVE http://www.kb.cert.org/vuls/id/552286 and white paper https://www.mitre.org/sites/default/files/publications/14-2221-extreme-escalation.pdf.

In addition, just this week there were a couple of talks featured on UEFI at the Chaos Communications Conference (CCC), including https://www.youtube.com/watch?v=5BrdX7VdOr0 and the associated presentation https://frab.cccv.de/system/attachments/2557/original/AttacksOnUEFI_Slides.pdf
by researchers from Bromium and Mitre, respectively.

The other CCC talk was on EFI and Thunderbolt https://www.youtube.com/watch?v=5BrdX7VdOr0. Glad to hear from the Matthew Garrett question to the presenter near the end of the talk that the option ROM vulnerability could have been mitigated if the Apple platforms implemented UEFI Secure Boot with option ROM verification (i.e., UEFI Driver Loading) enabled.

These security events and broad use of UEFI and edk II-based platforms definitely argue for the need to have additional industry coordination. This is a role that CERT has done admirably, but as Tim noted, they are now joined by the UEFI Security Response Team (USRT) http://www.uefi.org/security. This effort has been followed by a more code base-specific effort, too http://tianocore.sourceforge.net/wiki/Security. I am happy to be involved in both and although my CVSS-Fu isn't too evolved yet, I'm trying my best in writing technical advisories and doing the associated grading.

It is interesting that the references for both BH and CCC  https://www.youtube.com/watch?v=5BrdX7VdOr0 talks above cite the Intel Framework Specifications at www.intel.com and not the superseding UEFI Platform Initialization (PI) specifications http://www.uefi.org/sites/default/files/resources/PI_Spec_1.3.zip. This might contribute to some of the ambiguity seen in the boot script implementations, for example, noted in the CCC talk, since the Intel Framework specifications are frozen after having been contributed to the UEFI Forum. Maybe posting a ZIP of the PI specs and a PDF of the Framework makes the latter more search-engine friendly?

For the CCC talk https://frab.cccv.de/system/attachments/2557/original/AttacksOnUEFI_Slides.pdf, it was good to see that slide 53 mentions the work done with my Intel colleague

      [11] A Tour Beyond BIOS:
      Implementing S3 Resume with EDK2 –JiewenYao and Vincent Zimmer,
      October 2014

Jiewen and I designed features like the Lock Box protocol https://github.com/tianocore/edk2-MdeModulePkg/blob/master/Include/Protocol/LockBox.h to allow for protecting the boot script memory, via SMM or other container, back in 2009. But issues in seeing the protections deployed are compounded by the sheer difficulty in implementing S3 resume in platforms. Specifically, getting the functionality correct and having less-easily testable properties like securing the boot script has proven challenging. As a platform developer the last call you want to hear during product development is from the SQA team, saying "Everything works great, but our S3 resume testing fails once out of 10,000 times."

The above S3 document represents part of an effort to document some of the design intent on edk II source artifacts. We already have architectural intent documents such as http://www.cs.berkeley.edu/~kubitron/courses/cs194-24-S14/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf (including the companion talk https://www.youtube.com/watch?v=lZ505uz1TZ4).

Regarding other defenses, in the S3 talk Corey also mentioned the "SMI Transfer Monitor" (STM). Corey's co-presenter Rafal discusses the STM in more detail at http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf. This is also mentioned in CCC 2013 talk http://events.ccc.de/congress/2013/Fahrplan/system/attachments/2266/original/Gal_Diskin_-_Virtually_Impossible_-_30C3__release_version_.pdf by former Intel researcher Gal Diskin.on slide 13. Chapter 13 of Grawrock's 2nd edition of Safe Computing http://www.amazon.com/Dynamics-Trusted-Platform-Building-Approach/dp/1934053171 also describes this feature. The gist of the STM is that it represents a usage of the peer-monitor capability in IA32, a hardware feature defined in chapter 34.15 of the Intel Software Development Manual (SDM) https://www-ssl.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html. There is a nice peer monitor overview at http://virtualizationtechnologyvt.blogspot.com/2011/07/vmx-and-smm-dual-monitor-mode.html. The use of the peer monitor, which is essentially virtualization controls in System Management Mode (SMM), allows for de-privileging today's ring 0 SMM code, such as that built responsive to the infrastructure in volume 4 of the PI 1.3 specification http://www.uefi.org/sites/default/files/resources/PI_Spec_1.3.zip. So when Corey said "where is the STM specification?", he was referring to the firmware convention for loading the STM, interaction with Intel TXT, and how to expose resource lists for which the guest SMM code can access. This class of firmware interaction is the "STM specification" and it is built upon the hardware specifications of the peer monitor virtualization capability treated in the SDM. The SDM is the bible for software-visible parts of IA32, i.e., the 'architecture.' The SDM hasn't changed over the last decade plus, whereas the STM specification has, er, evolved. 

I have spent quite a bit of time on SMM over the last decade plus, from having defined the Framework SMM CIS http://www.intel.com/content/www/us/en/processors/itanium/efi-smm-cis-v09.html infrastructure http://www.google.com/patents/US6848046, from which the present PI 1.3 SMM design has been derived, to collaborating on peer monitor and STM work. I'm a big fan of isolation technologies and trusted computing, but I'll have to pause here for this 2014 entry on this topic. If I were a smarter guy I would follow in the foot-steps of Fermat's Last Theorem and claim to have the final proof of solving the SMM security issues but excuse myself for today by noting that the answer is "too large to fit in the margin" of this blog http://en.wikipedia.org/wiki/Fermat%27s_Last_Theorem.

Just as a document cannot replace well commented codes, having more executable methods for assurance are always preferred. These include efforts such as the CHIPSEC work https://github.com/chipsec/chipsec which I also describe in http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_04_Intel.pdf and https://www.youtube.com/watch?v=aV1DSF4cwGw. These tests are run after boot and provide an a posteriori view of the platform.

More recent technology includes having security testability in-situ with the platform, versus a CHIPSEC style post-boot test, and reporting the results. This type of test and reporting capability was mentioned in 2013 at http://www.uefi.org/sites/default/files/resources/UEFI_Summerfest_2013_-_Microsoft_Hardware_Security_Test_Interface.pdf and now has a public specification realization at  http://msdn.microsoft.com/en-us/library/windows/hardware/dn879006.aspx (HSTI) This work bridges the semantic gap historically faced by platform builders wherein the various system requirements in a Windows Hardware Certification document, such as http://download.microsoft.com/download/7/0/E/70E74967-B0FE-477A-974F-C1ED16EE31DF/windows8-1-hardware-cert-requirements-system.pdf, can now have a companion reporting channel. Examples include injunctions in System.Fundamentals.Firmware.UEFILegacyFallback, such as

"An OEM may not ship a 64 bit system which defaults to legacy BIOS or loads legacy option ROMs if that system ships with a UEFI-compatible OS. When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded."

These Compatibility Support Module (CSM) behaviors are something that only the platform implementation can deduce and are difficult to detect via a later test, although heuristics like scanning 0xC0000p through 0x100000p in the address space 'could' be done.

The HSTI interface builds upon the Adapter Interface Protocol (AIP) class of structure defined in the UEFI 2.4 specification http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf. Since AIP producers are boot service only, a pre-OS agent needs to query the HSTI interface in order to cull the settings and convey the results into the operating system run time, if needed, in a vendor-specific fashion.

Related work to HSTI that goes beyond mapping to Windows requirements include the ability to report BIOS Integrity Attributes, as described in http://csrc.nist.gov/publications/drafts/800-155/draft-SP800-155_Dec2011.pdf in 3.2.1.1. And in order to surface this information, we defined in http://www.trustedcomputinggroup.org/files/static_page_files/D4268663-1A4B-B294-D05DE87EE90558B6/TCG_EFI_Platform_1_22_Final_-v15.pdf the following:

    typedef struct {

       UINT32 VendorId;

       EFI_GUID ReferenceManifestGuid;

    } TCG_Sp800-155-PlatformId_EventStruct

This structure can be used to reference an off-machine Reference Manifest (RM). The idea is that the GUID in the structure above would be specific to a vendor, model, and firmware instance in a XML-based manifest document on the platform suppliers website. The schemas are defined in http://www.trustedcomputinggroup.org/files/resource_files/73638609-1A4B-B294-D0902CC2A13C8697/Reference_Manifest_Schema_Specification_v2.0.r5.pdf, so now it's a set of work items for the industry to map the RM's to platform attributes, such as mentioned in 155.

Who knows, at some point maybe these reporting and testing efforts will all align?

Well, if you have gotten this far, the 'Didn't Read" portion of "Too Long, Didn't Read" (TL;DR) hasn't been the case for you. I'm not sure whether to reward you for your stoicism or not for wading through this entry.

To summarize, 2014 has shows a spate of security-related activities, both by the attackers (BH, CCC) and the defenders (USRT). The firmware-producing and consuming community is acutely aware of assurance concerns and new testing methodologies have been deployed in '14 and are coming in '15, too, including HSTI. I don't necessarily subscribe to the 'Spy versus Spy' aspect of security, or fall into existential angst that the "Defenders Dilemma" is not solvable. Instead, I see many parties passionate about having robust, usable systems and collaboration on art to achieve those goals. Open source, open documentation, open specifications, open platforms,.... All help in the cause.

And if you're still working these last hours of today, pause and have a coffee.

Also, enjoy a happy and safe new year.

Cheers,

V.Z.兹梅