Category: Uncategorized

qboot, new x86 firmware for qemu

~ hucktech ~ Leave a comment

Last week, Paolo Bonzini of Red Hat announced qboot, a new x86 firmware option for QEMU. qboot is a minimal x86 firmware that runs on QEMU and, together with a slimmed-down QEMU configuration, boots a virtual machine in 40 milliseconds on an Ivy Bridge Core i7 processor. The code is 8KB in size.

More information:
git://github.com/bonzini/qboot.git
https://lwn.net/Articles/645455/

https://www.kraxel.org/repos/firmware.repo
https://www.kraxel.org/repos/jenkins/qboot/

tool mini-review: UEFITool

~ hucktech ~ 2 Comments

UEFITool is a UEFI firmware parsing tool, written by Nikolaj Schlej. UEFITool is a GUI tool for parsing, extracting and modifying UEFI firmware images. It supports parsing of full BIOS images starting with the flash descriptor or any binary files containing UEFI volumes. The UI provides abilities to Extract, Insert, Replace, Remove, and Rebuild, and Search. Extracting and Replacing can be done either by just the body, or also include it’s header (GUID, size, attributes and other structure-related information). Inserting targets UEFI volumes and encapulation sections, and can be done before, after, or into. You can Search by hex patterns, a GUID, Unicode text, or ASCII text. The BSD-ish licensed open source tool is cross-platform, written in C++, using Qt v4 or v5, built using the Qt qmake utility.

More Information:

https://github.com/LongSoft/UEFITool

Linux ACPI support for ARM-v8

~ hucktech ~ Leave a comment

Earlier this month, Linaro announced their effort to upstream the Linux patches to enable ACPI on ARMv8. It appears the patch may make it in Linux 4.1, but it is not done yet.

The Linaro blog post credits a large list of people who helped: UEFI Forums’ ACPI Working Group, Linaro, ARM, Red Hat, Huwaei, Qualcomm, AMD, AMD, APM, HP, other Linaro LEG members, and Linux kernel maintainers, including Linus.

As part of this effort, on March 26th, ARM hosted a Firmware Summit focused on ARMv8 and ACPI, with dozens attending, including SoC vendors, BIOS vendors, firmware and kernel developers, ODMs and OEMs.

The Linux kernel checking comment for this patchset includes this description:

‘This series introduces preliminary ACPI 5.1 support to the arm64 kernel using the “hardware reduced” profile. We don’t support any peripherals yet, so it’s fairly limited in scope:
– MEMORY init (UEFI)
– ACPI discovery (RSDP via UEFI)
– CPU init (FADT)
– GIC init (MADT)
– SMP boot (MADT + PSCI)
– ACPI Kconfig options (dependent on EXPERT)
ACPI for arm64 has been in development for a while now and hardware has been available that can boot with either FDT or ACPI tables. This has been made possible by both changes to the ACPI spec to cater for ARM-based machines (known as “hardware-reduced” in ACPI parlance) but also a Linaro-driven effort to get this supported on top of the Linux kernel. This pull request is the result of that work. These changes allow us to initialise the CPUs, interrupt controller, and timers via ACPI tables, with memory information and cmdline coming from EFI. We don’t support a hybrid ACPI/FDT scheme. Of course, there is still plenty of work to do (a serial console would be nice!) but I expect that to happen on a per-driver basis after this core series has been merged.’

Upon accepting the patch, Linus said:

‘No earth-shattering new features come to mind, even if initial support for ACPI on arm64 looks funny. Depending on what you care about, your notion of “big new feature” may differ from mine, of course. There’s a lot of work all over, and some of it might just make a big difference to your use cases.’

This *is* big new feature, if you care about firmware and Linux.
More Information:

https://www.linaro.org/blog/collaborative-effort-to-upstream-acpi/

ARM Trusted Firmware

~ hucktech ~ Leave a comment

Starting around 2013, ARM started to release “ARM Trusted Firmware” as a BSD-licensed Github-hosted open source project.  ARM Trusted Firmware is the trusted execution environment that runs behinds the scenes of the OS on AArch64 platforms. It works in conjunction with UEFI, including Secure Boot.

