Month: March 2017
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
HP seeks firmware pentester
Application Security Engineer – Firmware
HP Cloud Solutions and Operations (CSO) Security is an engineering organization specializing in secure development practices and penetration testing. We are organized as an internal consulting business, enabling our customers to develop and launch a diverse range of customer-facing products including mobile, eCommerce, web services, and embedded. It’s our job to analyze the design, audit the source code, and attempt to break the final product before potential adversaries do. We’re hiring an application security engineer with firmware experience and penetration tester at our new Vancouver, WA office. We have openings for a full-time engineer. Ideally, you have a passion for learning new attack vectors and implementing working exploits. Given your past experience you can improve the security of the architecture, design, authorship, and testing of code. If many of the following apply, you’re probably a good fit.[…]
Trapezoid on lack of firmware security standards
Trapezoid CTO Jose Gonzalez has written a new article on LinkedIn about lack of firmware security in government standards.
[…]What’s the problem? Firmware is powerful code that persists from device restart to restart, sitting below operating systems and driver layers where it can fool anything else on the system – including existing security tools – into thinking everything is working fine. The problem is that very few people are paying attention to protecting the firmware.[…]
Developing a NY DFS Cybersecurity Program? Pay attention to firmware!
https://www.linkedin.com/pulse/developing-ny-dfs-cybersecurity-program-pay-attention-gonzalez
Timothy Pearson of Raptor on closed-source firmware
Timothy Pearson of Raptor Engineering has a blog post talking about the security issues of closed-source firmware ‘blobs’.
[…]So, what are your thoughts on the current x86 proprietary software situation? Are you willing to continue to use FOSS software inside the ever-shrinking x86 “software jail”, or are you possibly willing to give up some cost or performance advantages in order to retain full control of the software running on your hardware? This is a question that will need to be answered soon; the long-term consequences of a fully TiVo-ized computing world are not to be taken lightly, and thus far the free software community has put up very little resistance to the antifeatures being forced into modern x86 platforms. I hope to provoke wider discussion on these topics via this message.
Nikolaj on AMD AGESA/PSP
Nikolaj Schlej made a comment on the recent Snowden/AMD thread. The comment is on Twitter, so it is in multiple messages. I hope that AMD proves him wrong, AMD can change course, so can Intel, if they choose.
https://twitter.com/NikolajSchlej/status/837751682226405379
https://twitter.com/NikolajSchlej/status/837752203490308096
https://twitter.com/NikolajSchlej/status/837752948004388865
https://twitter.com/NikolajSchlej/status/837753773737000960
https://twitter.com/NikolajSchlej/status/837754171642286081
https://twitter.com/NikolajSchlej/status/837754489843109888
https://twitter.com/NikolajSchlej/status/837755046825713666
Syscall-Monitor for Windows
Syscall Monitor is a system monitor program (like Sysinternal’s Process Monitor) using Intel VT-X/EPT for Windows7+
https://github.com/hzqst/Syscall-Monitor
It requires Intel x86/x64 systems with Intel VT-x and EPT support, running Microsoft Windows.
6th RISC-V Workshop: call for papers
Registration and the call for presentations / posters is open for the 6th RISC-V Workshop, co-hosted by NVIDIA and the Shanghai Jiao Tong University (SJTU) in Shanghai China on May 8-11, 2017. As with past workshops, our goals for these events are to bring the RISC-V community together to share information about recent activity in the various RISC-V projects underway around the globe, and build consensus on the future evolution of the instruction set. This will be a four day event broken down as follows[…]
https://riscv.org/2017/03/6th-risc-v-workshop-registration-and-call-for-papers/
Users ask firmware vendors for open source option
Vendors, your compiled code is an firmware attack vector, and makes it harder to trust your product. Secure Boot and signed images are not silver bullets. If you made golden images available, as per NIST 147, we could at least tell if your blobs have changed. But trusting blobs is not enough, there’s enough HW/FW vulnerabilities, and opportunities for attackers to subvert the supply chain. Only open source firmware will solve the firmware blob security problem. Intel has FSP, AMD has AGESA. All IBVs ship closed-source products, no open source vendors, and OEMs/IHVs ship closed-source drivers. Giving us an open source option would solve this problem. IBM claims the OpenPOWER is blob-free, but I’ve yet to verify this. RISC-V is also an ISA that also may be blob-free at the firmware level, depending on the manufacturer. Both OpenPOWER and RISC-V may offer some alternatives to current processors, if they wish to keep with status quo. I hope to see more security standards require the option to build firmware from source, and user ability to reinstall from their own locally-compiled version. And at least requiring that vendors ship hashes for all the blobs they ship.
Dear AMD, could you please release the Platform Security Processor (PSP) source code to the Coreboot / Libreboot project? (or publicly)
[…]
Thanks for the inquiry. Currently we do not have plans to release source code but you make a good argument for reasons to do so. We will evaluate and find a way to work with security vendors and the community to everyone’s benefit.
–AMD_jamesProduct Manager 487 points 4 hours ago
https://www.coreboot.org/Binary_situation https://libreboot.org/faq/#amd
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
ACPI registry updates
https://twitter.com/coreboot_org/status/836748151247749120
It looks like there have been 3 new ACPI regisrations so far this year:
Coreboot Project BOOT 02/28/2017
https://www.coreboot.org/
Exar Corporation EXAR 02/28/2017
https://www.exar.com/
VR Technology Holdings Limited 3GVR 01/19/2017
http://www.3glasses.com/en/
Malware Guard Extension: Using SGX to Conceal Cache Attacks
Malware Guard Extension: Using SGX to Conceal Cache Attacks
Michael Schwarz, Samuel Weiser, Daniel Gruss, Clémentine Maurice, Stefan Mangard
(Submitted on 28 Feb 2017 (v1), last revised 1 Mar 2017 (this version, v2))
In modern computer systems, user processes are isolated from each other by the operating system and the hardware. Additionally, in a cloud scenario it is crucial that the hypervisor isolates tenants from other tenants that are co-located on the same physical machine. However, the hypervisor does not protect tenants against the cloud provider and thus the supplied operating system and hardware. Intel SGX provides a mechanism that addresses this scenario. It aims at protecting user-level software from attacks from other processes, the operating system, and even physical attackers. In this paper, we demonstrate fine-grained software-based side-channel attacks from a malicious SGX enclave targeting co-located enclaves. Our attack is the first malware running on real SGX hardware, abusing SGX protection features to conceal itself. Furthermore, we demonstrate our attack both in a native environment and across multiple Docker containers. We perform a Prime+Probe cache side-channel attack on a co-located SGX enclave running an up-to-date RSA implementation that uses a constant-time multiplication primitive. The attack works although in SGX enclaves there are no timers, no large pages, no physical addresses, and no shared memory. In a semi-synchronous attack, we extract 96% of an RSA private key from a single trace. We extract the full RSA private key in an automated attack from 11 traces within 5 minutes.
Firmware Security 
You must be logged in to post a comment.