Firmware at Intel Developer Forum

IDF, Intel’s Developer Forum, is happening shortly, August 18-20 (or so). It appears Brian and Vincent of Intel UEFI will be speaking, at least:

Vendors usually announce/release new things at their annual conferences, so I’m looking forward to seeing what Intel does… With 201 sessions, only a 2-minute glance at the schedule, here’s a teaser (but not all) of the more interesting presentations I noticed:

STTS001 — Firmware in the Data Center: Building a Modern Deployment Framework Using Unified Extensible Firmware Interface (UEFI) and Redfish REST APIs
STTS002 — Building a Firmware Component Ecosystem with the Intel® Firmware Engine
ACAS002 — Defense Against the Dark Arts – Introduction to Malware Research
STTS003 — Developing Best-in-Class Security Principles with Open Source Firmware
DCWC005 — Tech Chat: Trusted Networks in the Cloud – Attestation of Network Elements for Secure Cloud
ISGC003 — Tech Chat: A Primer on Intel® Software Guard Extensions (Intel® SGX)
SFTC003 — Tech Chat: Securing the Internet of Things with Intel® Micro Runtime (Intel® MRT)
ARCS003 — Intel® Architecture Code Name Skylake Deep Dive: Hardware-Based Security for Windows® 10
SPCS012 — Zoom-in on Your Code with Intel® Processor Trace and Supporting Tools
ISGC001 — Tech Chat: Intel® Security Controller – The Platform to Automate Your Security Application for Software-Defined Infrastructure
MAKE003 — Hands-on Maker Lab: Bring Up a MinnowBoard, the Intel® Atom™ Processor Based Open Hardware Platform
STTC003 — Tech Chat: Using Intel® Firmware Engine to Generate Simulated Platforms for Wind River Simics*
DCWC007 — Tech Chat: Differentiating Your Data Center Platforms in Firmware
ISGC003 — Tech Chat: A Primer on Intel® Software Guard Extensions (Intel® SGX)
SFTC003 — Tech Chat: Securing the Internet of Things with Intel® Micro Runtime (Intel® MRT)
SPCC002 — Tech Chat: A Wireless Smartphone-Based Pulmonary Function Analyzer
HSTS004 — Thunderbolt™ 3 Technology and USB-C*
INFS009 — Trusted Containers and VMs in Cloud Environments
ISGS004 — Biometric Authentication in Trusted Execution Environments
RPCS009 — Developer Training on Intel® Active Management Technology
SSDS004 — The Future of Storage Security

http://www.intel.com/content/www/us/en/intel-developer-forum-idf/san-francisco/2015/idf-2015-san-francisco-agenda.html

http://www.intel.com/content/www/us/en/intel-developer-forum-idf/san-francisco/2015/idf-2015-san-francisco.html

Purism laptops and FSP blobs

Purism is getting some slack about it’s firmware:

http://www.phoronix.com/scan.php?page=news_item&px=Purism-Librem-Still-Blobbed
https://www.phoronix.com/scan.php?page=news_item&px=Librem-15-Rev-2-Coreboot
http://www.phoronix.com/scan.php?page=news_item&px=coreboot-dev-purism
http://www.pcworld.com/article/2960524/laptop-computers/why-linux-enthusiasts-are-arguing-over-purisms-sleek-idealistic-librem-laptops.html
http://www.phoronix.com/forums/forum/software/mobile-linux/813274-purism-librem-laptops-remain-blobbed-up-less-than-interesting

The first one had a stock UEFI BIOS, the second one will apparently have a coreboot BIOS with a Purism-customized FSP.
It’s not too hard to fork a new Debian OS (PureOS), there’re many to emulate. But being a micro-sized OEM means you have to deal with COTS hardware, which have blobs.

You can’t build a modern computer w/o using it’s hardware. The firmware enables this. Open source projects like Tianocore or coreboot don’t have all the necessary firmware to enable this hardware. On Intel systems, they need the Intel Firmware Support Package (FSP), all the “blobs” needed to enable the hardware. OEMs and IBVs take Intel’s FSP blobs and combine them with the tianocore UEFI code or the coreboot code, and build a firmware image for their system. Some IBVs create their own firmware from spec, w/o FSP, but that is going to take a lot of work, and the NDA’ed material probably means no open source version.

http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html

Purism apparently is a licensee of the Intel FSP source code, so they can edit the FSP source and recompile them. I presume this means Purism is under NDA with Intel, and can’t give some details of what they’re doing.

There will always be blobs in current Intel systems. Purism may reduce the number of FSP blobs, but can’t eliminate them. Perhaps Purism should focus on AMD systems, if ASEGA(sp) is open source? Perhaps Purism should focus on ARM systems, where — if sufficiently funded, they could build a chip with just the parts they want; still there are ARM Ltd NDAs. I don’t think Purism — or any similar Linux OEM — will be able to create anything useful until RISV-V is an alternative to the mainstream chips, in a few years. 😦

