Tag: UEFI

UEFI 2.5 change list

~ hucktech ~ Leave a comment

I’ve been meaning to look more closely into version 2.5 changes in UEFI. So far, I’ve only looked at UEFI HTTP Boot, at a little at the NVMe passthru protocol.

Looking at the UEFI 2.5 spec from uefi.org, the initial pages of the document include it’s revision history.  It appears the UEFI 2.5 changes were done in two batches, February 2015 and April 2015. I’m listing the revisions below, with the “2.5” prefix and the “<Month> 2015” suffix removed, for clarity.

The number is the Mantis issue-tracking number, something only useful for UEFI Forum members. If you are a UEFI Forum member, you can presumably access their Mantis system and get more information about the changes. The public only has the title, and a useless Mantis number.  Perhaps the submitter for UEFI 2.5 mantis entry 1147 is the NSA or the Hacking Team? 🙂 We’ve no idea, the title for that change is “REDACT”. 😦

I wish the UEFI Forum would spend a few minutes in their release phase to give a paragraph or two of information about these changes. At minimum, they should mention where in the spec(s) this change impacts, if the new software feature will be in open source TianoCore implementation or only in commercial products. If the code is in TianoCore, it would be nice to mention the SVN build number, like the TiaonCore Security Advisories do — so you can compare the before/after in the code more easily. SVN build numbers would be more a lot useful to the public than the “<Month> <YEAR>” string added to the title of each revision entry.

Here are the UEFI 2.5 updates:

1071 New EFI_HASH2_PROTOCOL
1090 ESRT: EFI System Resource Table and component firmware updates
1091 Clarification of handle to host FMP
1103 Longer term New CPER Memory Section
1109 Smart Card Reader
1121 IPV6 support from UNDI
1147–REDACT
1163 Inline Cryptographic Interface Protocol proposal
1166 hash 2 protocol errata
1158 errata – boot manager clarification
1159 Proposal for System Prep Applications
1167 Persistent Memory Type support
1174 errata – Error in EFI_IFR_PASSWORD logic flowchart
1183 New Protocol with 2 Function for PKCS7 Signature Verification Services
1186 AArch64 binding clarifications and errata
1191 Add new SMBIOS3_TABLE_GUID in EFI_CONFIGURATION_TABLE
1199 Add NVM Express Pass Thru Protocol
1201 Exposing Memory Redundancy to OSPM
1204 new UEFI USB Function I/O Protocol addition to the UEFI spec
1212 UEFI.Next feature – HTTP API
1213 UEFI.Next feature – HTTP helper API
1214 UEFI.Next feature – HTTP Boot
1215 UEFI.Next feature – DNS version 4
1216 UEFI.next feature – DNS version 6
1217 UEFI.Next feature – WIFI support
1218 UEFI.Next feature – EAP2 Protocol
1219 UEFI.Next Feature – UEFI TLS API
1220 UEFI.Next feature – Bluetooth
1221 UEFI.Next feature – REST Protocol
1222 UEFI.Next feature – BMC/Service Processor Device Path
1223 UEFI.Next networking features – chapter 2.6 requirements
1224 UEFI.Next – Adding support for No executable data areas
1227 UEFI.Next feature – Platform recovery
1234 UEFI.Next feature – Smart card edge protocol
1244 sections of the spec mis-arranged
1251 EFI_REGULAR_EXPRESSION_PROTOCOL and EFI_IFR_MATCH2 HII op-code
1254 SD Device Path
1255 UFS Device Path Node Length
1257 Correct the typedef definitions for EFI_BOOT_SERVICES/EFI_RUNTIME_SERVICES–Reiterate
1263 Customized Deployment of Secure Boot
1266 UEFI.Next Feature – IP_CONFIG2 Protocol
1268 RAM Disk UEFI Device Path Node
1269 Configuration Routing Protocol and Configuration String Updates
1287 Errata: EFI Driver Supported EFI Version not matching the spec revision
1288 The Macro definition conflict in EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.SetAttribute() in UEFI 2.4 B
1303 Update the UEFI version to reflect new revision
1304 Add IMAGE_UPDATABLE_VALID_WITH_VENDOR_CODE to FMP Check image
1308 Fix typo’s found in the final/published UEFI 2.4 Errata B spec
1309 Disallow EFI_VARIABLE_AUTHENTICATION from Secure Boot Policy Variables
1339 Errata in section 7.2.3.2 Hardware Error Record Variables
1341 DNS4 – friendly amendment to be reviewed by USWG
1342 DNS6 – friendly amendment for review by USWG
1345 EFI_USB2_HC_PROTOCOL Errata
1346 Mantis 1288 Errata
1347 Boot Manager Policy Errata
1348 ERRATA – Section 10.12 EFI_ADAPTER_INFORMATION_PROTOCOL Custom Types
1350 Keyword Strings Errata
1352 Errata for 1263 and 1227
1353 SATA Device Path Node Errata
1358 v2.5 amendment and v2.4 errata (missed implementation of Mantis 1089)
1360 Vendor Range for UEFI memory Types
1362 HTTP boot typos/bugs
1364 Extend supplicant data type for EAP

