Intel SGX: EPID Provisioning and Attestation Services

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

Intel has a new document available on SGX, discussing EPID Provisioning and Attestation Services:

Intel SGX: EPID Provisioning and Attestation Services

One of the critical features of Intel SGX is the ability to attest that an enclave was successfully established on an SGX enabled platform. Our Attestation and Sealing Whitepaper from 2013 on the subject gives a high level overview of the attestation process, however it did not cover how the attestation key was delivered to the platform. In order to explain this process and the services that Intel has developed to support EPID provisioning, and the subsequent verification of EPID attestations, for SGX we have written a companion whitepaper. EPID provisioning takes place through enclaves that are provided as part of the SGX SDK and distributed along with SGX applications. The attestation service is available to all SGX developers. For developers that have built their enclaves and are ready to access the Intel Attestation Verification Service referenced in the paper, please contact intel.developer.services@intel.com for additional information.

Click to access 2016%20WW10%20sgx%20provisioning%20and%20attesatation%20final.pdf

https://software.intel.com/en-us/blogs/2016/03/09/intel-sgx-epid-provisioning-and-attestation-services

SimpleVisor: new hypervisor for Intel x64 Windows

https://twitter.com/aionescu/status/710477975288827904

Alex Ionescu has released a new hypervisor for Windows:

SimpleVisor is a simple, Intel x64 Windows-specific hypervisor with two specific goals: using the least amount of assembly code (10 lines), and having the smallest amount of VMX-related code to support dynamic hyperjacking and unhyperjacking (that is, virtualizing the host state from within the host).

http://ionescu007.github.io/SimpleVisor/

Keystone Project announced

Nguyen Anh Quynh announced the Keystone Engine Project, with an IndieGogo funding campaign to help them:

We are very excited to announce our IndieGogo campaign for Keystone Engine, the next-gen assembler framework! After Capstone & Unicorn, Keystone is the latest of our on-going effort to bring better tools to the reverse-engineering community. Now with the final missing piece Keystone, we complete the magical trilogy of disassembler – emulator – assembler. Come support us, and help to spread the news, so together we can solve the lingering problem of missing the assembler framework once, and for all! The Keystone name came from some private conversation with Felix “FX” Lindner. Thanks for such a great inspiration, FX!

http://www.capstone-engine.org
http://www.unicorn-engine.org
http://www.keystone-engine.org
https://igg.me/at/keystone

U-Boot: EFI patches applied, and new bootefi command

Alexander Graf of SuSE has been adding EFI support to U-Boot.  He also just added a new boot loader command, ‘bootefi’, as well:

[PATCH v6 19/30] efi_loader: Add “bootefi” command

In order to execute an EFI application, we need to bridge the gap between U-Boot’s notion of executing images and EFI’s notion of doing the same. The best path forward IMHO here is to stick completely to the way U-Boot deals with payloads. You manually load them using whatever method to RAM and then have a simple boot command to execute them. So in our case, you would do

  # load mmc 0:1 $loadaddr grub.efi
  # bootefi $loadaddr

which then gets you into a grub shell. Fdt information known to U-boot via the fdt addr command is also passed to the EFI payload.

Tom Rini of the U-Boot project also just posted a message saying that the EFI patches have been mostly applied:

EFI loader support largely enabled

What I mean by the subject is that with the EFI loader patches enabled U-Boot itself (not SPL) now includes the EFI loader and required bits on ARM/aarch64.  This is in general I think a good thing.  I’ve however disabled it on a few boards due to size constraints.  This is an average gain of ~12KiB in U-Boot proper.  I fully expect a number of platform patches opting out of this support due to it just not being a real usecase and I am agreeable to talking about making it not enabled by default.  So, lets kick things off.

For more information, see the U-Boot sources or mailing list archives:

http://lists.denx.de/mailman/listinfo/u-boot

FlashROM 0.9.9 released

After a year since the last release, FlashROM 0.9.9 has been released. Excerpt from announcement follows:

New major user-visible features:
 * Allow to link flashrom statically (with make CONFIG_STATIC=yes)
 * Ease debugging of build problems with libraries
    – Output way more debug information to build_details.txt
    –  Provide list of set make configuration variables that make builds fail
    –  Allow to easily disable groups of programmers depending on a library (make CONFIG_ENABLE_LIBUSB0_PROGRAMMERS=no CONFIG_ENABLE_LIBUSB1_PROGRAMMERS=no CONFIG_ENABLE_LIBPCI_PROGRAMMERS=no)
 * Ignore 0x00 as a flash chip manufacturer ID in the generic match to avoid ambiguous messages
 * Various improvements for serprog-based programmers
 * Support arbitrary UART baud rates on Windows