I  hope Purism checks CHIPSEC results before they ship their product. 🙂
I wish Intel would open source FSP. I presume that can’t be done due to NDA issues. I wonder if the open source community would sponsor an FSP alternative, if they could accomplish it w/o the NDA’ed data?

Intel to use Xeon E3-1500M v5 in notebooks

Last week Intel announced the upcoming Xeon Processor E3-1500M v5 Product Family for notebooks. This is the 6th Generation Intel Core family based on Skylake architecture.

“Intel Xeon-based mobile workstations will have key features such as error-correcting code memory that automatically detects and repairs errors on-the-fly that cause data corruption and system crashes for peace-of-mind reliability. These new systems will also enjoy the benefits of the unique hardware-assisted security, manageability, and productivity capabilities of Intel vPro Technology. Mobile workstations featuring Intel Xeon will also feature Thunderbolt 3 – the USB-C that does it all.”

http://blogs.intel.com/technology/2015/08/bringing-intel-xeon-to-notebook-pcs/

LTE modem exploitation gives attackers online access

Yesterday at DEF CON 23 this talk happened:

Scared Poopless – LTE and *your* laptop
Mickey Shkatov, Jesse Michael
“With today’s advancement in connectivity and internet access using 3G and LTE modems it seems we all can have a device that’s always internet capable, including our laptops, tablets, 2 in 1’s ultrabook. It becomes easier to be online without using your WiFi at all.  In our talk we will demonstrate and discuss the exploitation of an internal LTE modem from Huawei which can be found in a number of devices including laptops by HP.”

The slides are now available:

Click to access Intel_DC23_SPLTE.pdf

http://www.intelsecurity.com/advanced-threat-research/index.html

Xen releases Libbdvmi, Bitdefender VM introspection library

Xen has created a new library, Libbdvmi, the Bitdefender VM introspection library, an x86-centric library, supported by Xen 4.6.

In our quest for zero-footprint guest introspection using Xen, we needed to be able to decide whether changes to the guest OS are benign or malicious, and, once decided, to control whether they are allowed to happen, or rejected. To that end, we needed a way to be notified of interesting Xen guest events, with a very low overhead, that we could use in dom0 (or a similarly privileged dedicated domain), and that would connect our introspection logic component to the guest. We’re very happy to announce that the library we’ve created to help us perform virtual machine introspection, libbdvmi, is now on GitHub, under the LGPLv3 license, here. The library is x86-specific, and while there’s some #ifdeferry suggesting that the earliest supported version is Xen 4.3, only Xen 4.6 will work out-of-the-box with it. It has been written from scratch, using libxenctrl and libxenstore directly. Libbdvmi aims to provide a very efficient way of working with Xen to access guest information in an OS-agnostic manner:

* it only connects an introspection logic component to the guest, leaving on-the-fly OS detection and decision-making to it;
* provides a xenstore-based way to know when a guest has been started or stopped;
* has as few external library dependencies as possible – to that end, where LibVMI has used Glib for caching, we’ve only used STL containers, and the only other dependencies are libxenctrl and libxenstore;
* allows mapping guest pages from userspace, with the caveat that this implies mapping a single page for writing, where LibVMI’s buffer-based writes would possibly touch several non-contiguous pages;
* it works as fast as possible – we get a lot of events, so any unnecessary userspace / hypervisor context switches may incur unacceptable penalties (this is why one of our first patches had vm_events carry interesting register values instead of querying the quest from userspace after receiving the event);
* last but not least, since the Xen vm_event code has been in quite a bit of flux, being able to immediately modify the library code to suit a new need, or to update the code for a new Xen version, has been a bonus to the project’s development pace.

https://github.com/razvan-cojocaru/libbdvmi
https://blog.xenproject.org/2015/08/04/the-bitdefender-virtual-machine-introspection-library-is-now-on-github/

CHIPSEC on DEF CON Conference CD


Apparently CHIPSEC is on the DEF CON 23 CD:

The DEF CON home page has a link to download the Conference CD. I’ve not done a diff yet, but it appears to still be version 1.21. If it has anything newer than 1.21, it is newer than their Github public release, and should be checked out immediately! There is a new S3bootscript security test in the works…

As much as I trust the DEF CON Goons, I might not run any binaries from this CD, and would diff the sources against the public CHIPSEC github release before running it. 🙂

https://defcon.org/

Conference CD, Direct Download:
https://media.defcon.org/DEF CON Conference CD DVD/DEF CON 23 Original Hacking Conference DVD.rar”
https://media.defcon.org/DEF%20CON%20Conference%20CD%20DVD/DEF%20CON%2023%20Original%20Hacking%20Conference%20DVD.rar

Conference CD, Directory of Files:
https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/Extras/1o57/Extras/chipsec-master/source/tool/chipsec/modules/common/”
https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/Extras/1o57/1o57.txt”

Post-Domas Intel BIOS update

Intel has released some BIOS updates after Domas’ recent vulnerability:

Domas’ x86 vulnerability

Title: Local APIC Elevation of Privilege
Intel ID: INTEL-SA-00045
Impact of vulnerability: Elevation of Privilege
Severity rating:  Important
Original release:  Aug 04, 2015

