Intel SGX elevation of privilege update

Intel SGX security update for Intel Servers/NUC/ComputeStick. Excerpt of announcement:

Intel ID: INTEL-SA-00076
Product family: Intel Server Systems, NUC, and Compute Stick
Impact of vulnerability: Elevation of Privilege
Severity rating: Critical
Original release: Jul 25, 2017

Intel has released updates that improve the security of Intel® Software Guard Extensions (SGX). The improvement applies to 6th and 7th Generation Intel® Core™ Processor Families, Intel® Xeon® E3-1500M v5 and v6 Processor Families, and Intel® Xeon® E3-1200 v5 and v6 Product Families. This update improves the security of Intel® Software Guard Extensions (SGX) and is strongly recommended. While this firmware update prevents exploitation of the issue on systems running SGX, Intel also provides an SGX Attestation service to allow service providers to know whether clients have the latest security updates. Intel plans to update the SGX Attestation Service response on November 14, 2017. On platforms that have not installed the update, SGX applications using the SGX Attestation Service will begin to receive “out of date” responses from the SGX Attestation Service. Applications using SGX may or may not take action based on this information. If SGX Attestation is used, it may be necessary for applications using SGX to re-provision the platform with an updated SGX platform attestation key after this update is installed. This updated attestation key allows the platform to demonstrate that it is up to date.

Full announcement:

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

Apple on Secure Kernel Extension Loading

https://twitter.com/macOS_adm/status/889901131316559872

https://twitter.com/Contains_ENG/status/889878399195459589

On June 19th, Apple released a document describing how loading secure kernel extensions (.kext) would change with High Sierra and how this would impact enterprise customers.[…]

System Extension Blocked

http://blog.eriknicolasgomez.com/2017/07/25/Kextpocalypse-High-Sierra-and-kexts-in-the-Enterprise/

https://developer.apple.com/library/content/technotes/tn2459/_index.html

 

Trust Issues: Exploiting TrustZone TEEs

by Gal Beniamini, Project Zero

Mobile devices are becoming an increasingly privacy-sensitive platform. Nowadays, devices process a wide range of personal and private information of a sensitive nature, such as biometric identifiers, payment data and cryptographic keys. Additionally, modern content protection schemes demand a high degree of confidentiality, requiring stricter guarantees than those offered by the “regular” operating system. In response to these use-cases and more, mobile device manufacturers have opted for the creation of a “Trusted Execution Environment” (TEE), which can be used to safeguard the information processed within it. In the Android ecosystem, two major TEE implementations exist – Qualcomm’s QSEE and Trustonic’s Kinibi (formerly <t-base). Both of these implementations rely on ARM TrustZone security extensions in order to facilitate a small “secure” operating system, within which “Trusted Applications” (TAs) may be executed. In this blog post we’ll explore the security properties of the two major TEEs present on Android devices. We’ll see how, despite their highly sensitive vantage point, these operating systems currently lag behind modern operating systems in terms of security mitigations and practices. Additionally, we’ll discover and exploit a major design issue which affects the security of most devices utilising both platforms. Lastly, we’ll see why the integrity of TEEs is crucial to the overall security of the device, making a case for the need to increase their defences. […]

 

https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html

Hagfish: UEFI Bootloader for Barrelfish

Barrelfish is a new research operating system being built from scratch and released by ETH Zurich in Switzerland, originally in collaboration with Microsoft Research and now partly supported by HP Enterprise Labs, Huawei, Cisco, Oracle, and VMware. […]

Hagfish is the Barrelfish/ARMv8 UEFI loader prototype: Hagfish (it’s a basal chordate i.e. something like the ancestor of all fishes). Hagfish is a second-stage bootloader for Barrelfish on UEFI platforms, most importantly the ARMv8 server platform. […]

http://www.barrelfish.org/

https://github.com/BarrelfishOS/hagfish

https://github.com/BarrelfishOS/uefi-sdk