New chips:
 * ESI ES25P40, ES25P80 and ES25P16
 * GigaDevice GD25VQ41B and GD25Q128C
 * More GigaDevice GD25LQ chips (GD25LQ40, GD25LQ80, GD25LQ16, GD25LQ64(B), GD25LQ128)
 * PMC Pm25LQ020, Pm25LQ040, Pm25LQ080, Pm25LQ016, Pm25LQ032C
 * Sanyo LE25FU406C/LE25U40CMC
 * SST SST25WF020A, SST25WF040B, SST25WF080B
 * Winbond W29C512A/W29EE512

Infrastructural improvements and fixes:
 * Add support for libftdi1 (previous libftdi support still in place for backward compatibility but will eventually be removed)
 * Add infrastructure for libusb1 and use it for new programmers (existing code will be migrated from libusb0 continuously in the future)
 * Many cross-platform and cross-architecture improvements:
   – Fix compilation on OSX and Solaris-based systems
   – Add support for musl libc
   – Use nanosleep() instead of usleep() where available (enables building with uclibc)
   – Support compilation on Android (bionic libc)
 * Rigorously check integrity of I/O stream data (e.g. to notice full filesystems when writing flash data to a file)

Full announcement:
https://www.flashrom.org/Flashrom/0.9.9

ELC-EU’15 videos online

The videos for Embedded Linux Conference Europe 2015 are online. There are many interesting firmware and hardware-related presentations at this event.

For example, Simon’s talk on U-Boot driver models:

Order at Last: The New U-Boot Driver Model Architecture – Simon Glass

Intel SSD Data Center for SATA exploitable via SATA abuse

Excerpting Intel Security advisory:

Potential vulnerability in Intel® SSD Data Center Family for SATA
Intel ID: INTEL-SA-00050
Product family: Intel® SSD Data Center Family for SATA
Impact of vulnerability: Denial of Service
Severity rating: Important
Original release: Mar 15, 2016