Intel is releasing mitigations for a privilege escalation issue. This issue affects certain Intel processors based on older Intel micro-architectures. The issue identified is a method that enables malicious code to gain access to SMM. An issue was disclosed to Intel which leverages architectural differences in processors prior to 2nd Generation Intel Core Processors to gain access to SMM. Administrator or root level privileges are required to execute the attack.
 
Affected products: Intel Server Board S5500BC, Intel Server Board S5500HCV, Intel Server Board S5500HV, Intel Server Board S5500WB, Intel Server Board S5520HC, Intel Server Board S5520HCT, Intel Server Board S5520UR, Intel Workstation Board S5520SC
    
Intel highly recommends applying the mitigations.
 
Intel would like to acknowledge Christopher Domas of Battelle for working with us on this coordinated disclosure.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00045&languageid=en-fr

New HardenedBSD release

A new release of HardenedBSD is available: v28 version of 10-STABLE as well as 11-CURRENT.

HardenedBSD is a security-enhanced fork of FreeBSD, created in 2014 by Oliver Pinter and Shawn Webb. HardenedBSD aims to implement innovative exploit mitigation and security solutions for FreeBSD. The project works with upstream FreeBSD and any other FreeBSD-based project to include any security improvements. NanoBSD is the embedded subset of FreeBSD. FreeBSD — at least the last time I checked — was the only BSD distro that supports UEFI. Recently, HardenedBSD 11-CURRENT was released:
https://hardenedbsd.org/article/oliver-pinter/2015-07-24/hardenedbsd-11-current-amd64-x86-64-installers
https://github.com/HardenedBSD/hardenedBSD

The AArch64 port of FreeBSD has been progressing well. I’ve not built HardenedBSD for AArch64 myself yet, but it appears that someone can, there’s a VM version at least:
https://twitter.com/lattera/status/628701851286962177

Intel Firmware Engine SDK 1.0 for Windows released

Yesterday Intel released the 1.0 SDK for their Firmware Engine.

The Intel(R) Firmware Engine simplifies and accelerates the creation of platform firmware images, allowing developers to quickly deploy platforms based on Intel reference designs. Customers can configure firmware features using a catalog of compatible firmware components, without the need to modify source code. It enables simple changes of the binary image of the firmware from reference platform to derivative product, allowing developers to configure firmware features based on their product customizations. This development process accelerates adding and removing firmware features not found in reference platform, adding third-party components not provided with reference platform, and integrating custom boot payloads. Developers can also extend functionality using the Intel(R) Firmware Engine Software Development Kit (SDK). Existing Intel(R) UDK2014 code can be extended to work with Intel Firmware Engine, allowing silicon component vendors and firmware developers to rapidly extend the Intel Firmware Engine ecosystem.”

http://firmware.intel.com/learn/intel-firmware-engine/downloads
http://firmware.intel.com/sites/default/files/Intel%C2%AE%20Firmware%20Engine%20SDK%20Release%201.0.zip

The Firmware Engine and it’s SDK only work with Microsoft(R) Windows. If you don’t use Windows, you’ll find this SDK useless. I prefer the approach taken with the UEFI Driver Wizard, which was created with a cross-platform GUI (wxWidgets), and source code was released. Focusing on Windows-only developers alienates Mac and Linux (and FreeBSD) OS vendors and developers, all of which have UEFI firmware and may benefit from this engine and it’s SDK.  I wish Intel would target cross-platform developer tools. I wish the sources were available, so the non-Windows community could help Intel to port their code to other OSes.

Thunderstrike 2 research available

The slides from the Black Hat Briefings’ talk on Thunderstrike2 are now online:

This talk won a Pwnie!

Thunderstrike 2: Sith Strike

Click to access ts2-blackhat.pdf

http://legbacore.com/Research_files/ts2-blackhat.pptx
http://legbacore.com/Research_files/ts2-blackhat.key

http://legbacore.com/Research.html
https://trmm.net/Thunderstrike_2

Domas’ x86 vulnerability

UDPATE:

https://github.com/xoreaxeaxeax/sinkhole

Lucian Constantin has two articles (one in Computer World, one in PC World), on Christopher Domas’ Black Hat Briefings presentation.

Design flaw in Intel chips opens door to rootkits
http://www.computerworld.com/article/2962325/computer-processors/design-flaw-in-intel-chips-opens-door-to-rootkits.html
http://www.pcworld.com/article/2965872/components-processors/design-flaw-in-intel-processors-opens-door-to-rootkits-researcher-says.html

