ChromeOS impact of Infineon TPM problem

More on: https://firmwaresecurity.com/2017/10/10/infineon-tpms-generating-weak-keys/

“You can check the TPM firmware running on your device by looking at the firmware_version line of the tpm_version entry in chrome://system. If the tpm_version entry is absent, this is likely because you are running an old Chrome OS version which doesn’t report this information. Upgrade to a newer version and check again.”

https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_firmware_update

 

more on Google NERF

Google NERF looks interesting, they keep UEFI’s PI but replace the UEFI layers with Linux kernel, and the code is written in Go. Looks like they’re focusing on removing dynamic code in UEFI and SMM. Unclear about their position towards dynamic code in ACPI, as well as PCIe (eg, PCIleech-style attacks).

The slides from the recent North American OSS presentation are online, but I can’t find the video online:

Click to access Linuxcon%202017%20NERF.pdf

There’s an upcoming European OSS event upcoming:

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://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google
https://ossna2017.sched.com/event/BCsr/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google
https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

http://u-root.tk/
https://github.com/u-root/u-root

https://firmwaresecurity.com/2017/07/23/google-nerf-non-extensible-reduced-firmware/

 

 

Google Titan trust paper available

A Vendor-Agnostic Root of Trust for Measurement
Jon McCune, Rick Altherr
We report the success of a project that Google performed as a proof-of-concept for increasing confidence in first-instruction integrity across a variety of server and peripheral environments. We begin by motivating the problem of first-instruction integrity and share the lessons learned from our proof-of-concept implementation. Our goal in sharing this information is to increase industry support and engagement for similar designs. Notable features include a vendor-agnostic capability to interpose on the SPI peripheral bus (from which bootstrap firmware is loaded upon power-on in a wide variety of devices today) without negatively impacting the efficacy of any existing vendor- or device-specific integrity mechanisms, thereby providing additional defense-in-depth.

https://research.google.com/pubs/pub46352.html

Click to access 46352.pdf

Yuriy of Eclypsium has a few comments on the doc, click on below tweet for thread:

 

Android 8.0 and Project Treble

https://www.linux.com/news/2017/9/android-oreo-adds-linux-kernel-requirements-and-new-hardening-features

https://source.android.com/devices/architecture/kernel/modular-kernels#core-kernel-requirements

“The Android 8.0 release includes Project Treble, a major re-architect of the Android OS framework designed to make it easier, faster, and less costly for manufacturers to update devices to a new version of Android. Treble is for all new devices launching with Android 8.0 and beyond (the new architecture is already running on the Developer Preview for Pixel phones).[…]”

Google Pawn: Intel firmware dumping tool!

Exciting, Google has a new tool that helps dump the UEFI/BIOS into a rom.bin, like FlashROM and CHIPSEC! Pawn is written in C++/C, Apache-licensed, requires Linux and GCC toolchain. Given 2014-2017 copyright, it has been around for YEARS, only went public 3 months ago, and I just noticed it today. See below, I am still looking for “Bishop”…

Pawn BIOS Dumping Tool
Copyright 2014-2017 Google Inc.
Disclaimer: This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.
Pawn is a tool to extract the BIOS firmware from Intel-based workstations and laptops. The name is a play on an internal tool that is also named after a chess piece.
[…]
sudo .build/pawn bios_image.bin
You can then use other tools like UEFITool to process the firmware image further.

https://github.com/google/pawn

What/where is Pawn’s companion utility, Bishop?? From pawn.cc comments:

Pawn, a companion utility to Bishop (go/bishop) to extract BIOS firmware from corp machines.

If you find it, please leave a Comment.

https://github.com/google?utf8=%E2%9C%93&q=Bishop&type=&language=

https://github.com/search?q=topic%3Afirmware-tools+org%3Agoogle&type=Repositories

 

Android 8.0 (“Oreo”) security changes

https://android-developers.googleblog.com/2017/08/introducing-android-8-oreo.html

https://developer.android.com/about/versions/o/android-8.0-changes.html#security-all

https://developer.android.com/topic/security/index.html

https://developer.android.com/about/versions/o/index.html

 

Dorian Cussen’s Android Security Reference

I just noticed this Android Security Reference. It has a few pages on boot phase:

https://github.com/doridori/Android-Security-Reference

https://github.com/doridori/Android-Security-Reference/blob/master/boot/verified_boot.md

https://github.com/doridori/Android-Security-Reference/blob/master/boot/bootloader.md

https://github.com/doridori/Android-Security-Reference/blob/master/boot/boot_process.md

http://kodroid.com/

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

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