Google NERF: Non-Extensible Reduced Firmware

 

Open Source Summit North America 2017
September 11-14, 2017 – Los Angeles, CA
Replace Your Exploit-Ridden Firmware with Linux – Ronald Minnich, Google

With the WikiLeaks release of the vault7 material, the security of the UEFI (Unified Extensible Firmware Interface) firmware used in most PCs and laptops is once again a concern. UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel, that runs when the system is powered on and continues to run after it boots the OS (hence its designation as a “Ring -2 hypervisor”). It is a great place to hide exploits since it never stops running, and these exploits are undetectable by kernels and programs. Our answer to this is NERF (Non-Extensible Reduced Firmware), an open source software system developed at Google to replace almost all of UEFI firmware with a tiny Linux kernel and initramfs. The initramfs file system contains an init and command line utilities from the u-root project (http://u-root.tk/), which are written in the Go language.

https://ossna2017.sched.com/event/BCsr/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google?iframe=no&w=100%&sidebar=yes&bg=no

https://www.linkedin.com/pulse/open-hardware-servers-step-forward-jean-marie-verdun

Click to access Denver_2017_coreboot_u-root.pdf

U-Root: firmware solution written in Go

https://linuxfr.org/news/un-pas-en-avant-pour-les-serveurs-libres-le-projet-nerf

Baidu releases SGX SDK for Rust

Rust SGX SDK, v0.2.0 Release

This Rust SGX SDK helps developers write Intel SGX enclaves in Rust programming language. We are proud to have our v0.2.0 Rust SGX SDK released. It is now providing more threading functions, thread local storages, exception handling routines and supports unwind mechanism, as well as support of LARGE ENCLAVE MEMORY with the help of Intel SGX v1.9 (31.75 GB enclave memory tested). Please refer to release notes for further details. And we are working on a white paper for technical details about this project.[…]

https://github.com/baidu/rust-sgx-sdk/releases/tag/v0.2.0

Porting UEFI to Apple PowerPC…

Porting UEFI to a new architecture:
So it turns out that blogging about something after the fact is pretty tough. I really wanted to blog about my PoC port of UEFI to the OpenPower ecosystem, but it’s incredibly difficult to go back and try to systematize something that’s been a few years back. So let’s try this again. This time, our victim will be a G4 12″ PowerBook6,8 with a 7447A. That’s a 32-bit PowerPC. Now, I’ll go in small steps and document everything. For added fun, we’ll begin porting on the target itself, at least until that gets too tedious. Also, I’ve a few OldWorld machines, a spare G4 12″ for parts and a G5, so hopefully this odyssey won’t be interrupted by old and failing hardware ;-). Keep in mind that each part is checked in along with the source code, so look at the entire commit. Each blog post will focus on the most important details.[…]

http://osdevnotes.blogspot.com/2017/07/porting-uefi-to-xxx-step-1.html
https://github.com/andreiw/ppcnw-edk2
https://github.com/andreiw/ppcnw-edk2/blob/master/PortingHowTo_p1.md

See-also:

Interview with Andrei Warkentin, OpenPOWER UEFI porter

Tianocore for OpenPOWER

 

CVE-2017-11472: Linux kernel ACPI KASLR vulnerability

The acpi_ns_terminate() function in drivers/acpi/acpica/nsutils.c in the Linux kernel before 4.12 does not flush the operand cache and causes a kernel stack dump, which allows local users to obtain sensitive information from kernel memory and bypass the KASLR protection mechanism (in the kernel through 4.9) via a crafted ACPI table.

[…]This causes a security threat because the old kernel (<= 4.9) shows memory locations of kernel functions in stack dump, therefore kernel ASLR can be neutralized. To fix ACPI operand leak for enhancing security, I made a patch which removes the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the deletion code unconditionally.[…]

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11472
https://nvd.nist.gov/vuln/detail/CVE-2017-11472
https://vuldb.com/?id.104315
https://github.com/acpica/acpica/commit/a23325b2e583556eae88ed3f764e457786bf4df6
https://github.com/torvalds/linux/commit/3b2d69114fefa474fca542e51119036dceb4aa6f

 