The Memory Sinkhole – Unleashing an x86 Design Flaw Allowing Universal Privilege Escalation
Christopher Domas
https://www.blackhat.com/us-15/briefings.html#the-memory-sinkhole-unleashing-an-x86-design-flaw-allowing-universal-privilege-escalation
“In x86, beyond ring 0 lie the more privileged realms of execution, where our code is invisible to AV, we have unfettered access to hardware, and can trivially preempt and modify the OS. The architecture has heaped layers upon layers of protections on these negative rings, but 40 years of x86 evolution have left a labyrinth of forgotten backdoors into the ultra-privileged modes. Lost in this byzantine maze of decades-old architecture improvements and patches, there lies a design flaw that’s gone unnoticed for 20 years. In one of the most bizarre and complex vulnerabilities we’ve ever seen, we’ll release proof-of-concept code exploiting the vast, unexplored wasteland of forgotten x86 features, to demonstrate how to jump malicious code from the paltry ring 0 into the deepest, darkest realms of the processor. Best of all, we’ll do it with an architectural 0-day built into the silicon itself, directed against a uniquely vulnerable string of code running on every single system.

Christopher’s slides and paper are now available:

Click to access us-15-Domas-The-Memory-Sinkhole-Unleashing-An-x86-Design-Flaw-Allowing-Universal-Privilege-Escalation-wp.pdf

Click to access us-15-Domas-The-Memory-Sinkhole-Unleashing-An-x86-Design-Flaw-Allowing-Universal-Privilege-Escalation.pdf

Genode OS v15.05

Found on Joanna’s Twitter feed:
https://twitter.com/rootkovska/status/629256162706329601

Genode is new to me. Genode Labs makes the “Genode OS Framework”. Genode is a new OS, not a new Linux distribution. It is “a GPLv2-licensed construction kit for building specialized operating systems out of small building blocks including different kernels, device drivers, protocol stacks, and applications”. This current release is a major release for Genode. The new documentation is a large 472 page PDF. The current release adds “rudimentary GPT” support. GPT aside, I don’t see any other UEFI-related technology support, only “BIOS” references to firmware.

Version 15.05 represents the most substantial release in the history of Genode. It is packed with profound architectural improvements, new device drivers, the extension of the supported base platforms, and a brand new documentation.

We understand the complexity of code and policy as the most fundamental security problem shared by modern general-purpose operating systems. Because of high functional demands and dynamic workloads, however, this complexity cannot be avoided. But it can be organized. Genode is a novel OS architecture that is able to master complexity by applying a strict organizational structure to all software components including device drivers, system services, and applications.”

“The current implementation can be compiled for 8 different kernels: Linux, L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, Codezero, and a custom kernel for running Genode directly on ARM-based hardware. Whereas the Linux version serves us as development vehicle and enables us to rapidly develop the generic parts of the system, the actual target platforms of the framework are microkernels. There is no ‘perfect’ microkernel – and neither should there be one. If a microkernel pretended to be fit for all use cases, it wouldn’t be ‘micro’. Hence, all microkernels differ in terms of their respective features, complexity, and supported hardware architectures.

Genode allows the use of each of the kernels listed above with a rich set of device drivers, protocol stacks, libraries, and applications in a uniform way. For developers, the framework provides an easy way to target multiple different kernels instead of tying the development to a particular kernel technology. For kernel developers, Genode contributes advanced workloads, stress-testing their kernel, and enabling a variety of application use cases that would not be possible otherwise. For users and system integrators, it enables the choice of the kernel that fits best with the requirements at hand for the particular usage scenario.

Inverse Path’s USB Armoury supports Genode as of 15.02:  “The Genode OS Framework supports the USB armory since version 15.02 implementing a TrustZone Secure virtual-machine monitor (VMM) supervising Linux running in the Normal world. Support is in the very early stages. The Linux kernel requires minimal patching to be executed in the Normal world, at the moment Martin Stein from Genode Labs provides a repository with a patched kernel.

http://genode.org/documentation/release-notes/15.05
https://github.com/genodelabs/genode
http://sourceforge.net/projects/genode/files/

No Starch Press: Rootkits and Bootkits

[Wow!]

Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats
by Alex Matrosov, Eugene Rodionov, and Sergey Bratus

Spring 2016, 304 pp.
ISBN: 978-1-59327-716-1
$39.95 EARLY ACCESS Ebook
$49.95 Print Book and EARLY ACCESS Ebook

Get 30% off with the coupon code EARLYBIRD

Modern malware is always evolving because malware authors are constantly finding new ways to bypass security and avoid detection. Defending against (and even discovering) the latest malicious software requires cunning and extensive expertise because attackers have become much more sophisticated.

One particularly fascinating and threatening area of malware development is that of rootkits and bootkits. We’re talking hard stuff – attacks buried deep in a machine’s boot process or firmware. These are the kind of attacks that keep malware analysts up late at night. But help is on the way.

In Rootkits and Bootkits, authors Alex Matrosov, Eugene Rodionov, and Sergey Bratus share the knowledge and expertise they’ve gained during years of professional research. You’ll learn how to expose hidden files systems that can make rootkits so hard to identify and remove. You’ll explore how malware has evolved from rootkits like TDL3 to the present; how this stealthy software can take hold of a system; and how to counter anti-debugging, anti-disassembly, and anti-virtual machine measures. You’ll also learn how bootkits work, and how Windows boots so that you can better prevent infections in the first place.