In upcoming blog posts, I’ll be writing some articles with more details about this project. For now, I’ll suggest reading their Firmware Design Guide and watching the below Youtube-hosted Linaro intro video.

More Information:

https://github.com/ARM-software/arm-trusted-firmware
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/change-log.md
https://github.com/ARM-software/tf-issues/issues
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.md
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-design.md
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/porting-guide.md
https://lists.linaro.org/pipermail/boot-architecture/
https://lists.linaro.org/pipermail/linaro-uefi/

MITRE Copernicus

~ hucktech ~ 1 Comment

So far, in this new blog, I’ve been mostly focusing on open source tools and open source operating systems, so I’ve not focused on MITRE’s Windows-centric non-open source tool, Copernicus[1]. But the tool is extremely powerful, and deserves more attention.

“Copernicus is the first tool to provide BIOS configuration management and integrity checking capabilities throughout an enterprise. The tool is implemented as a kernel driver that creates a file containing the BIOS dump and a file containing the raw configuration information. When deployed in enterprise environments, scripts can send the raw BIOS dump and configuration information to a server for post-processing. This processing can indicate whether a given BIOS differs from an expected baseline, and it can also indicate whether the BIOS or the computer’s System Management RAM (where some code loaded by BIOS continues running after boot).”

An excerpt from a G+ post in 2013 from Dragos Ruiu on Copernicus:

“IMHO Copernicus BIOS verification tool, is one of the most important new security tools in recent history. We’ve already found some persistent BIOS malware that survives re-flashing with it.”

I wish it were available for Linux, not just for Windows, so I could use it! And I wish it were open source (alas, all security tools are not): trusting any native kernel driver on your system, or especially to deploy to all systems in you enterprise, whether it is natively installed or from another boot media, has issues. I hope licensees from MITRE have the option to review the code and compile it themselves.

[Intel’s CHIPSEC also has some similar features. When run as an OS-present tool — instead of a live-boot or UEFI Shell booted — CHIPSEC also includes a native driver on Windows, and on Linux. With CHIPSEC, the kernel driver sources are provided.]

If you have Windows-based enterprise, you should investigate out Copernicus.

Windows-centric code aside, Copernicus distribution includes bios_diff.py, which works on Linux. This is a wonderful tool[2].

Even if you don’t care about Windows, you should study the Copernicus research, is it amazing.

Two of the creators of Copernicus have left MITRE and have started LegbaCore. Their last talk on using Copernicus at RSA conference last month[3] was excellent, talking about using Copernicus usage in enterprises.

More Information:

[1]http://www.mitre.org/publications/project-stories/going-deep-into-the-bios-with-mitre-firmware-security-research
http://www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/copernicus-question-your-assumptions-about
http://www.mitre.org/publications/technical-papers/copernicus-2-senter-the-dragon
http://www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/playing-hide-and-seek-with-bios-implants
http://www.mitre.org/research/technology-transfer/technology-licensing/copernicus
[2]https://firmwaresecurity.com/2015/05/21/tool-mini-review-bios_diff-py/
[3]https://firmwaresecurity.com/2015/05/19/legbacore-releases-new-firmware-research-at-rsa-conference/

Recent FreeBSD firmware improvements

~ hucktech ~ Leave a comment

Like Linux, FreeBSD now also supports UEFI. PC-BSD and TrueOS are FreeBSD-based, as is NanoBSD, the embedded subset of FreeBSD.

Besides UEFI pre-OS tool support, FreeBSD also has Forth-based OpenFirmware /boot/loader, with numerous diagnostic commands (autoboot, bcachestat, boot, echo, heap, help, include, load, load_geli, ls, lsdev, more, pnpscan, read, reboot, set, show, unload, unset, ?).

Earlier this week, PC-BSD 10.1.2 has been released. Amongst the changes I notice two firmware-related improvements for this release:

* Support for encrypted iSCSI backups via Life-Preserver, including support for bare-metal restores via installer media

* Improvements to Online Updater, along with GRUB nested menus for Boot-Environments

