Tag: UEFI

resflash: Resilient OpenBSD images for flash memory

~ hucktech ~ Leave a comment

Resflash is a tool for building OpenBSD images for embedded and cloud systems in a reproducible way. Resflash exclusively uses read-only and memory-backed filesystems, and because the partitions are only written to during system upgrades (or as configured), filesystems are not subject to corruption or fsck due to power loss – and even cheap flash drives can last virtually forever. Resflash images can be written to any bootable media, flash or conventional, and make great firewalls and NAS boot drives. Resflash was written from scratch, with inspiration drawn from NanoBSD and flashrd.

Brian Conway of RCE Software just announced UEFI support for resflash:

https://twitter.com/bconwayRCE/status/646049380999544832

I just pushed a new update to resflash that enables UEFI boot on 5.8-current and newer. There are no knobs to use this, it will be enabled if the sets used to create your OpenBSD base_dir support it, and will create an EFI System Partition (ESP) before the main OpenBSD partition. Partitioning is still done via MBR, so the image produced will be bootable in either native UEFI mode or in BIOS/CSM mode.

A few caveats:
– OpenBSD UEFI support is still under heavy development and is not guaranteed to work on all hardware. Also, I’m unable to get serial console output working yet on any of my hardware.
– Support is subject to change as GPT support in OpenBSD evolves, but I’m hoping not to break out images into separate UEFI and BIOS images.

Also, I’ve released a set of sample tools for building and configuring resflash images called resflash-tools.

http://stable.rcesoftware.com/resflash/
https://github.com/bconway/resflash-tools

Full announcement:
http://www.freelists.org/post/resflash/resflash-582-supports-UEFI-boot-in-58current-and-newer-and-announcing-resflashtools

LUV 2.0 RC3 released

~ hucktech ~ Leave a comment

Ricardo Neri of Intel announced version 2.0-RC3 of the LUV (Linux UEFI Validation) distribution today. It includes fresh versions of CHIPSEC, FWTS, BITS, as well as changes to LUV. Excerpts of announcement:

This release includes improvements to allow to use the same LUV USB stick several times and save the results of all the executions. This comes handy when, for instance, you want tests several systems or you need to run LUV several times if you are debugging. From now on, the luv-results directory name will be appended with a timestamp; it will look like: luv-results-yyyy-mm-dd–hh-mm-ss. A new directory will be created each time you run LUV. If, for any reason (e.g., your system resets the real time clock each time you reboot) a directory with the same timestamps exists already in the luv-results partition, a number will be appended to the newly created directory.

We have bumped the following test suite versions: FTWS is now V15.09.00, CHIPSEC is now v1.2.1, BITS is now 2005.