APT monitoring & analysis …below Ring 0

Applying Provenance in APT Monitoring and Analysis Practical Challenges for Scalable, Efficient and Trustworthy Distributed Provenance
Jenkinson G, Carata L, Bytheway T, Sohan R, Watson RNM, Anderson J, Kidney B, Strnad A, Thomas A, Neville-Neil G

[…] Below Ring 0 – hardware primitives can potentially support provenance capture in a number of ways. Trusted Computing primitives such as Intel SGX (Software Guard Extensions) can be used provide stronger non-repudiation (even in the presence of a compromised OS). And new hardware primitives could directly support provenance capture, for example providing an append only log for use by the kernel to store provenance records prior to sending over a network.[…]

https://www.usenix.org/conference/tapp17/workshop-program/presentation/jenkinson

Click to access tapp17_paper_jenkinson.pdf

https://www.researchgate.net/publication/317827922_Applying_Provenance_in_APT_Monitoring_and_Analysis_Practical_Challenges_for_Scalable_Efficient_and_Trustworthy_Distributed_Provenance

UEFI:NTFS

UEFI:NTFS is a generic bootloader, that is designed to allow boot from an NTFS partition, in pure UEFI mode, even if your system does not natively support it. This is primarily intended for use with Rufus, but can also be used independently. In other words, UEFI:NTFS is designed to remove the restriction, which most UEFI systems have, of only providing boot support from a FAT32 partition, and enable the ability to also boot from NTFS partitions. This can be used, for instance, to UEFI-boot a Windows NTFS installation media, containing an install.wim that is larger than 4 GB (something FAT32 cannot support) or to allow dual BIOS + UEFI boot of ‘Windows To Go’ drives. […] Secure Boot must be disabled for UEFI:NTFS to work.[…]

https://github.com/eventus77/uefi-ntfs-boot

http://efi.akeo.ie/
https://rufus.akeo.ie/

 

coreboot security slides from REcon available

Digging Into the Core of Boot by Yuriy Bulygin, Oleksandr Bazhaniuk

Click to access RECON-MTL-2017-DiggingIntoTheCoreOfBoot.pdf

https://recon.cx/2017/montreal/slides/

See-also the SGX talk…

KLEE 1.4.0 released

Cristian Cadar announced the 1.4.0 release of KLEE.

KLEE 1.4.0 is now available at
https://github.com/klee/klee/releases/tag/v1.4.0