If the Intel SSD Data Center Family for SATA product receives certain commands that violate the SATA protocol, the drive may stop responding to host commands and, in that event, user data will be inaccessible. The Intel SSD Data Center Family for SATA product series was designed to the ATA-ACS specification. If the Intel SSD Data Center Family for SATA product receives certain commands that violate the SATA protocol, the drive may stop responding to host commands and, in that event, user data will be inaccessible. There is no risk of data corruption as a result of this issue. Platforms with a host implementation that complies with the SATA protocol are not at risk for this issue. Intel recommends that customers with affected product should download and apply the mitigated firmware version using the Intel® Solid State Drive Data Center Tool, which is available from the Intel Download Center (https://downloadcenter.intel.com).

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00050&languageid=en-fr
https://downloadcenter.intel.com/download/23931/Intel-Solid-State-Drive-Data-Center-Tool

Clang static analysis of firmware sources

Last month Alexander Tarasikov wrote a blog post on Clang static analyzers and firmware, ranging from UEFI to U-Boot and other technologies:

In this blog post I mainly want to summarize my latest experiments at using clang’s static analyzer and some thoughts on what could be further done at the analyzer, and open-source software quality in general. It’s mostly some notes I’ve decided to put up.
[…]
In one of my previous posts I have drawn attention to gathering code coverage in low-level software, such as bootloaders. With GCOV being quite easy to port, I think more projects should be exposed to it. Also, AddressSanitizer now comes with a custom infrastructure for gathering code coverage, which is more extensive than GCOV.
[…]

http://allsoftwaresucks.blogspot.ru/2016/02/noted-on-firmware-and-tools.html

Intel FSP 2.0 in the works?

As reported by Phoronix, it appears that Intel is working on the 2.0 release of their Firmware Support Package (FSP), the pre-compiled set of firmware binaries needed by most firmware solutions to work Intel systems.

http://www.phoronix.com/scan.php?page=news_item&px=Intel-FSP-2.0-Coreboot
http://anzwix.com/a/Coreboot/SocintelapollolakeEnableUsingFSP20Driver
https://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=b37fd67e8757e2eaf3ae7dd453e9aaa1518e9439
http://firmware.intel.com/learn/fsp/about-intel-fsp
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html

Firmware update presentation from OpenCompute Project

At the recent Open Compute Project (OCP) Summit there was a talk on firmware updates. The video is now online:

Nikolaj Schlej audits Intel Quark BSP

William Leara of Dell has a new blog post about Nikolaj Schlej’s new blog post analyzing Intel Quark’s BSP:

Another tip of the cap to Nikolaj Schlej, this time for an interesting article where he examined the Intel Quark Board Support Package (BSP) source code with the static source code analyzer PVS-Studio. The Intel Quark is an SoC used in embedded systems applications.  For example, it runs the Intel Galileo family of development boards.  Galileo is a small computer board comparable to the Arduino family of products, and is targeted to maker and educational customers. The BSP is a set of documentation and EDKII source code that allows a developer to build his own bootable firmware image for the Quark. Nikolaj discovered many serious problems, and I found it educational to read through them.  This is helpful so that you can discover the typical mistakes people make in UEFI development, and also so that you won’t make the same mistakes yourself! […]

http://www.basicinputoutput.com/2016/03/nikolaj-schlej-analyzing-intel-galileo.html
https://habrahabr.ru/post/258721/
http://www.viva64.com/en/b/0326/

UEFI 2.6 and ACPI 6.1 specs announced

The UEFI Forum has announced the availability of the UEFI v2.6 and ACPI v6.1 specifications.

ACPI v6.1 includes:
 * Interrupt-signaled events for expanded hardware-reduced platform support and improved system-on-chip designs.
 * Standardized ARMv8-A processor support for “firmware-first” hardware error handling and reporting, including SEA and SEI notification types in the Hardware Error Source Table (HEST).

UEFI v2.6 includes:
 * Enriched ability for agents in the system to provide better user interface support prior to launching of the OS through additional Image and Font information.
 * Formal API definition for RAM Disk Protocol.
 * New Wireless MAC Connection Protocol interface simplifies wireless network support and future radio technology versions.
 * ARM error reporting extensions for the Common Platform Error Record (CPER), allowing ARMv8-A systems to implement “firmware-first” hardware error handling and reporting.

More info:

ACPI 6.1 released

UEFI 2.6 spec changes

UEFI 2.6 released


http://uefi.org/specifications
http://www.businesswire.com/news/home/20160309005302/en/UEFI-Forum%C2%A0Announces-Availability-Updated-Specifications-UEFI-v2.6

Intel releases GLibC advisory

The Intel Software Center has announced a list of multiple products and services implacted by the recent GLibC bug:

Intel ID:      INTEL-SA-00049
CVE Name:  CVE-2015-7547

Intel Software Products and Services that rely on glibc may be indirectly impacted by CVE-2015-7547. Multiple stack-based buffer overflows in the (1) send_dg and (2) send_vc functions in the libresolv library in the GNU C Library (aka glibc or libc6) prior to version 2.23 allow remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted DNS response that triggers a call to the getaddrinfo. Intel Products and API services not included in this advisory are considered not to be impacted at this time. Intel Products and API services listed below are potentially impacted indirectly by this issue since those perform DNS lookups and are reliant on the Operating System. End-users should contact their Operating System vendor for a relevant glibc patch to help mitigate CVE-2015-7547. Intel recommends customers contact their Operating System vendor for a relevant glibc patch to help mitigate CVE-2015-7547. […]

https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
https://access.redhat.com/articles/2161461

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

DarkReading’s IoT Security Checklist

Dark Reading has a new article on IoT security, with a 9-part checklist for IoT entrepreneurs to read:

#1. Begin at the beginning to reduce attack points
#2. Authentication & authorization
#3. Encryption
#4. Privacy
#5. Consumer awareness
#6. Security testing: digital & physical
#7. Third-party testing
#8. Internet-enabled security software updates and vulnerability management
#9. Security analytics to detect intrusion

Full checklist:
http://www.darkreading.com/iot/iot-security-checklist-get-ahead-of-the-curve/a/d-id/1324513

FPMurphy’s UEFI Utilities has 2016 fork

Finnbarr P. Murphy has a set of UEFI Utilities on Github. He’s recently made two versions of it, UEFI-Utilities-2016:

Note that the code in this repository is quite old. Many of these utilitoes will only build against the GNU-EFI library and run under UEFI Shell v1.0. See my UEFI-Utilities-2016 repository for utilities that will build under UDK2015 and run under UEFI Shell v2.0.

Tools included:

DisplayBMP
ScreenModes
ShowBGRT
ShowECT
ShowEDID
ShowESRT
ShowMSDM
ShowTCM20
ShowTPM2
ShowTrEE
ShowTrEELog
tpm_getpermflags
tpm_getrandom

https://github.com/fpmurphy/UEFI-Utilities
https://github.com/fpmurphy/UEFI-Utilities-2016
http://blog.fpmurphy.com/

Samsung S6 Modem firmware reversing

Reverse Engineering Samsung S6 Modem
04 Mar 2016

So I was a little late to the game, and just got my hands on a Samsung Galaxy S6, specifically the SM-G920F which will be the topic of discussion in this post. I am quite curious as to understanding the structure of the device’s modem.bin file. While I haven’t been able to get a de-obfuscated/decrypted version of modem.bin yet, hopefully this post will help others quickly get up-to-speed and assist in the pursuit of one. Anyone interested in helping or contributing can hit me with the Tweets @theqlabs or submit a PR.

TL;DR – i do not have a decrypted modem.bin yet, but here are all my notes, send help. ❤

[…]
Full post:

http://arm.ninja/2016/03/04/reverse-engineering-samsung-s6-modem/

coreboot update

The coreboot project posted their regular project status update. In the last two week period, there have been: 105 commits by 25 authors, adding 13K and removing 3K lines of code. There were updates for multiple boards and chipsets, including Intel Galileo board and Quark chip, Intel Sandy Bridge/Ivy Bridge, Intel Skylake, Intel Bay Trail, Intel Apollo Lake, ARM ARM7 QEMU board, QEMU POWER8, and RISC-V. There were also updates to ARM Trusted Firmware and Verified Boot. Excerpting the announcement:

Payloads got some attention during this period, adding a way to include additional modules into the GRUB2 build. An option was added to build and include coreinfo as a ‘secondary’ payload, allowing it to be run from another payload. We also added U-Boot as a coreboot payload. This is currently still just in development, and needs additional work before it will act as a generic payload for all platforms.

We added LZ4 compression to the build with runtime decompression for cbfs. LZ4’s speed should be roughly the same as LZMA, trading a smaller compressed size for slightly slower decompressoin. LZ4’s main advantage is that it requires much less memory to do the decompression, allowing for compression of stages that couldn’t previously be compressed.

The suite of board-status scripts got several updates, fixing timestamp handling for the sanitized path names, handling when the script is run as super-user in a better way, and adding a script that will set up a Ubuntu Live-image to allow users to more easily run the board-status script.

In the build tools and utilities, we had some fixes for the toolchain builder, updating the GDB builds for x86_64 and MIPS. A couple of scripts were also added. One utility downloads and extracts binary blobs from Chrome OS recovery images, and the other new script allow easier testing of POST cards.

It is always hard to excerpt coreboot blog posts, they have a lot of good data which I’ve omitted. Full post:

coreboot changelog Feb 17 – March 1

Thinkpad password bypass hardware

Some friends of mine are gathering up some old IBM Thinkpads from a recycling center, to refurbish them with Libreboot. It reminds me how much fixing end-user problems are like attacking a system. One of the Thinkpads had multiple passwords that had to be bypassed, so it could be used.

There’s a password bypass solution for Thinkpads that involves custom hardware:

“Joe in Australia offers the only Affordable Fully Assembled, Programmed and Tested unlimited use USB based ThinkPad Supervisor Password [SVP] Recovery or Clear Tools in the world.  Joe’s KeyMaker X1 [KMX1] and X2 [KMX2] can Recover or Clear Supervisor Password from all current IBM and Lenovo ThinkPad models with the exception of the SL300 SL400 SL500 G550 T*40 X*40 X1 Carbon (Gen 2) it can do this even if TPM/TCPA/PC8394T/8356908 security has been enabled. SL300 SL400 SL500 G550 T*40 X*40 X1 Carbon (Gen 2) do NOT store Supervisor Password [SVP] in an EEPROM, that is the reason the SVP cannot be recovered in those models from an EEPROM by KMX1 or KMX2.”

http://www.ja.axxs.net/

https://support.lenovo.com/us/en/documents/ht036206

How to Reset an IBM ThinkPad BIOS Password