https://firmwaresecurity.com/2017/02/21/u-root-firmware-solution-written-in-go/

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

initroot: Bypassing Nexus 6 Secure Boot through Kernel Command-line Injection

initroot: Bypassing Nexus 6 Secure Boot through Kernel Command-line Injection
By Roee Hay (@roeehay)
In the May 2017 Android Security Bulletin, Google released a patch to a critical and unique vulnerability CVE-2016-10277 in the Nexus 6 bootloader we had found and responsibly disclosed. By exploiting the vulnerability, a physical adversary or one with authorized-ADB/fastboot USB access to the (bootloader-locked) device (such as PC malware awaiting for an ADB-authorized developer’s device to be hooked via USB) could break the Secure/Verified Boot mechanism, allowing him to gain unrestricted root privileges, and completely own the user space (which may also lead much more), by loading a tampered or malicious initramfs image. Moreover, exploitation does not lead to a factory reset hence user data remains intact (and still encrypted). It should be noted that we do not demonstrate an untethered attack. During this research we also uncovered a 18-year-old Linux Kernel bug (not affecting Nexus 6 and probably does not affect any Android device): CVE-2017-1000363[…]

https://alephsecurity.com/2017/05/23/nexus6-initroot/

Google Fuchsia

https://fuchsia.googlesource.com/
https://fuchsia.googlesource.com/magenta/
https://github.com/fuchsia-mirror

http://spectrum.ieee.org/tech-talk/computing/software/a-modern-os-from-google
http://www.osdrawer.net/fuchsia-googles-new-operating-system/
https://en.wikipedia.org/wiki/Google_Fuchsia

https://firmwaresecurity.com/2016/08/15/uefi-bootloader-for-google-fuchsia/

 

Google: exploiting Broadcom’s Wi-Fi

Google ProjectZero has an excellent blog post on Broadcom WiFi firmware.

[…]In this two-part blog series, we’ll explore the exposed attack surface introduced by Broadcom’s Wi-Fi SoC on mobile devices. Specifically, we’ll focus our attention on devices running Android, although a vast amount of this research applies to other systems including the same Wi-Fi SoCs. The first blog post will focus on exploring the Wi-Fi SoC itself; we’ll discover and exploit vulnerabilities which will allow us to remotely gain code execution on the chip. In the second blog post, we’ll further elevate our privileges from the SoC into the the operating system’s kernel. Chaining the two together, we’ll demonstrate full device takeover by Wi-Fi proximity alone, requiring no user interaction. We’ll focus on Broadcom’s Wi-Fi SoCs since they are the most common Wi-Fi chipset used on mobile devices. A partial list of devices which make use of this platform includes the Nexus 5, 6 and 6P, most Samsung flagship devices, and all iPhones since the iPhone 4. For the purpose of this blog post, we’ll demonstrate a Wi-Fi remote code execution exploit on a fully updated (at the time, now fixed) Nexus 6P, running Android 7.1.1 version NUF26K.  All the vulnerabilities in the post have been disclosed to Broadcom. Broadcom has been incredibly responsive and helpful, both in fixing the vulnerabilities and making the fixes available to affected vendors. For a complete timeline, see the bug tracker entries. They’ve also been very open to discussions relating to the security of the Wi-Fi SoC. I would like to thank Thomas Dullien (@halvarflake) for helping boot up the research, for the productive brainstorming, and for helping search the literature for any relevant clues. I’d also like to thank my colleagues in the London office for helping make sense of the exploitation constraints, and for listening to my ramblings. […]

https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html

https://bugs.chromium.org/p/project-zero/issues/detail?id=1046#c2

http://www.wi-fi.org/product-finder-results?sort_by=default&sort_order=desc&categories=1,2,4,6,7,5,9,3&certifications=38

https://news.ycombinator.com/item?id=14034092

https://arstechnica.com/security/2017/04/wide-range-of-android-phones-vulnerable-to-device-hijacks-over-wi-fi/

I do not look forward to the day that most Redfish implementations are WiFi-based. 😦

U-Root: firmware solution written in Go