I’ll start to dig into a subset of this list in upcoming blog entries, starting with ones that have TianoCore implementation-related checkins.

Twitter, and Hacking Team

~ hucktech ~ Leave a comment

This blog isn’t attempting to cover ALL firmware news issues. I presume you’re reading about elsewhere, and don’t need this blog to tell you about. Especially stories that make it ‘mainstream’, like the recent Apple EFI vulnerability, or the recent Hacking Team’s use of UEFI in their malware.

In general, I go online and try to see what is new with firmware news only once a day, and miss some days. I don’t use Twitter as much as many, so I’m naturally behind-the-times of fresh news. To track UEFI issues with Twitter, here are a few URLs to start with:

https://twitter.com/legbacore/
https://twitter.com/intel_uefi

For example the Hacking Team’s use of UEFI. Twitter is a good place for this kind of news:

And a few security researchers are starting to dig deeper with research about the malware, such as:
http://blog.trendmicro.com/trendlabs-security-intelligence/hacking-team-uses-uefi-bios-rootkit-to-keep-rcs-9-agent-in-target-systems/

UEFI Mini-Summit at LinuxCon Europe in October

~ hucktech ~ Leave a comment

The UEFI Forum has recently announced they’ll do a UEFI Mini-Summit at the next LinuxCon Europe, in Dublin on October 7th.

Sessions:
* UEFI Forum Update and Open Source Community Benefits – Mark Doran, Intel
* What Linux Developers Need to Know About Recent UEFI Spec Advances – Jeff Bobzin, Insyde Software
* LUV Shack: An automated Linux kernel and UEFI firmware testing infrastructure – Matt Flemming, Intel
* The Move from iPXE to Boot from HTTP – Dong Wei, HP
* UEFI Development in an Open Source Ecosystem – Vincent Zimmer and Michael Krau, Intel

More Information:
http://uefi.org/node/947
http://events.linuxfoundation.org/events/linuxcon-europe/extend-the-experience/co-located-events

 

Tool review: UBU-helpers

~ hucktech ~ 1 Comment

Tool Review: UBU-helpers

[UPDATED, with feedback from reader. Thanks!]

UBU-helpers is a collection of tools used to examine UEFI binaries. The UBU-helpers code is portable C, built with CMake, so it should work on most UNIX systems as well as other common platforms with decent C compilers. The project is maintained: the tools were updated a few days ago. Currently there three tools: Hex Find (hexfind), Find Version (findver), and Driver Version (drvver).

1) Hex Find (hexfind) is a simple tool that searches for a pattern in a file.

hexfind v0.1.2
Usage: hexfind PATTERN FILENAME

2) Find Version (finder) is simple tool that also searches for version-based patterns in a file.