Cybercrime syndicates and malicious actors keep pushing the envelope, writing ever more persistent and covert attacks. But the game is not lost. In this low-level tour through the wilds of malware, you’ll learn how to reverse next generation threats. Explore the cutting edge of malware analysis with Rootkits and Bootkits.
About the Author

Alex Matrosov has more than 10 years experience with malware analysis, reverse engineering and advanced exploitation techniques. He is a senior security researcher in the Advanced Threat Research team at Intel Security Group and prior to this role, he spent four years focused on advanced malware research at ESET. Matrosov is co-author of numerous research papers including Stuxnet Under the Microscope, and is frequently invited to speak at major security conferences such as REcon, ZeroNights, Black Hat and Virus Bulletin.

Eugene Rodionov, PhD, graduated with honors from the Information Security faculty of the Moscow Engineer-Physics Institute. He currently works at ESET, where he is involved with internal research projects and performs in-depth analysis of complex threats. His interests include kernel-mode programming, anti-rootkit technologies and reverse engineering. Rodionov has spoken at security conferences such as REcon, Virus Bulletin, ZeroNights, CARO and AVAR, and has co-authored numerous research papers.

Sergey Bratus is a Research Associate Professor in the Computer Science Department at Dartmouth College. He has previously worked at BBN Technologies on Natural Language Processing research. Bratus is interested in all aspects of Unix security, in particular in Linux kernel security, and detection and reverse engineering of Linux malware.

Table of Contents
Introduction
Part 1: ROOTKITS
Chapter 1: What’s in a Rootkit: The TDL3 Case Study (NOW AVAILABLE)
Chapter 2: Festi Rootkit: The Most Advanced Spam Bot
Chapter 3: Observing Rootkit Infections
Chapter 4: Rootkit Static Analysis: IDA Pro
Chapter 5: Rootkit Dynamic Analysis: WinDbg
Part 2: BOOTKITS
Chapter 6: Bootkit Background and History (NOW AVAILABLE)
Chapter 7: The Windows Boot Process: Bringing Up a System in a Trustworthy State (NOW AVAILABLE)
Chapter 8: From Rootkits (TDL3) to Bootkits (TDL4): Bypassing Microsoft Kernel-Mode Code Signing Policy (NOW AVAILABLE)
Chapter 9: Operating System Boot Process Essentials (NOW AVAILABLE)
Chapter 10: Static Analysis of a Bootkit Using IDA Pro (NOW AVAILABLE)
Chapter 11: Bootkit Dynamic Analysis: Emulators and Virtual Machines
Chapter 12: Evolving from MBR to VBR Bootkits: Mebromi & Olmasco
Chapter 13: VBR Bootkits: Rovnix & Carberp
Chapter 14: Gapz: Advanced VBR Infection
Chapter 15: UEFI Boot vs. MBR/VBR
Chapter 16: Contemporary UEFI Bootkits
Part 3: DEFENSE AND FORENSIC TECHNIQUES
Chapter 17: How Secure Boot Works
Chapter 18: HiddenFsReader: Bootkits Forensic Approaches
Chapter 19: CHIPsec: BIOS/UEFI Forensics
Part 4: ADVANCED REVERSE ENGINEERING
Chapter 20: Breaking Malware Cryptography
Chapter 21: Modern C++ Malware Reversing
Chapter 22: HexRaysCodeXplorer: Practical C++ Code Reconstruction

https://www.nostarch.com/rootkits

DMTF Redfish 1.0 released

Redfish, an IPMI replacement, has shipped the first release of their spec. Quoting the press release:

DMTF Helps Enable Multi-Vendor Data Center Management with New Redfish 1.0 Standard

DMTF has announced the release of  Redfish 1.0, a standard for data center and systems management that delivers improved performance, functionality, scalability and security. Designed to meet the expectations of end users for simple and interoperable management of modern scalable platform hardware, Redfish takes advantage of widely-used technologies to speed implementation and help system administrators be more effective. Redfish is developed by the DMTF’s Scalable Platforms Management Forum (SPMF), which is led by Broadcom, Dell, Emerson, HP, Intel, Lenovo, Microsoft, Supermicro and VMware with additional support from AMI, Oracle, Fujitsu, Huawei, Mellanox and Seagate. The release of the Redfish 1.0 standard by the DMTF demonstrates the broad industry support of the full organization.

http://dmtf.org/standards/redfish
http://dmtf.org/join/spmf

Don’t forget to grab the Redfish “Mockup” as well as the specs and schema.

UEFI 2.5 has a JSON API to enable accessing Redfish. HP was first vendor with systems that supported UEFI 2.5’s new HTTP Boot, a PXE replacement.  Intel checked in HTTP Boot support into TianoCore, so it’s just a matter of time until other vendors have similar products. JSON-based Redfish and HTTP-based booting makes UEFI much more of a “web app”, w/r/t security research, and the need for system administrators to more closely examine how firmware is updated on their systems, to best protect them.
https://firmwaresecurity.com/tag/uefi-http-boot/

quiz: define ‘firmworm’

The pre-conference preview videos are coming out… 🙂 One firmware one that caught my attention:

Thunderstrike 2 “firmworm” for MacBooks Preview Video

https://twitter.com/qrs/status/628346592668598272

Microsoft Windows HSTI (Hardware Security Test Interface)

I just noticed that Microsoft has a “Hardware Security Testability Specification”, still at version 1.0, which defines the Microsoft Windows “Hardware Security Test Interface” (HSTI). The Windows Hardware Certification Program is a self-testing and certification process for Windows OEMs and IHVs. The OEMs/IHVs run some tests, pass them, upload the test log output showing the passing, the vendor gets their code signed and/or they won’t get their marketing logo. Though the test name and the group  name have changed, these tests have been around since the beginning of Windows NT. The tests have grown over time to cover more system components, and certification and logo requirements have gotten more tied to passing test results. As these tests are only useful for Windows-centric IHVs and OEMs, I’ve not paid much attention to what firmware tests are available. These days, there are tests for chip vendors and for IBVs (Independent BIOS Vendors), in addition to OEMs and IHVs. It looks like they have a few UEFI-centric tests regarding Secure Boot, and dealing with system suspend/resume.

Jeremiah Cox of Microsoft gave a talk at the Summer 2013 UEFI Forum plugfest (Summerfest): “Validating Hardware Security Through Firmware Interfaces“, see below for URL to slides.

Excerpts from the MSDN web page:

HSTI helps avoid misconfiguration of security features on devices running Windows. Thus, HSTI provides better assurance of compliance with Windows Hardware Security Requirements. HSTI aims to simplify the interface for designing tests to ensure compliance, reducing the effort required to comply with Windows Hardware Security Requirements. The results of HSTI tests will be consumed by Windows Certification Tests and can be used to verify that devices have been properly configured to enable supported security features. These tests may be used to identify unsecure engineering devices in the field; for example, engineering devices which may contain unsecure test keys. The results of these tests may be used by the Windows operating system to display a watermark (or similar indicator) on unsecured devices. The IHV will develop reference security designs for their platforms that comply with the Windows Compatibility Requirements. In addition, IHVs and IBVs will also implement programmatic tests that verify proper enablement of the reference security implementations and report the results via the Hardware Security Test Interface. These tests are delivered to OEMs & ODMs as compiled modules (not source) and should work without modification. If an OEM/ODM deviates from reference security designs, these test modules may report failures, and the OEM/ODM will need to contact Microsoft to review the modifications and implement an additional HSTI instance that reports these exceptions. OEMs should be able to leverage these security modules with no modification required by following the reference design and documentation. OEMs who wish to add additional security modules, or modify the behavior of any security module, must undergo a design review with Microsoft. Silicon suppliers and IBVs who support Connected Standby systems must implement the platform independent interfaces for querying the respective hardware and firmware security states of their reference platforms. These implementations must be delivered as compiled modules. It is recommended that these modules be signed, and that a signature check is performed when they are run. The purpose is to query the hardware and firmware designs and states to report proper security provisioning of the platform. If an OEM wants to provide an alternate implementation of HSTI tested security features the OEM may provide additional tests. OEM security checks must at least fully cover one IHV or IBV security test. Before use, OEMs must submit to a design review by Microsoft and are subject to the same Documentation and Tool disclosure requirements as other HSTI test providers. Upon approval from Microsoft, the OEM may include security tests that extend upon the IHV and IBV tests. Note that OEM attestation is not required as part of the HSTI design. HSTI is not a list of requirements for OEMs; it is an interface to guarantee effective programmatic security testing of firmware, hardware, and configuration parameters. Silicon and firmware suppliers should make available to Microsoft all necessary security-related reference documentation and tools that they provide to OEMs. This documentation and tools should be made available no later than they are provided to Windows OEMs. This should include, but is not limited to, all documentation and tools related to fusing, installing and updating firmware, firmware and boot recovery, hardware diagnostics, firmware diagnostics, & boot diagnostics. This documentation and tools provided should be fully sufficient to perform HSTI checks in a lab environment.

Beyond Canonical’s FirmWare Test Suite (FWTS) tool for Ubuntu systems, I wonder if Linux Foundation (and FreeBSD Foundation) have anything close to this testing and certification policy for (not just a test), to help encourage silicon vendors, IBVs, IHVs, and OEMs to best (and most securely) work with Linux (and FreeBSD). In addition to passing FWTS, Intel-based systems should also have to pass current CHIPSEC release before Linux or FreeBSD should touch the platform.

This also reminds me of my last blog post, about getting CHIPSEC results more widely available for consumer’s pre-sales knowledge, depending on the strength of these Windows tests, Microsoft may have some OEM/IBV test results that I wish they’d share (but they never would share that kind of data about their Partner, of course).

For the good of all OSes, not just Windows, I wish Microsoft would add CHIPSEC to their test suites, to force OEMs to pass CHIPSEC. I wonder if CHIPSEC works using IronPython when run as an OS-level app on Windows. 🙂

More Information:

Click to access UEFI_Summerfest_2013_-_Microsoft_Hardware_Security_Test_Interface.pdf