Lots of new changes, in particular a new CMake build system, support for  some missing features for LLVM 3.4 (and partial support for 3.5 and  3.6), better support for MacOS, support for release documentation (as in  http://klee.github.io/releases/docs/v1.4.0/) and many other  optimizations, features and bug fixes.[…]

Full announcement:
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
https://klee.github.io/

https://github.com/klee/klee

 

Shut the HAL Up: Isolating Android HALs

Shut the HAL Up
18 July 2017
Jeff Vander Stoep, Senior Software Engineer, Android Security

Updates are essential for security, but they can be difficult and expensive for device manufacturers. Project Treble is making updates easier by separating the underlying vendor implementation from the core Android framework. This modularization allows platform and vendor-provided components to be updated independently of each other. While easier and faster updates are awesome, Treble’s increased modularity is also designed to improve security. A Hardware Abstraction Layer (HAL) provides an interface between device-agnostic code and device-specific hardware implementations. HALs are commonly packaged as shared libraries loaded directly into the process that requires hardware interaction. Security boundaries are enforced at the process level. Therefore, loading the HAL into a process means that the HAL is running in the same security context as the process it’s loaded into.[…]

https://android-developers.googleblog.com/2017/07/shut-hal-up.html

TI on embedded SoC security

Where to Start with Embedded Processor Security
July 17th, 2017
By Amrit Mundra, Texas Instruments
The world runs on data, and every bit or byte is a potential target for attack. At the same time, both software and hardware systems are becoming much more complex, connected, and interdependent. And with complexity comes vulnerabilities. The billions or trillions of lines of code and interrelated hardware modules, subsystems, and partitions—all crammed on tiny slices of silicon—are a hacker’s delight.[…]

Figure 1: Security pyramid

 

 

http://eecatalog.com/chipdesign/2017/07/17/where-to-start-with-embedded-processor-security/

Quarkslab’s vulnerabilitries in NXP i.MX secure boot

 

Vulnerabilities in High Assurance Boot of NXP i.MX microprocessors
By Guillaume Delugré Iván Arce

This blog post provides details about two vulnerabilities found by Quarkslab’s researchers Guillaume Delugré and Kévin Szkudłapski in the secure boot feature of the i.MX family of application processors [1] built by NXP Semiconductors. The bugs allow an attacker to subvert the secure boot process to bypass code signature verification and load and execute arbitrary code on i.MX application processors that have the High Assurance Boot feature enabled. These bugs affect 12 i.MX processor families. The vulnerabilities were discovered and reported to the vendor in September 2016 and the technical details included in this blogpost were disclosed in a joint Quarkslab-NXP presentation at the Qualcomm Mobile Security Summit 2017 [2] in May 19th, 2017. National computer emergency response teams (CERTs) from 4 countries were informed about the issues in March, 2017. NXP has issued an Engineering Bulletin and two Errata documents (EB00854, ERR010872 and ERR0108873 respectively) [3] providing a brief description of both vulnerabilities, the list of affected processor models along with resolution plans and possible mitigations. In the rest of the blogpost we describe the relevant features in i.MX processors and the vulnerabilities affecting them.[…]InversePath, vendor of USB Armory [6], an affected device confirmed the vulnerabilities and developed proof of concept programs to demonstrate them.[…]

https://blog.quarkslab.com/vulnerabilities-in-high-assurance-boot-of-nxp-imx-microprocessors.html

https://labsblog.f-secure.com/2017/07/19/break-your-own-product-and-break-it-hard/

https://github.com/inversepath/usbarmory/blob/master/software/secure_boot/Security_Advisory-Ref_QBVR2017-0001.txt

Inception: hacking tool exploiting PCI-based DMA

Inception has been around since at least 2014, but I just noticed it. 😦

Inception is a physical memory manipulation and hacking tool exploiting PCI-based DMA. The tool can attack over FireWire, Thunderbolt, ExpressCard, PC Card and any other PCI/PCIe interfaces. Inception aims to provide a relatively quick, stable and easy way of performing intrusive and non-intrusive memory hacks against live computers using DMA. Inception’s modules work as follows: By presenting a Serial Bus Protocol 2 (SBP-2) unit directory to the victim machine over a IEEE1394 FireWire interface, the victim operating system thinks that a SBP-2 device has connected to the FireWire port. Since SBP-2 devices utilize Direct Memory Access (DMA) for fast, large bulk data transfers (e.g., FireWire hard drives and digital camcorders), the victim lowers its shields and enables DMA for the device. The tool now has full read/write access to the lower 4GB of RAM on the victim. Once DMA is granted, the tool proceeds to search through available memory pages for signatures at certain offsets in the operating system’s code. Once found, the tool manipulates this code. For instance, in the unlock module, the tool short circuits the operating system’s password authentication module that is triggered if an incorrect password is entered. […] However, vendors generally dismiss DMA attacks as a non-issue, which I hope that the awareness that this tool generates will change. Users deserve secure devices, even when attackers gain physical access.[…]

https://github.com/carmaa/inception
http://www.breaknenter.org/projects/inception/
http://www.breaknenter.org/2014/09/inception-metasploit-integration/