BARing the System: New vulnerabilities in Coreboot & UEFI based systems
Tag: UEFI
EFI TBOOT
The EFI TBOOT project is currently under development! EFI TBOOT is mostly a proof of concept at this point. It is not currently functional. It can be built and installed as an EFI boot loader. It only works in conjunction with Xen at the moment. The current development work is being done on Fedora 25 x64. The status as of March 14, 2017 is:
– EFI TBOOT will boot, but it needs a few key strokes to get going (this is for debugging purposes).
– EFI TBOOT will relocate itself to EFI runtime memory and setup a shared runtime variable with Xen.
– EFI related configuration setup is done as well as standard TBOOT pre-launch configuration.
– Xen is launched and has code to call EFI TBOOT back after EBS.
– EFI TBOOT then does the SENTER successfully in the callback.
– The post launch entry point is reached but the switch back to long mode is not working.
[…]
EFI TBOOT needs a number of platform support files used with TXT (called Authenticated Code Modules or ACMs). For convenience the packages can be gotten from the OpenXT mirror:
http://mirror.openxt.org/
[…]
UEFI-Dumper
“UEFI-Dumper is a simple perl script to get access to your Insyde Bios hidden menus.”
The source code says: Copyright (c) 2013 Nurlan Mukhanov (aka Falseclock).
https://github.com/Falseclock/UEFI-dumper
The tool appears brand-new, from Github epoch. But given the 2013 date in the copyright, it is probably older. A quick search finds the same code from a 3-year-old post:
http://developers-club.com/posts/182676/
When I noticed this, I sent an FYI to the the UEFI Security team and to Insyde’s security team, in case they hadn’t seen it. Kevin Davis of Insyde responded with:
“Insyde Software takes the security of our customer’s platforms very seriously. InsydeH2O and SETUP page settings are based on public specifications. Insyde is aware that the UEFI-Dumper allows individuals to get the information about SETUP pages that customers have hidden. Insyde believes that current customer platforms are following our guidelines for protecting sensitive system variables from malicious changes. As the first BIOS vendor to ship production systems supporting the UEFI standards, Insyde has always worked to improve the UEFI standards and our InsydeH2O BIOS. Our customers are encouraged to work with their Insyde contacts to continue to build secure systems.”
LUV adds EFI_WARN_ON_ILLEGAL_ACCESSES
Sai Praneeth Prakhya of Intel has posted a patch to the LUV project list, with new clever new abilities to increase LUV’s ability to detect bad UEFI firmware.
Presently, LUV detects illegal accesses by firmware to EFI_BOOT_SERVICES_* regions only during “SetVirtualAddressMap()”. According to UEFI spec, this function will be called only once; by kernel during boot. Hence, LUV cannot detect any other illegal accesses that firmware might do after boot. Moreover, LUV can detect illegal accesses *only* to EFI_BOOT_SERVICES_CODE/DATA regions. This patch set tries to address the above mentioned two issues:
1. Detect illegal accesses to other EFI regions (like EFI_LOADER_CODE/DATA, EFI_CONVENTIONAL_MEMORY)
2. Detect illegal accesses to these regions even after kernel has booted
Recently, we came across machines with buggy firmware that access EFI memory regions like EFI_CONVENTIONAL_MEMORY, EFI_BOOT_SERVICES_CODE/DATA and EFI_LOADER_CODE/DATA even after kernel has booted. Firmware accesses these regions when some efi_runtime_service() is invoked by test cases like FWTS. These illegal accesses can potentially cause kernel hang. Hence, it’s good to have a test case in LUV which can detect these illegal accesses and hence report them to user. This requires making changes to kernel and searching dmesg for relative warnings. As there are 9 patches to linux kernel to enable this feature and putting all these 9 kernel patches in a single LUV patch makes the LUV patch gigantic; hence I have split them into smaller ones (as suggested by Ricardo). The first patch in this series (“linux-yocto-efi-test: Do not support EFI_BOOT_SERVICES_WARN”) removes support to “EFI_BOOT_SERVICES_WARN” and the later patches add all the bits and pieces together and the 10th patch (“linux-yocto-efi-test: Introduce EFI_WARN_ON_ILLEGAL_ACCESSES”) enables the (new) feature.
Full patch:
https://lists.01.org/mailman/listinfo/luv
.
scan_thinkpwn: searches for ThinkPwn vulnerability
THINKPWN SCANNER: This program is used to scan UEFI drivers extracted from firmware image for ThinkPwn vulnerability in vendor/model agnostic way.
AUTHORS:
@d_olex (aka Cr4sh) — initial Vivisect based version of the program;
@trufae (aka pankake) — radare2 based version (this one);
Read the source code for more user docs, including a detailed source comment about how the code works.
https://github.com/Cr4sh/ThinkPwn/blob/master/scan_thinkpwn.py
More info:
https://github.com/Cr4sh/ThinkPwn
http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html
uefi_multiboot: create UEFI-compatible images
uefi_multiboot: Create UEFI-compatible boot drive supporting multiple ISO images.
It requires UEFI-based target systems, and Ubuntu-system to build, and a disposable USB drive (everything on drive will be deleted).
https://github.com/sundarnagarajan/uefi_multiboot
(Someone looking to create a script that generates a UEFI boot drive could also benefit from using parts of this script.)
UEFI_ListPci: UEFI tool to list PCI/PCIe devices
UEFI_ListPci is a new UEFI Application that uses UEFI protocol to enumerate PCI/PCIe devices.
https://github.com/Justgocode/UEFI_ListPci
(There is also the UEFI Shell’s PCI command, included in Tianocore.org.)
UEFI-Rebooter
“UEFI-Rebooter is a bash script for implementing dual boot through uefi.” It is labelled “Windows Boot Manager”, and calls Linux’s efibootmgr as it’s main tool.
https://github.com/Dertosh/UEFI-Rebooter
https://github.com/Dertosh/UEFI-Rebooter/blob/master/UEFI-rebooter.sh
Finbarr’s TPM 2.0 PCR Tool
Finnbarr P. Murphy has a new blog post about a new UEFI-based TPM tool he’s written.
[…]By the way, if you have access to the Intel TXT (Trusted Execution Technology) EFI compliance testing toolkit, the included utility, pcrdump.efi, provides similar functionality to the utility described in this post.[…]
http://blog.fpmurphy.com/2017/01/uefi-utility-to-read-tpm-1-2-pcrs.html
See more of his UEFI Utilities:
Apple seeks Core EFI Manager and Mac EFI Bring Up Engineer
The Mac Platform Software team is looking for a talented engineering manager to lead a team of firmware and systems software engineers responsible for developing Apple’s UEFI implementation and related technologies for the Mac product line. Mac Platform Software is responsible for bringing up macOS and Windows on all new Mac products, including the development and integration of firmware and systems software for macOS and Windows, the development of platform-level features for the Mac, and the leadership of cross-functional debug and optimization efforts across hardware and software teams.[…]
https://jobs.apple.com/search?job=56058298&openJobId=56058298#&openJobId=56058298
The Mac Platform team in Core OS is looking for a talented UEFI engineer to work on the bring-up of new Mac products. Breathe life into new Mac products by developing firmware across all phases of development, from pre-silicon to product ramp.[…]
https://jobs.apple.com/search?job=56058163&openJobId=56058163#&openJobId=56058163
CHIPSEC gets new UEFI Whitelist command
CHIPSEC already has a Blacklist command. Now there is a UEFI whitelist command.
more on CIA UEFI malware
Some comments from Yuriy of the Intel ATR team:
more on CIA UEFI wikileaks pages
More on CIA UEFI wikileaks pages:
EDB, Embedded Development Branch (includes UEFI):
https://wikileaks.com/ciav7p1/cms/space_753667.html
Active UEFI projects:
https://wikileaks.org/ciav7p1/cms/page_26968082.html
DerStarke project:
https://wikileaks.org/ciav7p1/cms/page_3375125.html
QuarkMatter project:
https://wikileaks.org/ciav7p1/cms/page_21561431.html
https://wikileaks.org/ciav7p1/cms/page_9535555.html
https://wikileaks.org/ciav7p1/cms/index.html
tutorial on using UDK with Linux:
Wikileaks on CIA UEFI malware
https://wikileaks.org/ciav7p1/cms/page_26968080.html
https://wikileaks.org/ciav7p1/cms/page_36896783.html
https://wikileaks.org/ciav7p1/cms/page_29851664.html
https://wikileaks.org/ciav7p1/cms/page_29851664.html
https://wikileaks.org/ciav7p1/cms/page_27721733.html
https://wikileaks.org/ciav7p1/cms/page_27262984.html
https://wikileaks.org/ciav7p1/cms/page_26968084.html
UEFI gets AMD Secure Encrypted Virtualization (SEV) support
AMD has submitted a similar patch to the Linux kernel, now there is support for AMD SEV in UEFI.
[RFC PATCH v1 0/5] x86: Secure Encrypted Virtualization (AMD)
This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. The SEV feature allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest VM. The memory controller contains a high performance encryption engine which can be programmed with multiple keys for use by a different VMs in the system. The programming and management of these keys is handled by the AMD Secure Processor firmware which exposes a commands for these tasks. SEV guest VMs have the concept of private and shared memory. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key. Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit, and is fully controlled by the guest. Due to security reasons all the DMA operations inside the guest must be performed on shared pages (C-bit clear). Note that since C-bit is only controllable by the guest OS when it is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the C-bit to a 1. KVM SEV RFC [1] extends the KVM_FEATURE cpuid instruction to indicate whether SEV is enabled. When SEV is enabled then OVMF can use cpuid Fn8000_001F[BX] to get the C-bit position in PTE.
AMD Memory Encryption whitepaper:
Click to access AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
AMD64 Architecture Programmer’s Manual (SME is section 7.10, SEV is section 15.34):
Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
KVM Forum Presentation:
Click to access 02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
UEFI lab at Cascadia IT Conference in Seattle March 10th
[DISCLAIMER: FirmwareSecurity is my personal blog. I work at PreOS Security.]
PreOs Security is offering a half-day training lab for System Administrators, SRE/DevOps in the Seattle area at Cascadia IT Conference, for those interested in learning about UEFI/ACPI/BIOS/SMM/etc security. Here’s the text for the training:
Defending System Firmware
Target audience: System administrators, SRE, DevOps who work with Intel UEFI-based server hardware
Most enterprises only defend operating system and application software; system and peripheral firmware (eg., BIOS, UEFI, PCIe, Thunderbolt, USB, etc) has many attack vectors. This workshop targets enterprise system administrators responsible for maintaining the security of their systems. The workshop is: an introduction to UEFI system firmware, an overview of the NIST secure BIOS platform lifecycle model of SP-(147,147b,155) and how to integrate that into normal enterprise hardware lifecycle management, and an introduction to the available open source firmware security tools created by security researchers and others, and how to integrate UEFI-based systems into the NIST lifecycle using available tools, to help protect your enterprise. It will be a 3.5 hour presentation, and at the end, you can optionally can run some tests on your laptop: Intel CHIPSEC, Linux UEFI Validation distribution (LUV-live), FirmWare Test Suite live boot distribution (FWTS-live), and a few other tools. Attendees trying to participate in the lab will need to have a modern Intel x86 or x64-based (not AMD), UEFI-based firmware, running Windows or Linux OS software. That means no AMD systems, no Apple Macbooks, no ARM systems. Any system used in the lab must have all data backed up, in case some tool bricks the device. Attendees should understand the basics of system hardware/firmware, be able to use a shell (eg, bash, cmd.exe, UEFI Shell), and able to use Python-based scripts.
announcing PreOS Security Inc.
FirmwareSecurity.com is my personal blog. I use it to post information about firmware as I come across it, in the hope that it might help others. I try to keep it impersonal and only focus on news/information, but my bias towards open source HW/FW/SW is not hard to find.
I started the blog a few years ago to learn firmware by focusing on the security perspective of firmware and learning from existing security researchers. I’d been doing OS-level driver consulting for a while, and was moving from OS-level moving down into firmware. Along the way, I’ve learned a lot and given talks and training on firmware security at LinuxFest Northwest, B-Sides PDX, SOURCE Seattle, and other places.
With great advice from both firmware engineers as well as firmware security researchers, I’ve seen an opportunity to help secure enterprises at the firmware level.
I’ve started a small new company, PreOS Security Inc., https://preossec.com/ . Besides attending the last UEFI Plugfest, we’ve been mostly in ‘stealth mode’, busy working on code. We have a small group of advisors who are teaching us lots of things about security/b2b/tool startups.
We’re creating a product to help enterprises secure their system firmware, as per NIST SP 800-147 guidance. We’re leveraging the expertise of existing firmware security researchers, and some of their tools (for example CHIPSEC). We’re also writing new tools to fill in some of the gaps. Our product is currently in a pre-alpha stage, and are looking for a few enterprises who’re eager to secure their firmware to work on the alpha release.
We have a draft document on ‘enterprise firmware guidance’ that we’ll be publishing on our web site (and Github), as well as that ‘awesome firmware’ links that I’ve been promising in previous blog posts. We have some patches to existing tools that we need to upstream.
We also offer training to UEFI/ACPI device vendor QA teams, data centers, and security-minded enterprises, on using firmware security tools, and consulting to customize/integrate these tools. We’ve got a half-day training event that we’ll announce shortly.
We need a Python developer, either as a partner, or a few as contractors. Currently we have equity to offer. For more information, see: https://preossec.com/careers/ .
We’re currently self-funded, hoping to fund our product development with training/consulting. But to offer more than equity, we’ve begun looking at some other sources of funding. If there are any firmware-friendly angel investors reading this, we should talk.
Hyper-V UEFI bootloader complexities
[…]Forcing GRUB installation to EFI removable media path does basically the same thing as when Ubuntu installer asks you if you want to force UEFI installation: it installs to the removable media path in the ESP (EFI System Partition). This is fine for environment where no other operating system is present. However if there is another operating system present on the device which depends on this fallback location “removable media path” it will make this system temporary unbootable (you can manually configure GRUB later to boot it if necessary though). Windows installer for example *also* installs to the removable media path in the ESP. All OS installers installing things to this removable media path will conflict with any other such installers and that’s why in Debian (and Ubuntu) installers don’t do this by default. You explicitly have to select UEFI mode during the normal installation (what I did).[…]
NATO on UEFI attack vectors
Glad to see forensic community realizing that there is more under the hood than they’ve been paying attention to. A new PDF in the SANS Digital Forensics reading room:
Analysis of the building blocks and attack vectors associated with the Unified Extensible Firmware Interface (UEFI)
Author: Jean-François Agneessens (jean.agneessens@ncirc.nato.int)
Advisor: Manuel Humberto Santander Pelaez
While Operating Systems have seen tremendous and very visible developments, driven by the evolution of hardware components, there are still some remnants from the 8086-era, one of which is the BIOS. Led by a consortium of vendors, the industry is now implementing a new style of BIOS which, by design, appears to overcome all the issues introduced by the Intel 8086 engineering decisions back in 1978. The Unified Extensible Firmware Interface (UEFI), replacement of the legacy BIOS, is a blank-sheet design based on modular pieces of code following the well-known Portable Executable/Common Object File Format (PE/COFF), found on all Microsoft OS-based executable code. The UEFI code can therefore be reverse-engineered using similar techniques learned during GREM. The concepts of UEFI, and some of its VMware implementation, are presented here, as well as an insight into the possible paths open for further exploitation of the extended capabilities offered by UEFI.
somewhat related:
http://www.nato.int/cps/en/natohq/news_118855.htm
Microsoft seeks Senior UEFI Engineer
The Surface Team focuses on building devices that fully express the Windows vision. Be part of the team that brings to life experiences in Microsoft Windows and Office through the hardware of its Microsoft Surface product line. Our team develops the UEFI and firmware that connects the operating system to the hardware. Candidate will be a member of the Surface SW/FW team and be responsible for developing, adapting and fixing code related to UEFI. As a member of the team, candidate will actively participate on development practices such as task planning/sizing and scheduling, bug triage and bug management. Candidate will actively participate in SCRUM meetings, documenting progress and updating tasks. Candidates are expected to collaborate and familiarize with other functions within the team in order to develop BIOS code that adapts the HW to platform requirements. […]
https://careers.microsoft.com/jobdetails.aspx?jid=275588&job_id=1016471
Firmware Security 
You must be logged in to post a comment.