http://www.uefi.org/learning_center/presentationsandvideos
https://msdn.microsoft.com/en-us/library/windows/hardware/dn879006.aspx

book mini-review: combat: UEFI Principles and Programming (in Chinese)

Ok, I’m writing a book review about a book I didn’t read. 😦 The book is written in Chinese, and I’m not good enough at translation software yet to read the book. But for anyone who can read Chinese, if you don’t already know about this book, you should check it out.

According to Amazon.com. the author is Director of Intel Labs China, and the book has a developer focus. The github site includes a snapshot of the EDK2, with a few examples. Even if you can’t read Chinese, you can still benefit from reading the samples. The  book was published January 1st 2015, and Gthub appears to have last been updated in May. From the Amazon.com abstract:

combat: UEFI Principles and Programming is the first UEFI monograph in Chinese, which is written by senior UEFI expert and evangelist. Director of Intel Labs China, Wu Gansha, strongly recommended! This book is combat-oriented for UEFI users and developers. It describes the UEFI system components, boot process, advantages, and a variety of systems development environment to build; Then it analyzes the UEFI components from deverloper’s view, including UEFI modules, a variety of protocols. basic services, events, hard drives and file systems; Finally it explaines UEFI development , involving the development of UEFI services(video decoder service though ffmpeg), UEFI-driver development(AC97 audio driver), the development of multi-tasking applications, the development of network applications and GUI application development.”

https://github.com/zhenghuadai/uefi-programming
https://github.com/zhenghuadai/uefi-programming/blob/master/README.md

book review: Platform Embedded Security Technology Revealed

Book review:
Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine
Xiaoyu Ruan (Intel)
APress Open, 2014
ISBN: 978-1-4302-6571-9 and 978-1-4302-6572-6
http://www.apress.com/9781430265719

The book reveals the technical details of Intel’s security and management engine, with the focus on the architecture and design of its firmware infrastructure. For the past several years, the engine has been serving as the base of many security technologies included in Intel platforms. This book talks about the various Intel boot security technologies, focusing on the Intel Management Engine (ME) and how ME interacts with the other Intel security technologies at the hardware, firmware, and OS-levels. Much of the book focuses on boot integrity, process isolation, and various Intel hardware-based protections. The book gives good background on how a chip vendor deals with hardware/firmware hybrid solutions, as well as how recent security researcher’s attacks against Intel have impacted their product designs.

It is from APress Open, not Intel Press. But it does read like an book-length whitepaper by Intel, explaining most of Intel’s hardware/firmware security offerings, with some crypto background on some of the designs. The author, Xiaoyu Ruan, is a security researcher with the Platform Engineering Group at Intel Corporation, and is responsible for designing cryptography infrastructure and security applications for Intel’s security and management engine.

The Management Engine (ME) is sometimes just called a management engine, later is starts to become called the security engine:

“Depending on the end product in which the embedded engine resides, the engine is denominated differently. For the embedded system shipped with computing devices featuring Intel Core family microprocessors, it is called the management engine. For the embedded system shipped with computing devices featuring the Intel Atom system-on-chip (SoC), it is called the security engine. Note that not all Atom platforms use the security engine introduced in this book.”

The list of Intel security technologies and acronyms discussed in this book is extensive:
* Intel Security Security Engine, aka Management Engine (ME)
* Intel Boot Guard
* Intel Trusted Execution Technology (TXT)
* Intel Software Guard Extensions (SGX)
* Intel Identity Protection Technology (IPT)
* Intel Active Management Technology (AMT)
* TCG’s TPM
* Intel Virtualization Technology
* Intel Anti-Theft Technology
* Intel management engine BIOS extension (MEBX)
* Host-Embedded Controller Interface (HECI)
* Intel EPID (Enhanced Privacy Identification)
* Intel PAVP (Protected Audio And Video Path)
* Intel Platform Trust Technology (PTT)

The discussion on Boot Guard goes into detail as to how it works with Verified Boot and Measured Boot, including use of TPM on Measured Boot. There is a comparison of these various Intel HW/FW security technologies to ARM’s TrustZone. There is discussion on how some of these security technologies are used for “Rights Protection” (DRM), including Intel Sandy Bridge hardware protection technology for UltraViolet-based video content. The author talks about WS-Management interfaces, as well as pre-WSMAN SOAP-based External Operations Interface (EOI) interfaces to engine. There is discussion of the OS-level drivers used to communicate with ME, including Baseboard Management Controllers (BMC) and Out-of-bound traffic to systems via ME on servers. There is some clarification of ME -vs- AMT -vs- vPro, as well as ME use of TPM (discrete or software-based).

The engine has many features. It includes a secure timer, a protected real-time clock in the engine. It can be used for secure storage:

“A partition of the SPI flash chip is reserved for storing the security and management engine’s nonvolatile data. As the flash size is very limited, the files cannot be too large. Generally speaking, the storage is intended for keys and credentials, such as device private keys, AMT passwords, and so on. It is not designed for storing bulk data such as video frames or network traffic.”