findver v0.3.2
Prints version string found in input file
Usage: findver prefix pattern offset end_marker max_length FILE
Options:
prefix      – Prefix string, ASCII symbols
pattern     – Pattern to find, hex digits
offset      – Offset of version string, integer
end_marker  – Pattern that marks end of version string, 2 hex digits
max_length  – Maximum length of printed version string, integer
num_location- Number of location, integer

3) Driver Version (driver) searches for multiple UEFI drivers/applications via hardcoded string/offset searches.  It — as do the other two tools — uses a Boyer-Moore-Horspool algorithm for it’s find algorithm.

drvver v0.19.2
Reads versions from input EFI-file
Usage: drvver DRIVERFILE
Support:
GOP driver Intel, AMD, ASPEED.
SATA driver Intel, AMD, Marvell
LAN driver Intel, Realtek, Broadcom

Here’s the printf statements of what drvver recognizes:

EFI GOP Driver SandyBridge – 2.0.%s
EFI GOP Driver IvyBridge   – 3.0.%s
EFI GOP Driver Haswell     – 5.0.%s
EFI GOP Driver Broadwell   – 5.5.%s
EFI GOP Driver CloverView  – 6.0.%s%S
EFI GOP Driver ValleyView  – 7.%c.%s%S
EFI GOP Driver CherryView  – 8.0.%s
EFI GOP Driver SkyLake     – 9.0.%s
EFI GOP AMD                – %s_signed
EFI GOP AMD                – %s
EFI GOP-in-OROM ASPEED     – %x.%02x.%02x
EFI GOP ASPEED             – %x.%02x.%02x
EFI IRST RAID for SATA     – %s
EFI AMD RAID               – %s
EFI AMD Utility            – %s
EFI AMD Utility            – %c.0.0.%c%c
EFI IRSTe RAID for SCU     – %s
EFI IRSTe RAID for sSATA   – %s
EFI IRSTe RAID for SATA    – %s
EFI Marvell SATA RAID      – %x.%x.%x.%04x
EFI Marvell SATA AHCI      – %x.%x.%x.%04x
EFI Intel 40GbE UNDI       – %x.%x.%02x
EFI Intel 10GbE UNDI       – %x.%x.%02x
EFI Intel PRO/Server UNDI  – %x.%x.%02x
EFI Intel Gigabit UNDI     – %x.%x.%02x
EFI Intel PRO/1000 UNDI    – %x.%x.%02x
EFI Intel FCoE Boot        – %s
EFI Broadcom UNDI          – %d.%d.%d
EFI Realtek UNDI           – %x.%03x %X%s
EFI Realtek UNDI           – %x.%03X%s
CPU Microcode 040671 BDW   – %02X
CPU Microcode 0306C3 HSW   – %02X
CPU Microcode 0206A9 IVB   – %02X
CPU Microcode 0306A7 SNB   – %02X
CPU Microcode 0306F2 HSW-E – %02X
CPU Microcode 0506E3 SKL-S – %02X
Unknown version GOP Driver
Unknown Intel LAN version.
Unknown Broadcom LAN version.
Unknown Realtek LAN version.
Unknown Realtek LAN version.

If you need to search for specific EFI strings in EFI binaries, these tools might be just what you needed. For more information, see the source code:

https://github.com/LongSoft/UBU-helpers

These tools were created to augment another tool which I’ve not used yet, “UEFI BIOS Updater (UBU)”. Here’s more information on that:

http://www.win-raid.com/t154f16-Tool-Guide-News-quot-UEFI-BIOS-Updater-quot-UBU.html

LinuxCon North America this August in Seattle

~ hucktech ~ Leave a comment

LinuxCon North America is happening this August, in Seattle for the first time (I think). A quick look at their schedule shows a variety of interesting presentations related to firmware security:

* Extending the Secure Boot Certificate and Signature Chain of Trust in the OS – Fionnuala Gunter, Hypori
* Resurrecting Internet Booting – Boot Boot, Booting Over the Internet – John Hawley, Intel
* Demystifying ACPI and EFI via Python and BITS – Josh Triplett
* ACPI for Network Switches – Dustin Byford, Cumulus Networks
* Tying TPMs Throughout The Stack – Matthew Garrett, CoreOS
* Turtles All The Way: Running Linux on Open Hardware – Rob Landley
* ACPI 6 and Linux – Rafael J. Wysocki, Intel
* The Bare-Metal Hypervisor as a Platform for Innovation – Russell Pavlicek, Citrix
* Suspend/Resume at the Speed of Light – Len Brown, Intel

Josh Triplett on BIOS BITS sounds especially interesting. It’ll be interesting to see if the boot boot reboot will get integrated with UEFI HTTP Boot support.

More information:
http://events.linuxfoundation.org/events/linuxcon-north-america
http://events.linuxfoundation.org/events/linuxcon-north-america/program/schedule

FreeBSD 10.2 beta1 released

~ hucktech ~ Leave a comment

Today FreeBSD announced availability of release 10.2-BETA1.

Amongst the new features/changes in this release, for firmware these changes are interesting:

* The uefisign(8) utility has been added. [r282974] (Sponsored by The FreeBSD Foundation)
* The acpi(4) subsystem has been updated to version 20150515. [r284460]
* Throttling via ACPI and P4TCC via device.hints(5) have been turned off by default. [r276986]
* The boot loader has been updated to support entering the GELI passphrase before loading the kernel. To enable this behavior, add geom_eli_passphrase_prompt=”YES” to loader.conf(5). [r281843]
* The memory test run at boot time on FreeBSD/amd64 platforms has been disabled by default. [r283262] (Sponsored by The FreeBSD Foundation)

Besides the above changes, there’ve also been a variety of iSCSI changes, unclear if this impacts UEFI’s iSCSI at all. And the Hyper-V drivers have been updated, sponsored by Microsoft’s Open Source Technology Center. [I am ignorant to Hyper-V technology, I guess I need to check how open source Hyper-V code in NanoBSD  impacts UEFI.]

More Information:
https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html
https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082704.html

PS: Unrelated to FreeBSD release, appears Intel CHIPSEC team is about to release 1.2.1, there is activity on their Github site:

https://github.com/chipsec/chipsec

EDK-II specs updated

~ hucktech ~ Leave a comment

[

UPDATE: Below I complain about lack of an announce mechanism to find these updates; TianoCore has an RSS feed that I’ve been neglecting to check, so they have been announcing it, but I’ve not been noticing…

http://www.tianocore.org/news/feed.xml

]

Today, the EDK-II specs were revised.

“Announcing the 1.25 Updates to the EDK II Specifications (BUILD, DSC and FDF). Also Update to Visual Forms Representation (VFR) V 1.9.”

(I stumbled upon announcement on web page by accident; I wish these were announced on edk2-devel or somewhere else more easily-discoverable.)

More Information:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications

FirmWare Test Suite 15.07.00 released

~ hucktech ~ Leave a comment