Firmware changes aside, they’ve been adding some interesting security features: /-level encryption for ZFS, PersonaCrypt Utility, with Stealth Mode, Tor mode for firewall, etc.

More information:

10.1.2 release:
http://lists.pcbsd.org/pipermail/announce/2015-May/000076.html
http://blog.pcbsd.org/2015/05/pc-bsd-10-1-2-released/
https://www.freebsdnews.com/

FreeBSD and UEFI:
https://www.freebsd.org/doc/en/books/handbook/boot.html
https://www.freebsd.org/cgi/man.cgi?query=uefi&apropos=0&sektion=8&manpath=FreeBSD+11-current&format=html
https://wiki.freebsd.org/SecureBoot
https://wiki.freebsd.org/UEFI
http://bsdmag.org/beyond-bios-the-extended-firmware-interface -efi/

/boot/loader:
https://www.freebsd.org/cgi/man.cgi?query=loader%288%29
http://ficl.sourceforge.net/ficl.html

VZ on network usage of UEFI 2.5

~ hucktech ~ Leave a comment

Vincent Zimmer of Intel recently gave a presentation on use of UEFI 2.5 and Cloud-related issues. The talk was given at the Open Compute Project, and recently reprised at the Spring UEFI Forum event. The focus is UEFI-centric use of network booting, and firmware updates. This is a useful presentation to help understand one way UEFI uses it’s network stack.

More information:

http://firmware.intel.com/blog/uefi-and-cloud

Tool mini-review: bios_diff.py

~ hucktech ~ 1 Comment

I recently became of a tool that I didn’t know worked on Linux: bios_diff.py, included with Copernicus. The MITRE Corporation’s Copernicus is a very powerful firmware security tool. I’ve been focusing more on non-Windows tools and open source tools, so I’ve not been giving Copernicus tools enough emphasis, something I’ll correct in future posts. I’ll start with this post, on bios_diff.py, which is distributed with Copernicus. This tool is not Copernicus-centric, nor Windows-centric.

If you’ve a dump of a BIOS ROM image, created by CHIPSEC or Copernicus or Coreboot’s FlashROM, you can use bios_diff.py to help determine what has changed. The tool parses the EFI Firmware Filesystem, to break out the files. It can also do smart diff’ing based on GUIDs in case files were added/removed, and will provide additional semantically relevant things like the file name, PE sections, and size of differences found (where each is applicable.)

This tool is a very useful addition to your open source firmware security toolbox.

This free tool does have some limits, EFIPWN is not as good as the newer UEFITool w/r/t some parsing. Perhaps someone has time to integrate UEFTool into a newer version of this tool? 🙂

Usage:

  bios_diff.py [-crs] [-i IGNORE] [-d [-a [-p]] [-n [-u UNIQUE]] [-l SIZELIMIT] [-m NUMBYTES]] [-o OUT] [-e EFIPWN] <file1> [<file2>]
  bios_diff.py (-h | –help)

The files are BIOS dumps to be compared.  <file2> may be a single file, or it may be a directory which contains several BIOS dumps against which we will diff <file1>.  Also, <file1> can be a directory by itself.  In this case, the first file found in this directory will be compared against all of the others.

Options:
  -c            delete the directories when the diff is complete
  -r            reuse parsed directories previously generated by EFIPWN if they appear to exist
  -s            print out all sha1 hashes of files in BIOS dump
  -i IGNORE     file containing list of regular expressions (one per line) for filenames we should ignore
  -d            do hash diffing of extracted files
  -a            print all unique ranges per file
  -n            print number of unique bytes per file
  -u UNIQUE     exclude diffs which have less than UNIQUE unique bytes for both files
  -l SIZELIMIT  dont compute unique ranges or bytes on files which exceed this size
  -p            print the PE information about diffs if the files are PE files
  -m NUMBYTES   merge regions which are within NUMBYTES of eachother
  -o OUT        output directory [default: temp]
  -e EFIPWN     the location of EFIPWN files [default: EFIPWN]

More information:

https://www.blackhat.com/docs/us-13/US-13-Butterworth-BIOS-Security-Code.zip

Upcoming UEFI/BIOS security training