Regarding debugging, production parts have fewer silicon diagnostic abilities, but the ME “offers two ways—debug messaging and special production-signed firmware—to facilitate debugging on production parts.”

The book helps enlighten you as to some of the reasons your firmware is generating network traffic, eg:

“To get the current date/time information, the EPID manager requests a real-time OCSP (Online Certificate Status Protocol) response from a trusted OCSP server, which was endorsed by Intel.”

“As an embedded system, the security and management engine does not have convenient network access. Therefore, the SIGMA protocol is designed such that the platform does not communicate with the OCSP server directly but only connects with the verifier.”

The engine adds new crypto protocols, new PKIs, for cryptographers to enjoy. I’m not sure what code outside the engine uses this yet.

Intel EPID (Enhanced Privacy Identification) was added to the management engine:

“Intel’s chipset series 5 (released in 2008) and newer natively support the EPID platform functionality. A unique private key, in its encrypted form, is burned into security fuses for every chipset part during manufacturing. For this EPID ecosystem, Intel acts as the EPID authority. Using the private key, the security and management engine proves that it is a genuine Intel platform, and hence eligible for premium services that are only available for Intel platforms.

Yet it sounds like there is hardware and knowledge available for attackers to obtain to sidestep some of this technology, and rubberhoses can trump NDAs:

“The implementation of the security and management engine attempts to ensure that the EPID key cannot be revealed from a device without special and expensive equipment and advanced expertise in hacking.”

The engine includes a Dynamic Application Launcher (DAL). One thing that jumped out to me about the ME is that it runs Java code from the hard drive! After spending a lot of time explaining why ME is isolated and secure from third-party code, the author mentions two ME limitations: not enough space on Flash for more ME-based firmware apps, and inability of third parties to use the ME.

“To address these drawbacks to some extent, newer versions of the security and management engine firmware include a module called the Dynamic Application Loader, or DAL for short. As indicated by the name, the DAL allows the engine to dynamically load and execute Java applets at runtime. The applets are not stored on the flash, but on the host’s hard drive. With the DAL, the embedded engine is no longer a closed-door realm. The engine is now open to more flexibility and possibilities to be explored.”

“The DAL is essentially a Java virtual machine that enables the operation of Java applets in the security and management engine’s firmware environment. The Java applets in bytecode implement their designed functionalities that can be executed in the firmware.”

“Depending on product, the IPT may be implemented as an applet for the engine’s DAL feature, or a native firmware module on the engine. If the firmware supports DAL, for example, on most Intel Ultrabook models, then the IPT implementation will be distributed in a Java applet. On certain smartphones and other products where the DAL is not built into the engine’s firmware, the IPT will be a native firmware ingredient that is loaded from the system’s flash chip. The firmware design and functionalities of the IPT component are identical for both variants.”

Interestingly, it sounds like the management engine uses some open source code, but doesn’t mention what code is used, only that the TLS used in AMT is not ported from OpenSSL:

“In the security and management engine’s firmware, only a small fraction originates from open-source domain, and it is only used in modules that do not assume security responsibilities. For example, the TLS implementation in the AMT firmware application is not ported from OpenSSL and hence not affected by OpenSSL’s vulnerabilities such as the Heartbleed. The validation of the engine does not discriminate between open source and closed source. Thorough testing is performed against open-source software used by the engine.

(Tianocore’s UEFI implementation of Secure Boot requires the use of libOpenSSL to implement the crypto. OEMs/IBVs could replace that with another library, and may be doing so, but there’s no docs to clarify this.)

In some ways, I look at Intel platforms a bit differently now. In the beginning, it was simple (and insecure): BIOS loaded MS-DOS, then you had a shell, and you ran an app, with the occasional service (TSR). These days, OSes are much more complex, BIOS was replaced by UEFI, which itself a new OS added to stack. The mangement engine and SMM are two background layers to the stack as well. Before reading this, I really thought of the non-UEFI, non-SMM, non-TPM, non-IPMI background interactions were infrequent. But the management engine looks like a significant new addition to the stack, running it’s own drivers, virtual TPMs, ISV Java code off the hard disk, it sounds like yet-another OS (er, platform) added to the stack. It makes sense if you are Intel, I suppose. But I feel uneasy about how complex HW/FW is becoming… Some of these technologies are going to get in the way of General Purpose Computing, helping some companies make disposable systems where vendors dictate all FW/OS choices, and you cannot install your own OS. On the other hand, security issues need addressing, somehow. Boot system, start SMM, start background ME OS, then start background UEFI OS, then load user’s main OS, …that’s a lot of platforms in one stack.

In summary, I liked this book. Unlike my blog posts, the book was well-written. 🙂 The author knows a LOT about Intel security technologies. I learned a lot. If you care about firmware security on Intel platforms, you should get this book. You might be able to avoid the book if you spend a lot of time researching the various technologies off Intel’s web sites and online, but this book does a great job of integrating all of these technologies into one source. I hope to see a 2nd edition once Intel adds more features to the engine.