On top of FWTS, we have a applied a patch to downgrade the the severity of failure in systems that are prepared for Secure Boot (i.e., have a database of keys and certificates) but do not have the Microsoft UEFI CA certificate. This is especially relevant for users that want to build their own chain of trust. This is a patch that is in process of being merged in to FWTS (https://lists.ubuntu.com/archives/fwts-devel/2015-September/006884.html).

We also have included a change in the LEG (Linaro) kernel to fix a build break due to a problem in the kernel configuration. Work is in progress to use the mainline kernel instead of the LEG kernel tree.

There are patches to improve builds of sbsigntool in native and cross-compilation mode.

More info:
https://lists.01.org/pipermail/luv/2015-September/000610.html

https://download.01.org/linux-uefi-validation/v2.0/luv-live-v2.0-rc3.tar.bz2
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc

tool: ebiso: UEFI bootable ISO image creator

~ hucktech ~ Leave a comment

Vladimir Gozora just created ebiso, an UEFI bootable ISO image creator, a newly-created UEFI-centric project on Github. It is so

The Primary intention of ebiso was to create simple bootable UEFI ISO image for ReaR on SLES11.

*  currently supports only 8.3 file name convention (Joliet might follow in future)
*  no additional dependencies
*  released under GPL
*  currently under heavy testing 😉
*  more info will come (maybe)

The project is new, unclear if it’ll work with non-SLES11 ISOs. Ebiso aside, rear looks like an interesting project as well:

Relax-and-Recover is the leading Open Source bare metal disaster recovery and system migration solution. It is a modular framework with many ready-to-go workflows for common situations. Relax-and-Recover produces a bootable image. This image can repartition the system. Once that is done it initiates a restore from backup. Restores to different hardware are possible. Relax-and-Recover can therefore be used as a migration tool as well. Currently Relax-and-Recover supports various boot media (incl. ISO, PXE, OBDR tape, USB or eSATA storage), a variety of network protocols (incl. sftp, ftp, http, nfs, cifs) as well as a multitude of backup strategies (incl. IBM TSM, HP DataProtector, Symantec NetBackup, Bacula, rsync).

More info:

https://github.com/gozora/ebiso

https://github.com/rear/rear

tool: python-eficompressor

~ hucktech ~ Leave a comment

There are a few versions of the EFI compress/decompress tools outside of the UEFI Shell commands, for OS-level usage. Here are two, there are others, I am not sure which is most up-to-date:

https://github.com/sstjohn/python-eficompressor
https://github.com/linearregression/python-eficompressor

Note there is an EfiCompress and EfiDecompress, as well as  TianoCompress (but no TianoDecompress). Comparing to the Tianocore commands for freshness would be useful:

https://github.com/tianocore/edk2-ShellPkg/blob/master/Library/UefiShellDebug1CommandsLib/EfiCompress.c
https://github.com/tianocore/edk2-ShellPkg/blob/master/Library/UefiShellDebug1CommandsLib/EfiDecompress.c
https://github.com/tianocore/edk2-ShellPkg/blob/master/Library/UefiShellDebug1CommandsLib/Compress.c
https://github.com/tianocore/edk2-BaseTools/blob/master/Tests/TianoCompress.py

As well, the UEFI spec has an appendix with some source code on this topic. I have not checked if the source in the spec is in sync with the sources on Tianocore.

I’ve heard that EFI/UEFI has had 4 versions of compression algorithms, at least one of them is broken in a few ways, but I don’t have any specific details. I am not sure of the variatios of the compression algorithms used over time by EFI/UEFI in EDK1 and EDK2, and current UEFI spec. I wish I could find some specific test that verifies these errors. Teddy Reed’s UEFI-Firmware-Parser is also a current tool that deals with this compression issue. I also wonder if there are more recent compression algorithms that’d be better suited for current UEFI usage.

Teddy Reed research on Minnow firmware

~ hucktech ~ Leave a comment

As found by ‘retweeted’ by the CHIPSEC team:

Teddy Reed has an EXCELLENT blog post — the first in a series! — going into detail about the firmware of Intel’s MinnowBoard.

Again, this is an EXCELLENT article, worth reading!

http://prosauce.org/blog/2015/9/13/minnowboard-max-quickstart-uefi-secure-boot

UEFI-NTFS updated

~ hucktech ~ Leave a comment

Pete Batard of Akeo Consulting has updated UEFI:NTFS boot loader:

UEFI:NTFS – Boot NTFS partitions from UEFI

This generic bootloader, which is primarily intended for use with Rufus, is meant to allow seamless booting from an EFI bootloader, that resides on an NTFS partitions. In other words, UEFI:NTFS is designed to remove the UEFI restriction of being able to natively boot from FAT32 only, and allow NTFS boot without the need for any user intervention. This can be used, for instance, for booting an USB Windows NTFS installation media, in EFI mode, allowing support for files that are larger than 4GB (something a native EFI FAT32 partition cannot support), or allow indiscriminate EFI or BIOS boot of Windows To Go drives. The way this works, in conjuction with Rufus, is as follows:

* Rufus creates 2 partitions on the target USB disk (these can be MBR or GPT partitions). The first one is an NTFS partition occupying almost all the drive, that contains the Windows files (for Windows To Go, or for regular installation), and the second is a very small FAT partition, located at the very end, that contains an NTFS EFI driver (see http://efi.akeo.ie) as well as the UEFI:NTFS bootloader.
* When the USB drive boots in EFI mode, the first NTFS partition gets ignored by the EFI firmware and the UEFI:NTFS bootloader from the bootable FAT partition is executed.
* UEFI:NTFS then loads the relevant NTFS EFI driver, locates the existing NTFS partition on the same media, and executes the /efi/boot/bootx64.efi or /efi/boot/bootia32.efi that resides there. This achieves the exact same outcome as if the EFI firmware had native NTFS support and could boot straight from NTFS.

https://github.com/pbatard/uefi-ntfs

Akeo Consulting is an Irish Software Development company, expertise ranging from OSS development, Embedded Systems and SoCs development, Security, Web Services technologies, Operating Systems, Reverse Engineering, e-Papertechnologies and more. Pete has a blog with UEFI- and other firmware-related posts, and other UEFI-related projects.

http://pete.akeo.ie/
http://efi.akeo.ie/
http://akeo.ie

Off-topic rant: These kinds of hacks are needed because UEFI requires FAT32 for it’s EFI System Partition (ESP). Apple also supports HFS+ as well as FAT for their ESP. UEFI spec requires vendors only support FAT. As I understand this, it’s mainly because FAT is widely-supported, Microsoft requires it for Windows OEMs, and having more than one file system would make life a bit more complex for UEFI developers, a complexity that Apple’s UEFI developers are already dealing with.  With a little bit of interop testing, each OS could have an EFI file system that understands it’s preferred native file system format, which may enable better disk encryption, and fewer support issues with the foreign FAT file system. A problem with using any other file system for UEFI is that all vendors won’t necessarily support it, an install-time issue. I wish we had Ext4 and ZFS file system drivers for UEFI in mainstream use (inside IBV solutions, so they’re useful). Microsoft will of course require only FAT for Windows OEMs. Personally, I’d like to see the UDF file system, used by DVDs, more widely adopted as the second file system for UEFI ESP, as a FAT alternative. Most OSes already support UDF (though with some edge-case errors, which could be fixed), and it’s one of the few common file systems that support large files. If you have to deal with some large ISO/image in the UEFI Shell, you’re limited by FAT32’s small file size limits. Someone has already submitted a UDF into Tianocore. It isn’t perfect, there are probably better choices for some flash-based systems, but it could enable a FAT-free Linux/FreeBSD system.

AMI updates firmware of Intel Compute Stick

~ hucktech ~ Leave a comment

BIOS manufacturer AMI has updated their Aptio V UEFI-based firmware solution for the Intel Compute Stick. The update adds “UEFI Bluetooth Keyboard Support”.

Excerpt:
AMI is pleased to announce the addition of UEFI Bluetooth® keyboard support for the Intel® Compute Stick in its flagship Aptio® V UEFI Firmware. The Intel® Compute Stick is a small form factor computer with a quad-core Intel® Atom™ processor and Intel® HD Graphics. It features integrated WiFi® and Bluetooth capability and offers 32 GB of storage and 2 GB of RAM memory along with a USB 2.0 port and microSD™ card reader that can be plugged into any HDMI capable monitor. Users can add their own Bluetooth peripherals, such as keyboard and mouse, to create a full-fledged computer from this tiny yet powerful device. By adding Bluetooth keyboard support to Aptio V, the flagship UEFI firmware from American Megatrends, users of small form factor devices like the Intel® Compute Stick can now access the UEFI BIOS settings with their Bluetooth keyboard to make BIOS customizations that get the most out of these pocket powerhouse computers.
“Intel is pleased to have partnered with AMI on this achievement,” said Joel Christensen, General Manager, Intel® Compute Stick. “Adding the ability to utilize Bluetooth keyboards while in BIOS is a great step in improving the end user experience.”

(I’m not sure if this is a new UEFI protocol for BT keyboards, or just a normal BT stack with a normal keyboard, nor if this is new AMI code or part of what is in Tianocore.org.)

More Information:

http://www.ami.com/news/press-releases/?PressReleaseID=330&/American%20Megatrends%20Adds%20UEFI%20Bluetooth%C2%AE%20Keyboard%20Support%20for%20Intel%C2%AE%20Compute%20Stick%20to%20Aptio%C2%AE%20V%20UEFI%20Firmware/

Linux firmware update

~ hucktech ~ Leave a comment

As pointed out on Phoronix, there’s a new blog post by Peter Jones of Red Hat on the status of firmware updates on Linux.

http://blog.uncooperative.org/blog/2015/09/16/an-update-on-firmware-updates/

Phoronix has been covering this much better than I have:

http://www.phoronix.com/scan.php?page=search&q=ESRT

http://www.phoronix.com/scan.php?page=search&q=fwupd

http://www.phoronix.com/scan.php?page=news_item&px=Linux-UEFI-Firmware-Sept

OpenBSD UEFI progress

~ hucktech ~ Leave a comment

Progress appears to be continuing at the OpenBSD project w/r/t UEFI support, with multiple devices!

Jaspar has a new blog post with information on using OpenBSD on UEFI-based systems.

http://blog.jasper.la/openbsd-uefi-bootloader-howto/

http://undeadly.org/cgi?action=article&sid=20150902074526&mode=expanded&count=6

FWTS updated

~ hucktech ~ Leave a comment

Ivan Hu of Canonical has announced the release of FWTS (FirmWare TestSuite), to 5.09.00. FWTS is a set of command line tools for Ubuntu-based and related Linux systems. It also includes a curses-based interface frontend, which is also the default UI to FWTS-live. FWTS is also included in LUV, the Linux UEFI Validation distribution, but it may be a few days until this latest release has been updated in LUV-live. The release features many bugfixes, as well as some new updates/features, including:

* Update ACPICA to version 20150717
* SMBios 3.0.0 tests supported
* acpi: add _CR3 test
* acpi: add _MTL test
* acpi: add _RST test
* acpi: add _PRR test
* dmicheck: SMBIOS 3.0.0 test

For more information, see the full announcement on the fwts-announce mailling list, and see the full changelog, /usr/share/doc/fwts/changelog.Debian.gz in the source tarball.

https://launchpad.net/ubuntu/+source/fwts
http://fwts.ubuntu.com/release/fwts-V15.09.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.09.00

tool: Subzero

~ hucktech ~ Leave a comment

Teddy Reed, author of UEFI Firmware Parser, and UEFI Spider, also has a related project called Subzero. Excerpting the readme:

The project includes both a web interface and a set of importing and map/reduction scripts used for vulnerability analysis on Firmware Updates (specifically those parsed by uefi-firmware-parser.) The import of firmware is complimented with the descriptions and metadata mined from uefi-spider in JSON form. This web interface will eventually include a submission form used to detect/match unknown updates against the corpus of imported data.

Requirements:
* RethinkDB (python rethinkdb)
* ssdeep (pydeep)
* python-magic
* Ruby/Rails (and the associated gems)
* uefi-spider
* uefi-firmware-parser.

Firmware import: The importing process uses 4 steps, and assumes you have downloaded or crawled firmware update either from vendors or an enterprise: (1) Importing metadata about the updates; (2) Parsing and importing a hierarchy of components within a single firmware update; (3) Comparing product updates and vendor statistics; (4) Scheduling map/reductions to generate statistics on the firmware corpus. Step 2 is quite involved and uses multiple scripts specific to each vendor supported by Subzero. Since each vendor distributes their firmware uniquely, these scripts must preprocess and extract firmware components such as flash descriptors, UEFI Volumes, or other non-monolithic blobs for import. Once this data is isolated Subzero can use specifications and standards (and a lot of python) to parse each subcomponent and store the binary content and hierarchy of relations (a tree).

Features:
* WebUI display of UEFI, Flash, and other firmware formats.
* Graph-views of vendor update frequency, metadata, and firmware changes.
* Vulnerability analysis through a variety of techniques.
* Export and download of firmware components.

Supported Vendors: ASRock, Dell, Gigabyte, Intel, Lenovo, HP, MSI, VMware

https://github.com/theopolis/subzero

tool review: uefi-spider (and firmware_vault)

tool mini-review: UEFI Firmware Parser

VZ on Intel STM

~ hucktech ~ Leave a comment

Vincent Zimmer of Intel wrote a blog on recent Intel UEFI activities relating to open source. He talks about a few things, including “SMI Transfer Monitor (STM)”, recently announced at Intel Developer Forum. I briefly posted on STM, but barely mentioned any details, better points to information are in Vincent’s current post. I hope to see vendors using this powerful technology in the future.

https://firmware.intel.com/blog/developing-best-class-security-principles-open-source-firmware

 

UEFI DMA attack research and code

~ hucktech ~ Leave a comment

Dmytro Oleksiuk (@d_olex) just wrote up some very interesting UEFI security blog post, with CHIPSEC-based sample code!

 Breaking UEFI security with software DMA attacks
Hi everyone! In this article I’d like to tell you more about UEFI vulnerabilities exploitation. Last time, in “Exploiting UEFI boot script table vulnerability” blog post I shown how to execute arbitrary shellcode during early PEI phase which allows to bypass security mechanisms that protects System Management Mode memory (SMRAM) from DMA attacks. Now we will perform such DMA attack on SMRAM to disable BIOS_CNTL flash write protection — it will give us the ability to write infected firmware to ROM chip on the motherboard. This attack can be used for installation of my SMM backdoor without having physical access to the target machine (in previous blog post I explained how it works and how to install it using hardware programmer). My software DMA attack approach for Linux operating system hijacks physical address of DMA buffer used by disk driver, concept of such attack originally was presented in BH US 2008 talk by Rafal Wojtczuk “Subverting the Xen hypervisor”.

http://blog.cr4.sh/2015/09/breaking-uefi-security-with-software.html

https://github.com/Cr4sh/UEFI_boot_script_expl

sysadmin slides from last night

~ hucktech ~ Leave a comment

As mentioned earlier:

Reminder: Seattle-area sysadmin firmware talk Thursday


http://www.sasag.org/2015/08/14/sept-10th-mtg-defending-intel-uefi-systems-from-firmware-attackers/

Last night I gave a talk on UEFI firmware security for a sysadmin POV. This presentation was my first attempt at trying to gather the various hardware lifecycle models into one place, and start adding NIST firmware-centric platform lifecycle as well as currently-available firmware vulnerability assessment an forensic tools to accomplish these new tasks. The models are not well integrated yet. I’ll be giving an improved version of this talk next month at SeaGL.org, and will try to have the model section more clearly written.

On the QEMU/OVMF slide, I say “no danger of bricking hardware”. …I should clarify that. 🙂 By that I meant using fully virtualized environment, there’s no hardware to break. However, you can also use QEMU/OVMF to debug actual hardware (eg, USB devices, PCI cards, etc.), since QEMU can proxy some requests to direct hardware. ….so, you could potentially ‘brick’ some hardware (eg, USB devices, PCI cards, etc.) with QEMU/OVMF, if you’re doing tricky things, and not careful.

NISTs 147 has basic guidance, as well as some ‘extra’ guidance for organizations that want to do more, like keeping a ‘golden image’ of the firmware. (When I first read the 147 spec, I thought the Provisioning stage was a stage for the OEM/IBV and their CAs, not for an enterprise sysadmin…) As I understand it, any ‘golden image’ would be source code, not precompiled firmware ROM binaries. I presume NIST spec was written in to an abstract model, where firwmware sourcecode is fully-available. I presume some governments and large companies would be able to obtain the full source of their firmware from the ISA/OEM/IHV vendors, and do a ‘golden image’. For the rest of world, we have nearly 100% closed-source IBV code, so you can’t do this ‘golden image’-based extra level of guidance.
On Intel systems, the Intel Firmware Support Package (FSP) contains binary-only code (‘blobs’) that UEFI and coreboot use to work on modern Intel systems; unless you have the FSP source, I don’t think an org could do the NIST 147 ‘golden image’ stuff. Some ARM systems, and perhaps AMD with it’s AGESA firmware package, might have more chance at fewer blobs. Fully Open Source Hardware/Firmware/Software-based stacks would enable ‘golden image’, so FOSS has one advantage at NIST 147 support than closed source HW/FW/SW. So Novena and any Libreboot-based system would be good, any modern Intel-based system (including Purism) will not be able to do ‘golden image’ provisioning. Pragmatically, I think the best most of us can do today for the NIST 147 Provisioning stage is run CHIPSEC/FWTS tests against it, and use CHIPSEC or other tools to capture the ROM, and that ROM.bin will be as close as you can get to a ‘golden image’.
Similarly, in the Recovery phase, I’m not sure that most orgs would be able to restore a system with a ROM dump today, without more tool documentation. Instead, I presume any ROM updates are going to be coming from your vendor, using the UEFI update mechanism. If your vendor’s update tools has the ability to ‘roll-back’ to an old image, you’re lucky.

I’d love to get feedback from sysadmins and other vendors about errors in the presentation, hopefully before SeaGL.org, for next revision.

Beyond this talk, LegbaCore has great advise for sysadmins using MITRE Copernicus for Windows enterprises. Copernicus, unlike CHIPSEC, scales, see the LegbaCore talk from RSA 2015.

Click to access sasag20150910.pdf

https://osem.seagl.org/conference/seagl2015/proposal/4

KVM Forum 2015 materials available

~ hucktech ~ Leave a comment

[[ UPDATE: WordPress mangles the below URL to Pauolo’s SMM talk. Download the PDF from the linux-kvm.org link below instead. ]]

The KVM Forum recently finished, and their post-conference materials are available, including videos of some of the presentations. There are multiple interesting talks on QEMU and KVM for security researchers. Two talks that jump out to me are:

Securing secure boot: system management mode in KVM and Tiano Core
by Paolo Bonzini

Click to access 03×06-Aspen-Paolo_Bonzini-Securing_secure_boot.pdf

Using IPMI in QEMU
by Corey Minyard

Click to access 03×08-Juniper-Corey_Minyard-UsingIPMIinQEMU.ods.pdf

More Information:
http://www.linux-kvm.org/page/KVM_Forum_2015

Secure Boot for USBArmory

~ hucktech ~ 2 Comments

[[  UPDATE: Earlier I called this “UEFI Secure Boot”. Vincent Zimmer of Intel read their blog article more closely than I did, read the comment he just made:  click on the “Comment” link on the left side of the blog, At the moment, I am not sure what flavor(s) of “Secure Boot” InversePath is using for the USB Armory. ]]

InversePath has updated the USB Armory to support Secure Boot (unclear what kind of  “Secure Boot” this is..

Interesting read to see what is involved in getting Secure Boot to work, even if you don’t have one of these devices. I like the disclaimer:

IMPORTANT: enabling Secure Boot functionality on the USB armory SoC, unlike similar features on modern PCs, is an irreversible action that permanenty fuses verification keys hashes on the device. This means that any errors in the process or loss of the signing PKI will result in a bricked device uncapable of executing unsigned code. This is a security feature, not a bug. The activation and use of the Secure Boot functionality is therefore at your own risk and must be approached with care.

https://github.com/inversepath/usbarmory/wiki/Secure-boot