From 2015, something I missed because I didn’t know Go then. ;-(

U-root: A Go-based, Firmware Embeddable Root File System with On-demand Compilation
Ronald G. Minnich, Google; Andrey Mirtchovski, Cisco

U-root is an embeddable root file system intended to be placed in a FLASH device as part of the firmware image, along with a Linux kernel. The program source code is installed in the root file system contained in the firmware FLASH part and compiled on demand. All the u-root utilities, roughly corresponding to standard Unix utilities, are written in Go, a modern, type-safe language with garbage collection and language-level support for concurrency and inter-process communication. Unlike most embedded root file systems, which consist largely of binaries, U-root has only five: an init program and 4 Go compiler binaries. When a program is first run, it and any not-yet-built packages it uses are compiled to a RAM-based file system. The first invocation of a program takes a fraction of a second, as it is compiled. Packages are only compiled once, so the slowest build is always the first one, on boot, which takes about 3 seconds. Subsequent invocations are very fast, usually a millisecond or so. U-root blurs the line between script-based distros such as Perl Linux and binary-based distros such as BusyBox; it has the flexibility of Perl Linux and the performance of BusyBox. Scripts and builtins are written in Go, not a shell scripting language. U-root is a new way to package and distribute file systems for embedded systems, and the use of Go promises a dramatic improvement in their security.

Video and audio on first URL.

https://www.usenix.org/conference/atc15/technical-session/presentation/minnich

https://github.com/u-root/u-root

http://u-root.tk/

Android Things

Supported hardware: Intel® Edison, Intel® Joule, NXP Pico i.MX6UL, Raspberry Pi

https://github.com/androidthings
https://developer.android.com/things/hardware/index.html
https://developer.android.com/things/index.html
https://developer.android.com/things/preview/index.html
https://developer.android.com/things/hardware/developer-kits.html
https://android-developers.googleblog.com/2017/02/android-things-developer-preview-2.html

 

 

Google on fuzzing PCIe

https://twitter.com/revskills/status/830102871077224448

Fuzzing PCI express: security in plaintext
By Julia Hansbrough, Software Engineer

Google recently launched GPUs on Google Cloud Platform (GCP), which will allow customers to leverage this hardware for highly parallel workloads. These GPUs are connected to our cloud machines via a variety of PCIe switches, and that required us to have a deep understanding of PCIe security. Securing PCIe devices requires overcoming some inherent challenges. For instance, GPUs have become far more complex in the past few decades, opening up new avenues for attack. Since GPUs are designed to directly access system memory, and since hardware has historically been considered trusted, it’s difficult to ensure all the settings to keep it contained are set accurately, and difficult to ensure whether such settings even work. And since GPU manufacturers don’t make the source code or binaries available for the GPU’s main processes, we can’t examine those to gain more confidence. You can read more about the challenges presented by the PCI and PCIe specs here. With the risk of malicious behavior from compromised PCIe devices, Google needed to have a plan for combating these types of attacks, especially in a world of cloud services and publicly available virtual machines. Our approach has been to focus on mitigation: ensuring that compromised PCIe devices can’t jeopardize the security of the rest of the computer. Fuzzing to the rescue[…]

https://cloudplatform.googleblog.com/2017/02/fuzzing-PCI-Express-security-in-plaintext.html

Google documents internals firmware usage

Worth reading:

[…]
Secure Boot Stack and Machine Identity

Google server machines use a variety of technologies to ensure that they are booting the correct software stack. We use cryptographic signatures over low-level components like the BIOS, bootloader, kernel, and base operating system image. These signatures can be validated during each boot or update. The components are all Google-controlled, built, and hardened. With each new generation of hardware we strive to continually improve security: for example, depending on the generation of server design, we root the trust of the boot chain in either a lockable firmware chip, a microcontroller running Google-written security code, or the above mentioned Google-designed security chip. Each server machine in the data center has its own specific identity that can be tied to the hardware root of trust and the software with which the machine booted. This identity is used to authenticate API calls to and from low-level management services on the machine. Google has authored automated systems to ensure servers run up-to-date versions of their software stacks (including security patches), to detect and diagnose hardware and software problems, and to remove machines from service if necessary.
[…]

https://cloud.google.com/security/security-design/

http://www.theregister.co.uk/2017/01/16/google_reveals_its_servers_all_contain_custom_security_silicon/

 

IBM on attacking Android Custom Boot Modes

IBM’s SecurityIntelligence has a story on attacking Android’s Custom Boot Modes.

Android Vulnerabilities: Attacking Nexus 6 and 6P Custom Boot Modes
By Roee Hay
Co-authored by Michael Goberman.

In recent months, the X-Force Application Security Research Team has discovered several previously undisclosed Android vulnerabilities. The November 2016 and January 2017 Android Security Bulletins included patches to one high-severity vulnerability, CVE-2016-8467, in Nexus 6 and 6P. Our new paper, “Attacking Nexus 6 & 6P Custom Bootmodes,” discusses this vulnerability as well as CVE-2016-6678.[…]

https://securityintelligence.com/android-vulnerabilities-attacking-nexus-6-and-6p-custom-boot-modes/