Apple EFI vulnerabilities: CVE-2015-3693 and CVE-2015-3692

From the security-announce@lists.apple.com announce list, Apple has an EFI update for multiple systems, available from the App Store. Two CVEs are listed:

APPLE-SA-2015-06-30-3 Mac EFI Security Update 2015-001

Mac EFI Security Update 2015-001 is now available and addresses the following:

EFI
Available for:  OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5
Impact:  A malicious application with root privileges may be able to modify EFI flash memory
Description:  An insufficient locking issue existed with EFI flash when resuming from sleep states. This issue was addressed through improved locking.
CVE-ID
CVE-2015-3692 : Trammell Hudson of Two Sigma Investments, Xeno Kovah and Corey Kallenberg of LegbaCore LLC, Pedro Vilaca

EFI
Available for:  OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5
Impact:  A malicious application may induce memory corruption to escalate privileges
Description:  A disturbance error, also known as Rowhammer, exists with some DDR3 RAM that could have led to memory corruption. This issue was mitigated by increasing memory refresh rates.
CVE-ID
CVE-2015-3693 : Mark Seaborn and Thomas Dullien of Google, working from original research by Yoongu Kim et al (2014)

More Information:
https://support.apple.com/en-us/HT204934
https://lists.apple.com/mailman/options/security-announce/

coreboot gets Rockchip ‘Veyron Shark’ support

As reported today by Michael Larabel at Phoronix, coreboot recently got support for the Rockchip ‘Veyron Shark’ ARM SoC , used for Chromebook/Chromebox, with code from Google and Rock Chip.

To quote Phoronix:

“Julius Werner of Google’s Chromium team added the Veyron Shark mainboard into Coreboot Git. Shark is in turn is based off a copy of the Coreboot code for Veyron Speedy. Some of the code comes from Google while the rest is from Rockchip Inc. Rockchip’s latest chip series is the RK33xx that is based on an octa-core Cortex-A53 design with a GPU supporting OpenGL ES 3.1 and capable of HDMI 2.0 and 4Kx2K @ 60 FPS H.264/H.265 real-time video playback.”

Rock Chip nor coreboot didn’t didn’t consider this newsworthy, no press release. I’m grateful that Phoronix has such an efficient news gathering system, especially for tracking new features in coreboot.

More Information:

http://www.phoronix.com/scan.php?page=news_item&px=Veyron-Shark-In-Coreboot

NIST SCAP CVE-2014-4768: IBM UEFI vulnerability

[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

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

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

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

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.

Two Linux firmware articles

1) Linux Vendor Firmware Service launches

In a Phoronix article today, Michael Larabel describes the new Linux Vendor Firmware Service (LVFS) has been announced.

“This site provides a place for hardware vendors to submit packaged firmware updates, typically .cab files. This fire-and-forget service allows vendors to submit firmware updates without generating and hosting AppStream metadata themselves.”

More information:
https://beta-lvfs.rhcloud.com/
http://www.phoronix.com/scan.php?page=news_item&px=Linux-Vendor-Firmware-S
https://github.com/hughsie/fwupd

2) Intel on Linux firmware updates

Brian Richardson posted a blog yesterday, with information on Linux fwupdate, UEFI Capsule (firmware updates), UEFI 2.5 ESRT, and the Fedora firmware update mechanism.

More information:
http://blogs.intel.com/evangelists/2015/06/23/better-firmware-updates-in-linux-using-uefi-capsules/

WinZent releases wION BIOS for Minnow

Today, WinZent, a Swedish-based BIOS vendor, released wION BIOS and wIOS operating system for the MinnowBoard MAX. The release is registration-required freeware.

Some excerpts from their press release:

“WinZent Technologies AB today announced the general availability of its wION BIOS and wIOS operating system for the MinnowBoard Max open hardware board. WinZent’s software allows the embedded systems developer to use any operating system, from legacy operating systems such as MS-DOS, to most Linux distributions and the latest Microsoft Windows versions. The software also boosts the board with lightening-fast performance. WinZent’s wION BIOS cold boots the MinnowBoard Max in 0.56 seconds, and completes a warm reboot in 0.21 seconds. wION is bundled with WinZent’s real-time POSIX compliant operating system wIOS, which can provide multiples to magnitudes improved performance for applications and programs.”