~ hucktech ~ Leave a comment

Here are two upcoming UEFI/BIOS security related training events being taught by industry experts (listed by date):

Security of BIOS/UEFI System Firmware from Attacker’s and Defender’s Perspective
When: Jun 16-18 2015
What: Recon
Where: Hyatt Regency Montreal
Instructors: Yuriy Bulygin, Oleksandr Bazhaniuk, Andrew Furtak and John Loucaides
https://recon.cx/2015/trainingbiosuefi.html

Introductory BIOS & SMM Attack & Defense
When: Oct 12-16, 2015
What: HITB GSEC Singapore
Where: Sheraton Towers Singapore
Instructors: Xeno Kovah, Corey Kallenberg
http://gsec.hitb.org/sg2015/sessions/tech-training-6-introductory-bios-smm-attack-defense

 

BUILDRULEORDER support added to EDK-II BuildTools

~ hucktech ~ Leave a comment

Recently there’s been a lot of checkins to the EDK-II trunk. Most are new libraries for UEFI 2.5 support, but some are design-time improvements to the EDK-II toolchain. One recent change to the BaseTools package is to implement BUILDRULEORDER support for tools_def.  This adds increased flexibility for compilers and related developer tools, which EDK-II’s Build command calls behinds the scenes. Quoting it’s comments:

This feature allows the toolchain to choose a preference for source file extensions in tools_def.txt. The first extension is given the highest priority. Here is an example usage for tools_def.txt:

*_*_*_*_BUILDRULEORDER   = nasm Nasm NASM asm Asm ASM S s
*_XCODE5_*_*_BUILDRULEORDER   = S s nasm Nasm NASM

Now, if a .inf lists these sources: 1.nasm, 1.asm and 1.S
All toolchains, except XCODE5 will use the 1.nasm file. The XCODE5 toolchain will use the 1.S file.

Note that the build_rule.txt file also impacts the decision, because, for instance there is no build rule for .asm files on GCC toolchains.

For more information, view recent archives of the EDK2-devel mailing list, such as:
http://comments.gmane.org/gmane.comp.bios.tianocore.devel/14760

New FWTS Discuss Mailing List Created

~ hucktech ~ Leave a comment

FWTS is the FirmWare TestSuite for Linux from Canonical. The project has had an Announce and a Develop mailing list; they’ve just created a Discuss list. This will be useful for enterprise users and security researchers who use these tools.

“A new fwts-discuss@lists.ubuntu.com has been created for general Firmware Test Suite related discussions. Email from other related firmware projects may be cross-posted to this as long as they are vaguely related to fwts.”
More information:

https://lists.ubuntu.com/mailman/listinfo/fwts-discuss
https://lists.ubuntu.com/archives/fwts-devel/2015-May/006103.html

Skyport Systems continuously verify firmware

~ hucktech ~ Leave a comment

Multiple news sites are carrying stories about a new security startup, Skyport Systems and their new cloud solution. From the perspective of firmware, their server is supposed have it’s firmware ‘continuously verified’:

“The SkySecure Server is a trusted computing platform. It consists of purpose-engineered hardware that is extremely difficult to compromise and can be deployed in untrusted environments. Some of the features include:
 * A hardware-based root-of-trust for the entire system lifecycle from the point of manufacture onwards
 * Continuous verification of the hardware, firmware, BIOS, OS, and workloads
 * Compartmentalization of subsystems – I/O, x86 compute, workloads, compartments – which isolates vulnerability in the event of a breach
 * Tamper-resistant hardware”

I have no personal experience with their platform, nor what kind of BIOS they’re using, and how they’re verifying it. It appears to be closed-source, I’ve not been able to find any code. Speak up if you find the code!

More information;
http://www.eweek.com/servers/skyport-emerges-from-stealth-intros-skysecure-servers.html
http://www.crn.com/news/security/300076844/skyport-systems-emerges-from-stealth-with-hyper-secure-converged-server.htm
https://www.skyportsystems.net/solution/

LegbaCore releases new firmware research at RSA Conference

~ hucktech ~ Leave a comment

LegbaCore gave a firmware security talk at last month’s RSA Security Conference. The presentation materials and some video, are online.