[Update: Colin King also blogged about this release:
http://smackerelofopinion.blogspot.com/2015/07/new-acpi-table-tests-in-fwts150700.html ]

Today Alex Hung of Canonical announced the latest release of FWTS, the FirmWare Test Suite.

Tar: http://fwts.ubuntu.com/release/fwts-V15.07.00.tar.gz
PPA: https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
Release Notes: https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.07.00

Changes to existing Features:
* –uefi and –acpi options renamed to –uefitests and –acpitests
* ACPI table tests in the acpitables test have been moved into specific ACPI tests.

New Features:
* acpi: acpidump: update TCPA table and acpidump accordingly
* acpi: add ACPI TCPA test
* acpi: add XENV table test
* lib: fwts_framework: Append “tests” to –uefi and –acpi
* live-image/fwts-frontend-text: update to –uefitests and –acpitests
* lib: acpi, acpidump: rename slit tables types
* lib: acpi: add in new GICC table fwts_acpi_table_gicc_affinity
* acpi: add SRAT table sanity checking (LP: #1464658)
* acpi: add BERT table sanity checking (LP: #1464712)
* lib: acpi: Add in GAS address types
* acpi: add ECDT table sanity checking (LP: #1464716)
* lib: acpi: Add support for the SPMI table
* acpi: add ACPI SPMI table sanity checking (LP: #1465256)
* acpi: add ACPI SLIT table sanity checking (LP: #1465276)
* lib: acpi: Add support for the HEST family of ACPI tables
* acpi: add ACPI HEST table sanity checking (LP: #1465379)
* acpi: Add BOOT table test (LP: #1465435)
* acpi: Add DBGP table test (LP: #1465441)
* acpi: Add DBG2 table test (LP: #1465710)
* acpi: re-orgainise HPET tests
* acpi: move MADT test from acpitables into new MADT test
* acpi: move GTDT test from acpitables into new GTDT test
* acpi: move XSDT test from acpitables into new XSDT test
* acpi: move RSDP test from acpitables into new RSDP test
* acpi: move RSDT test from acpitables into new RSDT test
* acpi: acpitables: remove no-op MCFG test
* acpi: move SBST test from acpitables into new SBST test
* acpi: move FADT test from acpitables into existing FADT test
* acpi: acpitables: remove redundant acpi table checking
* acpi: allow various ACPI table tests to run without root access
* lib: fwts_acpi_tables: fully pad out fixed up ACPI OEM IDs
* acpi: spcr: add missing white space in error messages
* acpi: add ACPI ERST test (LP: #1467835)
* acpi: correct ACPI BGRT table type
* acpi: add ACPI BGRT test (LP: #1467863)
* acpi: add ACPI CPEP test (LP: #1467870)
* acpi: add ACPI FACS test (LP: #1467966)
* acpi: acpidump: add in missing exponent field to SLIC
* acpi: add CSRT ACPI Table test (LP: #1470116)
* acpi: add LPIT ACPI test (LP: #1470184)
* acpi: add WAET ACPI table test (LP: #1470495)
* acpi: add SLIC table test (LP: #1470518)
* acpi: add MSDM table test (LP: #1470538)
* acpi: add UEFI ACPI data table test (LP: #1471698)
* bios: os2gap: remove ancient legacy test (LP: #1470573)

Fixed Bugs:
* acpi: acpidump: update SMM Communication fields on UEFI table
* lib: make acpidump parser more robust (LP: #1471202)
* fwts: cpufreq: fix theoretical division by zero (LP: #1466905)
* acpi: method: remove extraneous “_” in error message
* lib: fwts_klog: fix vector size and handle errors from pcre_exec (LP: #1461520)
* acpi: lib: fwts_acpi_tables: force fixup when loading tables from /sys/firmware
* lib: acpica: compiler: link in missing objects (LP: #1461936)

Two UEFI Form tools, plus one UEFI C Module complexity tool

~ hucktech ~ 1 Comment

UEFI has a “Browser”, and the browser shows various “Forms”. The browser is what you see when you get the OEM/IBV BIOS boot menu. OEMs/OBVs can reskin the browser, to add value, so the user experience will vary by vendor. In addition to the OEM/IBV, IHVs and ISVs can also add forms to a system’s browser. Each .efi binary contains resource strings, which get compiled into UEFI’s form language. The raw strings are IFR, Internal Forms Representation. The resulting view for the end user is VFR, Visual Forms Representation.  The UEFI browser is dynamic, you can programatically add new menu options by running an app. If you add foo.efi to your system, when you run the BIOS boot menu you may now see a new entry for the foo device, service, or application. For example, if you plug in a new device, that IHV’s config code will likely be now be in the BIOS boot menu. This is much nicer than having to run a DOS config.exe command (if you even have the ability to boot DOS), or boot into the vendor’s OEM firmware update CD (if they provide one).

At design-time, the EDK-II contains tools to build forms from source code. See TianoCore.org’s EDK-II tools and sample parsing code (in C and Python). Also see Intel SSG’s training courseware and labs, they have UI examples.

http://tianocore.sourceforge.net/wiki/EDK_II_Specifications
http://tianocore.sourceforge.net/wiki/EDK_II_Tools_List
http://tianocore.sourceforge.net/wiki/HII
http://sourceforge.net/projects/edk2/files/Training/TrainingMaterial/

At run-time, existing ROM images or .efi images may have an IFR in the binary. If you don’t have the source code, how do you evaluate the UI included, besides running it?

1) One tool is the “Universal IFR Extractor”, by Donovan6000. This tool can extract the internal forms representation from both EFI and UEFI modules and convert it into a human readable format. It is a Windows-centric tool, being an old-school native GDI GUI appplication written in C++. It may work on *nix via WINE, I’ve not tried it yet.

https://github.com/donovan6000/Universal-IFR-Extractor

2) Another tool is “Language applications for UEFI BIOS”, by William Leara. This was his University of Texas thesis; he is now a BIOS engineer at Dell. Besides the thesis, there is a github project with source code. He created an ANTLR grammar for VFR and a tool that gives an HTML preview of what the form would look like.

3) He also created an ANTLR grammar for UEFI-based C source code, and performs complexity analysis application uses general-purpose and domain-specific measures to give a complexity score to UEFI BIOS modules. This second tool isn’t form-centric, but it is also interesting, perhaps more interesting to some security researchers; it’s a good foundation to create more sophisticated tools of this kind, too…

https://github.com/WilliamLeara/LangAppUEFIBIOS
http://catalog.lib.utexas.edu/record=b8952762~S29
http://repositories.lib.utexas.edu/handle/2152/26306
http://www.basicinputoutput.com/p/aboutme.html

UEFI SMM vulnerability research: SmmBackdoor

~ hucktech ~ 1 Comment

Dmytro ‘Cr4sh’ Oleksiuk has been looking into Intel Systems Management Mode (SMM) on UEFI systems. Yesterday he posted a blog with some information on this research, along with some source code. Check out the blog post, it’s a very long document with lots of figures, very good reading.

More Information:

https://github.com/Cr4sh/SmmBackdoor
http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html

AMI announces NIST SP800-155-compatible UEFI

~ hucktech ~ Leave a comment

Today AMI announced an update for their Aptio V UEFI Firmware. For security perspective, this release is supposed to be compatible with NIST SP 800-155, BIOS Integrity Measurement Guidelines. Quoting an excerpt from their press release:

“In its Special Publication 800-155, NIST outlines the fundamentals of BIOS integrity measurement. This description includes a method to determine if the BIOS has been modified as well as the method for reporting and mitigating attacks against the BIOS. “These guidelines describe what is needed to establish a chain of trust for the BIOS,” commented Subramonian Shankar, President and CEO of American Megatrends. “In accordance with the NIST SP 800-155 guidelines, our Aptio V Firmware solution provides a means of generating and collecting the original BIOS measurements, called ‘the Golden Measurement Generation’, along with a means of storing the measurements that is either tamper-resistant or tamper-evident, called ‘the Collection Agent’ and a means of conveying the measurements to an analyzing agent, called the ‘Transmission and Reporting Agents’.” “Our goal in developing a NIST SP 800-155 compatible solution for Aptio V was to demonstrate to our customers that AMI is deeply committed to developing the most secure and tamper-resistant UEFI solutions available in the market today,” he commented.

I’m not sure if previous releases or other versions of AMI’s firmware products were/are SP800-155-compatible. Last time I looked at SP800-155, I thought it was still DRAFT, so I am not sure how that impacts compatibility.

On a nontechnical note, look at all the spaces that AMI uses in their press release URLs, yuck.

More Information:

http://ami.com/news/press-releases/?PressReleaseID=318&/American%20Megatrends%20Announces%20New%20Solution%20Compatible%20with%20NIST%20SP%20800-155%20%27BIOS%20Integrity%20Measurement%20Guidelines%27%20for%20Aptio%20V%20UEFI%20Firmware/
http://www.prnewswire.com/news-releases/american-megatrends-announces-new-solution-compatible-with-nist-sp-800-155-bios-integrity-measurement-guidelines-for-aptio-v-uefi-firmware-300107720.html

NIST SCAP CVE-2014-4768: IBM UEFI vulnerability

~ hucktech ~ Leave a comment

[I posted this blog entry a few hours ago, then immediately deleted it, after noticing that that CVE was listed as 2014, not 2015, and thought my search was invalid. But I just re-checked, and the CVE is dated yesterday, 2015-06-28. So I was wrong to delete the post.]

There’s a new NIST SCAP CVE for IBM UEFI for some systems, involving remote attackers. An excerpt of the data is listed below, see below URLs for full release in case you have one of these IBM systems.

Vulnerability Summary for CVE-2014-4768
Original release date: 06/28/2015
Last revised: 06/29/2015
Source: US-CERT/NIST

“IBM UEFI on Flex System x880 X6, System x3850 X6, and System x3950 X6 devices allows remote authenticated users to cause an unspecified temporary denial of service by using privileged access to enable a legacy boot mode.”

More Information:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4768
http://www.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-5098278

PS: Related to firmware and SCAP, but unrelated to this specific CVE: AFAICT, nobody has SCAP OVAL definitions for UEFI, and no SCAP tools look for UEFI issues. Once SCAP has UEFI OVAL definitions, apps like CHIPSEC and Copernicus can start issueing SCAP reports with this metadata, so firmware bugs can be found with SCAP security tools, instead of full-text-search luck. So AFAICT there is no way to use SCAP to properly look for firmware issues, only full-text search and hope that that “UEFI” or “BIOS” or “firmware” are included. I wish (Intel, ARM, UEFI Forum, OpenPOWER, etc.) and other vendors and trade groups who maintain firmware code should also maintain their SCAP metadata, to help keep enterprises more secure. The ecosystem needs more help looking for hardware and firmware-level bugs, they know how to look for kernelspace and userland bugs.

HTTP Boot support in Tianocore

~ hucktech ~ Leave a comment

One new feature in UEFI 2.5 is HTTP Boot, an alternative to PXE-based TFTP booting. I’ve made 2 blog posts on it so far:

New UEFI HTTP Boot support in UEFI 2.5

More Info on UEFI 2.5 HTTP Boot Implementations

Right now, HP supports it, and Intel is adding an implementation to Tianocore. In the last day, it appears that Intel’s beginning to add their implementation to the EDK-II trunk. In the NetworkPkg, there are a few new directories, apparently mostly related to a new HttpBootDxe driver. For more information, look at the edk2-devel mailing list archives, or the EDK-II trunk in the NetworkPkg.

Vim syntax highlighting for EDK2 sources

~ hucktech ~ 1 Comment

If you use Vim, there are a few projects with syntax highlighting support for TianoCore sources and config files. A recent one, from this year:
https://github.com/fedorov7/vim-uefi
Two others from 2013, with different features from above one:
https://github.com/0xeuclid/UEFI_VIM_Syntax
https://github.com/0xeuclid/vim_for_UEFI

If you use Visual Slick Edit, one firmware engineer at Dell has created some files for EDK-II support:
http://www.basicinputoutput.com/2015/05/syntax-highlighting-for-edkii-files-dec.html

I found no support found for Emacs, perhaps the FSF anti-UEFI campaign has impacted this? I don’t know of any EDK-II support in any other open source programmer’s editors or IDEs.

Besides highlighting C/assembly sources, EDK2 has 7 different build/config files, much more complex than a single Makefile to deal with. The specs for these files are listed below; it would be nice if you spend time in EDK2 sources, if your editor helps you understand these formats.
http://sourceforge.net/projects/edk2/files/Specifications/

tool mini-review: UEFI Firmware Parser

~ hucktech ~ 2 Comments

Here’s a short review of “UEFI Firmware Parser”, a UEFi security/diagnostic tool by Teddy ‘theopolis’ Reed.

“The UEFI firmware parser is a simple module and set of scripts for parsing, extracting, and recreating UEFI firmware volumes. This includes parsing modules for BIOS, OptionROM, Intel ME and other formats. Features:
– UEFI Firmware Volumes, Capsules, FileSystems, Files, Sections parsing
– Intel PCH Flash Descriptors
– Intel ME modules parsing (for ARC5)
– Dell PFS (HDR) updates parsing
– Tiano/EFI, and native LZMA (7z) [de]compression
– Complete UEFI Firmware volume object heirarchy display
– Firmware descriptor [re]generation using the parsed input volumes
– Firmware File Section injection”

This package is actually three tools, not just one:

fv_parser.py is a UEFI Firmware Parser, which searches a file for UEFI firmware volumes, there are two other tools/scripts.

uefi_guids.py is another tool, which outputs GUIDs for files, optionally write GUID structure file, and will import GUID labels into IDA.

fv_injector.py is the GUID Injector, which replaces GUIDs on sections within a UEFI firmware file, or on UEFI firmware files within a firmware filesystem.

The tools are written in Python. It requires Python development headers, GCC, and the Python pefile library. To install, use the normal:

$ sudo python ./setup.py install

Usage:

$ python ./scripts/fv_parser.py -h
usage: fv_parser.py [-h] [–type {VARIOUS_TYPES}]
[-b] [-q] [-o OUTPUT] [-e] [-g GENERATE] [–test]
file [file …]
-h, –help            show this help message and exit
–type {VARIOUS_TYPES} Parse files as a specific firmware type.
-b, –brute           The input is a blob and may contain FV headers.
-q, –quiet           Do not show info.
-o OUTPUT, –output OUTPUT Dump EFI Files to this folder.
-e, –extract         Extract all files/sections/volumes.
-g GENERATE, –generate GENERATE Generate a FDF, implies extraction
–test                Test file parsing, output name/success.

$ python ./scripts/uefi_guids.py -h
usage: uefi_guids.py [-h] [-c] [-b] [-d] [-g GENERATE] [-u] file
-h, –help            show this help message and exit
-c, –capsule         The input file is a firmware capsule, do not search.
-b, –brute           The input file is a blob, search for firmware volume headers.
-d, –flash           The input file is a flash descriptor.
-g GENERATE, –generate GENERATE  Generate a behemonth-style GUID output.
-u, –unknowns        When generating also print unknowns.

$ python ./scripts/fv_injector.py -h
usage: fv_injector.py [-h] [-c] [-p] [-f] [–guid GUID] –injection INJECTION
[-o OUTPUT]
file
-h, –help            show this help message and exit
-c, –capsule         The input file is a firmware capsule.
-p, –pfs             The input file is a Dell PFS.
-f, –ff              Inject payload into firmware file.
–guid GUID           GUID to replace (inject).
–injection INJECTION Pre-generated EFI file to inject.
-o OUTPUT, –output OUTPUT Name of the output file.

More Information:

https://raw.githubusercontent.com/theopolis/uefi-firmware-parser/master/README.rst
https://github.com/theopolis/uefi-firmware-parser

Firmware Security document collection project on Github

~ hucktech ~ Leave a comment

I just noticed a new github project:

https://github.com/robguti/firmware_security_docs

It is a collection of PDFs about firmware security, mostly security conference presentations, gathered up into a single project.

It is unrelated to this blog, I don’t know the person who created the project.

Funny, I recognize about 1/3 of the collected files by their filenames. 🙂

Be sure to virus-check PDFs before you read them, who knows if malware has been added to to these.