“WinZent Technologies AB develops and markets the world’s fastest and most compact firmware and kernel software. wION, our BIOS, is characterized by sub-second boot time and full support for both legacy and the latest operating systems. wIOS, our POSIX-compliant operating system, is characterized by its deterministic real-time capabilities and its lightening-fast speed. WinZent Technologies AB is headquartered in Stockholm in Sweden.”

More Information:

http://winzenttech.com/
http://lists.elinux.org/pipermail/elinux-minnowboard/Week-of-Mon-20150622/001660.html

Rasberry Pi firmware revised to use Linux 4.0

As reported by Michael Larabel in Phoronix, the Raspberry Pi firmware has been changed, it now uses the Linux 4.0 kernel.

As Michael says, “For this low-cost ARM single board computers, the newer kernel is beneficial for new features, file-system improvements, and new device support like when it comes to USB peripherals and adapters.”

More information:
http://www.phoronix.com/scan.php?page=news_item&px=Raspberry-Pi-Linux-4.0
https://www.raspberrypi.org/forums/viewtopic.php?t=113753&p=778141

Dell Firmware blog and Intel UEFI training

I just became aware of another firmware blog, by William Leara of Dell:

http://www.basicinputoutput.com/

If you’ve not seen it, it’s worth reading, if you care about UEFI.

In this article, he mentions some of Intel’s UEFI web-based training:

http://www.basicinputoutput.com/2015/05/the-best-movies-youve-probably-never.html

In addition to this Flash-based training, Intel SSG also has a 3-day class for Intel employees, which they upload the labs and presentation materials to the public. They maintain this courseware, new versions of the presentations/labs are occasionally updated. If you are a Windows/Visual Studio user, you’ll be right at home with the labs. If you are a Linux user, there is a small amount of content focused on Linux, otherwise you’ll have to ignore all the screenshots of Visual Studio users clicking and right clicking. In the future, I wish Intel SSG would add audio/video layers, in addition to presentation and labs. Download Lab-Material-FW.zip and the most recent Presentations<YYMMDD>.zip from:

http://sourceforge.net/projects/edk2/files/Training/TrainingMaterial/

New LAVA tool from Collabora

Today, Collabora released ‘lqa’, a new command line tool — and new Python API — for working with LAVA. LAVA is Linaro’s test tool that enables ‘continuous integration’-style testing with embedded devices (including QEMU), to update the firmware and OS, and run tests on the device. The main LAVA interface is a web UI. The tool is mainly intended for embedded development/QA, but is also useful for security researchers. Quoting their announcement on the linaro-validation mailing list:

Collabora has been working on `lqa’, a tool to submit and manage LAVA jobs, which helps to get many of the LAVA job administration and monitoring tasks conveniently done from the command line. `lqa’ brings a new API, lqa_api python module, a complete set of classes to easily interact with LAVA and offering at the same time a clean API on top of which further applications can be built upon (like `lqa’ itself). It has a templating system (using jinja2 package) that allows to use variables in json job files (in future could be expanded to support yaml), specifying their values either from a profile file or directly from the command line making possible the dynamic assignments of template variables during the `lqa’ command execution. The templating mechanism allows to handle groups of jobs, therefore it makes it easier to submit jobs in bulk. `lqa’ also features a flexible profile system (in YAML) which allows to specify a ‘main-profile’ from which further sub-profiles can inherit values, avoiding information duplication between similar profiles. Other of the current features include: Test report generation with the ‘analyse’ subcommand, Polling to check for job completion, All the operations offer logging capabilities, and Independent profile and configuration files.

More Information:

http://lists.linaro.org/pipermail/linaro-validation/
https://git.collabora.com/cgit/singularity/tools/lqa.git/

Intel AMT SDK 10.0 released

[Sorry for another short blog post, not much time this week..]

Intel released version 10 of their AMT SDK a few days ago.

Intel(R) Active Management Technology (Intel(R) AMT) is a capability embedded in Intel-based platforms that operates independently of the platform processor and operating system, which enables remote software to access Intel AMT, even when the platform is turned off, as long as the platform is connected to line power and to a network. ISVs can build applications that take advantage of the features of Intel AMT using the API provided in the Intel AMT SDK.

More Information:

http://blogs.intel.com/evangelists/2015/06/09/intel-amt-sdk-release-10-notes/
https://software.intel.com/en-us/articles/download-the-latest-intel-amt-software-development-kit-sdk/

AMI AMI DuOS: runs Android and Windows, no rebooting

Today, AMI announced DuOS, aka AMIDuOS, a new OS that runs Windows (v7 or v8) along with Android v5, users are able to use both OSes without rebooting. AMIDuOS is now in Beta for download; it is a commercial product, not open source or freeware: it cost $10 for a lifetime license – with a 30–day free trial. A few excerpts from their press release are below.

“AMIDuOS is a revolutionary new concept that brings the functionality, depth and fun of the Android experience to Microsoft Windows devices. It runs on nearly any Windows 7 or 8 PC or tablet device for fast, easy switching between Windows and Android environments – without the need to dual boot! Usage of AMIDuOS is quite similar to Android device. You just have to download and install, You got your Android device on Windows PC.”

“AMIDuOS runs on any modern Windows Desktops, Laptops, Tablets and 2-in-1 Devices. System requirements: x86 Processor. 32/64-bit of Windows 7/8/8.1. OpenGL 3.0 and above. Hardware Virtualization Technology should be enabled in BIOS. Minimum 3GB of System RAM. Minimum 2GB of Hard disk free space.”

“Now, users have access to the full library of Android apps on their Windows device – running either full-screen or in a window, while retaining the ability to switch over to their traditional Windows apps at any time – with no need to reboot. AMIDuOS is truly the best of both worlds. AMI has utilized its decades of expertise to build hardware acceleration support into the app, and support direct hardware access whenever possible. Emulation is only used when needed – otherwise code runs natively. This, plus 3D acceleration support, means incredible performance so games and video-intensive apps run smoothly and quickly. Since AMIDuOS can access native PC hardware and drivers, apps can take advantage of the touchscreen, sensors, peripherals, GPS, camera and more to deliver a fully immersive Android experience. AMI has tested AMIDuOS with over 4,000 apps and is continually releasing updates to improve compatibility.

“In order to enjoy the full performance of DuOS, Virtualization Technology (VT-x) should be enabled in BIOS. Please ensure that your System supports Virtualization Technology.”

More Information:

http://amiduos.com/support/knowledge-base/article/what-is-duos
http://amiduos.com/support/knowledge-base/article/enabling-virtualization-in-bios
http://www.intel.com/content/www/us/en/virtualization/virtualization-technology/intel-virtualization-technology.html
http://www.ami.com/news/press-releases/?PressReleaseID=315&/American%20Megatrends%20Unwraps%20Lollipop%20-%20Run%20Android%205.0.1%20Apps%20on%20Windows%20Devices%20without%20Compromise/

Tracking Intel BIOS and UEFI updates

Here’re two resources that you should be tracking, if you care about firmware security. In addition to OEM-specific sites, these are very useful to track updates in UEFI- and Intel-based systems:

1) TianoCore Security site, advisories, and list:
http://www.tianocore.org/security/
http://tianocore.sourceforge.net/wiki/Security
http://sourceforge.net/projects/edk2/files/Security_Advisory/

The Tianocore Security site has UEFI security vulnerability information impacting most UEFI-based vendors, including non-Intel vendors like ARM. The data is released as PDFs, and announced on their list. Tianocore doesn’t use NIST SCAP CVEs, look for these PDFs instead.

2) Intel Security Center site, and list:
https://security-center.intel.com/default.aspx
https://security-center.intel.com/advisories.aspx

The Intel Security Center site has BIOS/UEFI security vulnerability information impacting Intel-based systems. The data is released as web pages, and announced on their list.

Someone from your IT department should probably be subscribed to these mailing lists, and watch these lists and content for updates that may impact their systems.

Google Auron support added to Coreboot

As reported yesterday by Michael Larabel at Phoronix, coreboot recently got support for the Intel-based Google Broadwell ‘Auron’ board. To quote Phoronix:

“Support for Auron has been added in Coreboot Git. Auron is the Google Broadwell Reference Motherboard, which in turn is based on Google’s Peppy. More Broadwell designs are emerging and soon this latest-generation Intel processor will finally be out for desktops. The Google Auron is their reference board for this latest micro-architecture.”

More Information:

http://www.phoronix.com/scan.php?page=news_item&px=Auron-Coreboot-Broadwell

UEFI 2.5 ESRT in Linux 4.2

One new feature in UEFI 2.5 is the ESRT (EFI System Resource Table). As reported in Phoronix, ESRT supports has been added to the Linux kernel, and it appears that it’ll be in Linux 4.2. Quoting Peter Jones’ ESRT patch to sysfs on the linux-efi list, describing ESRT:

“The EFI System Resource Table (ESRT) provides a read-only catalog of system components for which the system accepts firmware upgrades via UEFI’s “Capsule Update” feature.  This module allows userland utilities to evaluate what firmware updates can be applied to this system, and potentially arrange for those updates to occur. The ESRT is described as part of the UEFI specification, in version 2.5 which should be available from http://uefi.org/specifications in early 2015.  If you’re a member of the UEFI Forum, information about its addition to the standard is available as UEFI Mantis 1090. For some hardware platforms, additional restrictions may be found at http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx , and additional documentation may be found at  http://download.microsoft.com/download/5/F/5/5F5D16CD-2530-4289-8019-94C6A20BED3C/windows-uefi-firmware-update-platform.docx .”

Peter’s patch adds sysfs files for the EFI System Resource Table (ESRT) under /sys/firmware/efi/esrt and for each EFI System Resource Entry under entries/ as a subdir. See the UEFI 2.5 specification for more details on ESRT.

More Information:

http://www.uefi.org/specifications
http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-Features-Coming
http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-EFI-System-ESRT-Table
http://permalink.gmane.org/gmane.comp.bios.tianocore.scm/3554
http://comments.gmane.org/gmane.linux.kernel.efi/5359

Learning OpenPOWER firmware

A few days ago, I blogged about AMI joining OpenPOWER. Recently, there’s been some other activity in OpenPOWER.

IBM just announced SuperVessel, an OpenPOWER-based cloud for developers:
http://www-03.ibm.com/press/us/en/pressrelease/47082.wss
https://ptopenlab.com/cloudlabconsole/index.html
http://openpowerfoundation.org/press-releases/openpower-accelerates-open-innovation-with-new-member-products-and-free-development-cloud/

It appears the source code to the OpenPOWER firmware was released about a year ago. Luckily, some others have been blogging on OpenPOWER firmware already:
http://openpowerfoundation.org/press-releases/occ-firmware-code-is-now-open-source/
http://jk.ozlabs.org/blog/post/159/customising-openpower-firmware/

OpenPower firmware up on github!

More OpenPower Firmware code released: OCC

I’m just learning about the OpenPOWER community, it’s been years since I’ve written PowerPC assembly, and that was OS-level stuff, I am not aware of current OpenPOWER firmware technology. I probably won’t have a lot of time to post blog entries next week, but but I’ll have some more on OpenPOWER firmware in future blog posts.

LegaCore releases new research

Yesterday LegbaCore updated their website to include some more research:

“Added the How Many Million BIOSes Would you Like to Infect whitepaper to our Research page. This document contains more discussion than was provided in the conference talks of what could be done by live OSes like Tails or LPS to be more secure against firmware threats.”

More information:
http://www.legbacore.com/Research.html
http://www.legbacore.com/News.html