LegbaCore, along with Invisible Things Lab are IMO the top two firmware security firmws, so when they release substantial new research like this, everyone should pay attention.

(If you attended my LinuxFestNorthWest talk last month on firmware security tools, the advise the LegbaCore covers in this presentation is much more detailed than what I covered.)

This is probably the best advise available to date for enterprises to protect themselves from bootkits. More up-to-date than the NIST SP guidelines or any other best practices that I know of. Everyone involved with protecting enterprise systems needs to study this carefully.

Title: Are You Giving Firmware Attackers a Free Pass?
Synopsis: Yes. Yes you are. Because you’re not patching away the vulnerabilities we and others have found and disclosed, and you’re not inspecting whether anyone has infected your firmware. This talk provides an introduction to firmware threats & capabilities. But because it is longer than previous talks like “Betting BIOS Bugs Won’t Bite Y’er Butt?”, a special emphasis is placed on including actions organizations can take immediately to mitigating firmware vulnerabilities and infections, above and beyond patching.

More Information:

http://www.legbacore.com/Research.html

Sage Engineering updates Minnow firmware

~ hucktech ~ Leave a comment

Sage Engineering maintains a Coreboot-based, SeaBIOS payload-based firmware for the Intel MinnowBoard MAX.

Today, they’ve announced an updated release. This update allows for flashing the boot image without a hardware device.

“The binary SageBIOS boot ROM image, which is flashed on the development board’s SPI Flash device, is based on the Intel Firmware Support Package (Intel FSP) and coreboot open source initialization. The SageBIOS OSP replaces UEFI firmware that comes installed on both versions of MinnowBoard MAX and will support booting a greater variety of operating systems, including FreeBSD and a variety of RTOS, as well as legacy operating systems such as older versions of Microsoft Windows and even DOS. The SageBIOS OSP will support all the operating systems supported by the native UEFI firmware, such as Windows and Linux. In addition, the SageBIOS OSP will boot both 32-bit and 64-bit operating systems with a single boot image.”

The download of the “demo ROM” is free, but email registration is required.
More information:
http://lists.elinux.org/pipermail/elinux-minnowboard/Week-of-Mon-20150518/001523.html
http://www.se-eng.com/minnow/

Spring UEFI Forum agenda announced

~ hucktech ~ Leave a comment

The UEFI Forum Spring event is happening in Tacoma.WA.US this coming week. They just announced the presentations for the event:

* Zachary Bobroff, AMI – PreBoot Provisioning solution with UEFI
* Kevin Davis, Insyde – System Prep Applications, A Powerful New Feature in UEFI 2.5
* Olivier Martin, ARM – Porting a PCI driver to ARM AArch64 platforms
* Lief Lindholm, ARM – Demonstrating a common EDK2 pltforms & drivers tree
* Dick Wilkins, Phoenix – UEFI FIrmware – Securing SMM
* Gabe Stocco and Scott Anderson, Microsoft – Windows Requirements for TPM, HVCI and Secure Boot
* Jeremiah Cox
* Vincent Zimmer, Intel – Filling UEFI/FW Gaps in the Cloud
* David Box, Intel – An overview of ACPICA userspace tools
* Samer El-Haj-Mahmoud, HP – Firmware in the Datacenter: Goodbye PXE and IPMI. Welcome Http

Typically, the UEFI Forum makes slides for these presentations available on their web site a few weeks later…

More information:
http://www.uefi.org/node/887

 

AMI launches MG9005 controller for NVMe SSD storage

~ hucktech ~ Leave a comment

Today AMI (American Megatrends, Inc.) launches a new enclosure solution for NVM Express SSD Subsystems. The controller is firmware-upgradable through SMBUS.

“A true, single-chip solution, the MG9095 backplane controller ships ready to use with no custom firmware or programming required,” said Subramonian Shankar, AMI CEO.

Read the full announcement:
http://www.ami.com/products/backplanes-and-enclosure-management/enclosure-management-asics/mg9095-controller/

http://www.ami.com/news/press-releases/?PressReleaseID=312&/American%20Megatrends%20Launches%20Enclosure%20Management%20Solution%20for%20NVM%20Express%E2%84%A2%20SSD%20Subsystems/

Red Hat OVMF whitepaper

~ hucktech ~ Leave a comment

[This is not fresh news. Since this is a new blog, I’m starting to work backward on some noteworthy news/releases that happened shortly before the blog started…]

Mid-2014, Red Hat released a whitepaper documenting the UEFI OVMF format. It is well-written, and useful for those new to UEFI, coming from a Linux background. The document is Copyright (C) 2014-2015, Red Hat, Inc., licensed CC BY-SA 4.0.

Abstract: The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI is designed to replace the Basic Input/Output System (BIOS) firmware interface. Hardware platform vendors have been increasingly adopting the UEFI Specification to govern their boot firmware developments. OVMF (Open Virtual Machine Firmware), a sub-project of Intel’s EFI Development Kit II (edk2), enables UEFI support for Ia32 and X64 Virtual Machines. This paper reports on the status of the OVMF project, treats features and limitations, gives end-user hints, and examines some areas in-depth.

Keywords: ACPI, boot options, CSM, edk2, firmware, flash, fw_cfg, KVM, memory map, non-volatile variables, OVMF, PCD, QEMU, reset vector, S3, Secure Boot, Smbios, SMM, TianoCore, UEFI, VBE shim, Virtio

Read the whitepaper:

http://people.redhat.com/~lersek/ovmf-whitepaper-c770f8c.txt

RMS on Free Hardware from LibrePlanet 2015

~ hucktech ~ Leave a comment

The Free Software Foundation has released some of the videos from LibrePlanet 2015. The presentation from RMS is described as:

Free software, free hardware, and other things by Richard Stallman, founder of the Free Software Foundation. Richard gives his take on some major issues facing the world of free software and explains how the free software philosophy extends to hardware.

It is a 45-minute video, the first 23 minutes are presentation, the remainder are QA. Video is here:
https://media.libreplanet.org/u/libreplanet/m/richard-stallman-free-software-free-hardware/

I have few questions of my own, from watching it:

At the beginning, he mentions that remote attestation of TPM doesn’t work, without any details on why he thinks that. I don’t understand what he’s talking about, there are multiple TNC implemenations, as well as non-TNC equivalent solutions that use TPM for network attestation. Linux-based Chrome OS, StrongSwan for Linux, Linux-IMA or OpenAttestation (OAT) for example.
If someone has more background on his perspective on remote attestation of TPM doesn’t work, please speak up. Heck, even the UEFI firmware on most modern systems have TNC support. IMO, it would have been more interesting to hear a discussion about new TPM 2.0 features, as well as TrustZone on ARM, and how that impacts various Free Software/Firmware/Hardware movements.
https://github.com/OpenAttestation/OpenAttestation/wiki
https://wiki.strongswan.org/projects/strongswan/wiki/TrustedNetworkConnect
http://linux-ima.sourceforge.net/

Later, he talks about “Free Hardware” term, which AFAICT isn’t that well-defined, and recommends using GPLv3 for hardware, and doesn’t mention OSHWA license, except to say that the alternatives offer no value. I am not sure that the existing OSHWA has the same opinion as RMS with his “Free Hardware” perspective, see March-April thread on the OSHWA list. IMO, Free Hardware -vs- Open Hardware needs some clarification. I guess, like with software, we’ll have the Open camps and the Free camp, with FSF as the Free owner and OSHWA instead of OSI for the Open camps, in addition to the Closed camps. However, unlike ISVs, I’ve never met an OEM or IHV that likes the GPL, so any Free Hardware will likely have to be community-funded, like Novena; I hope the FSF plans community-funded Free Hardware in the coming months.
https://www.fsf.org/bulletin/2012/fall/a-bit-about-free-hardware
http://www.wired.com/2015/03/need-free-digital-hardware-designs/
http://www.wired.com/2015/03/richard-stallman-how-to-make-hardware-designs-free/
http://lists.oshwa.org/pipermail/discuss/2015-March/thread.html
https://www.crowdsupply.com/kosagi/novena