[…]So what else is cool about this is, this is just one combination of invalid bytes that creates a PLD instruction the processor can ingest. There’s all sorts of combinations that will cause this same thing to happen
ARM has updated it’s C/C++ compiler toolchains.
C and C++ update for Arm Compiler 6:
As you are hopefully aware, Arm Compiler 6 has been available for 3+ years now, and has grown in maturity, and optimization quality release on release. As I write this, the latest available version is 6.8, and 6.6 has been qualified for use in safety-related development. We offer full support for the latest Arm processors, across the Cortex-A, R, and M, and SecureCore families. Arm Compiler 6 is available within DS-5 and Keil MDK toolchains. Furthermore the qualified version is available for purchase stand-alone. Arm Compiler 6 is based on the LLVM framework, using the modern Clang compiler front-end, and this is reflected in the name of the executable, Armclang. The compiler is then integrated into the full Arm tools suite, enabling use of legacy assembler code built with Armasm, as well as gas format assembler directly with Armclang. Finally the Arm linker (Armlink) brings in the optimized C and C++ libraries, or if desired the size optimized Arm C MicroLib library, as well as (optionally) implementing link-time optimizations across the source code.[…]
NXP has a webinar for IoT makers, talking about secure booting. ‘Webinar’ scared me, but there’s no registration required. 🙂
Watch this on-demand presentation to learn how to:
* Manage the life cycle of an IoT edge node from development to deployment.
* Leverage hardware and software offerings available with the Kinetis MCU portfolio that can help you protect against attacks.
* Ease the burden of secure IoT edge node development using new processors and architectures from ARM.
vTZ: Virtualizing ARM TrustZone
Zhichao Hua, Jinyu Gu, Yubin Xia, Haibo Chen, Binyu Zang, Haibing Guan
ARM TrustZone, a security extension that provides a secure world, a trusted execution environment (TEE), to run security-sensitive code, has been widely adopted in mobile platforms. With the increasing momentum of ARM64 being adopted in server markets like cloud, it is likely to see TrustZone being adopted as a key pillar for cloud security. Unfortunately, TrustZone is not designed to be virtualizable as there is only one TEE provided by the hardware, which prevents it from being securely shared by multiple virtual machines (VMs). This paper conducts a study on variable approaches to virtualizing TrustZone in virtualized environments and then presents vTZ, a solution that securely provides each guest VM with a virtualized guest TEE using existing hardware. vTZ leverages the idea of separating functionality from protection by maintaining a secure co-running VM to serve as a guest TEE, while using the hardware TrustZone to enforce strong isolation among guest TEEs and the untrusted hypervisor. Specifically, vTZ uses a tiny monitor running within the physical TrustZone that securely interposes and virtualizes memory mapping and world switching. vTZ further leverages a few pieces of protected, self-contained code running in a Constrained Isolated Execution Environment (CIEE) to provide secure virtualization and isolation among multiple guest TEEs. We have implemented vTZ on Xen 4.8 on both ARMv7 and ARMv8 development boards. Evaluation using two common TEE-kernels (secure kernel running in TEE) such as seL4 1 and OP-TEE shows that vTZ provides strong security with small performance overhead.
I nearly missed this CHIPSEC announcement in the below Black Hat abstract. Exciting.
Blue Pill for Your Phone
By Oleksandr Bazhaniuk & Yuriy Bulygin
In this research, we’ve explored attack surface of hypervisors and TrustZone monitor in modern ARM based phones, using Google Nexus 5X, Nexus 6P, and Pixel as primary targets. We will explain different attack scenarios using SMC and other interfaces, as well as interaction methods between TrustZone and hypervisor privilege levels. We will explore attack vectors which could allow malicious operating system (EL1) level to escalate privileges to hypervisor (EL2) level and potentially install virtualization rootkit in the hypervisor. We will also explore attack vectors through SMC and other low level interfaces, interactions between TrustZone and hypervisor (EL2) privilege levels. To help with further low level ARM security research, we will release ARM support for CHIPSEC framework and new modules to test issues in ARM based hypervisors and TrustZone implementations, including SMC fuzzer.
IETF Internet draft: draft-moran-fud-architecture-00:
A Firmware Update Architecture for Internet of Things Devices
July 18, 2017
Brendan Moran, Milosch Meriac, Hannes Tschofenig
Vulnerabilities with IoT devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. This document specifies requires and an architecture for a firmware update mechanism aimed for Internet of Things (IoT) devices. The architecture is agnostic to the transport of the firmware images and associated meta-data. This version of the document assumes asymmetric cryptography and a public key infrastructure. Future versions may also describe a symmetric key approach for very constrained devices.
There’s a mailing list for FUD:
The Threat of Virtualization: Hypervisor-Based Rootkits on the ARM Architecture
Robert Buhren, Julian Vetter, Jan C. Nordholz
The virtualization capabilities of today’s systems offer rootk-its excellent hideouts, where they are fairly immune to countermeasures. In this paper, we evaluate the vulnerability to hypervisor-based rootkits of ARM-based platforms, considering both ARMv7 and ARMv8. We implement a proof-of-concept rootkit to prove the validity of our findings. We then detail the anatomy of an attack wherein a hypervisor rootkit and a userspace process collaborate to undermine the isolation properties enforced by the Linux kernel. Based on our discoveries, we explore the possibilities of mitigating each attack vector. Finally, we discuss methods to detect such highly privileged rootkits so as to conceive more effective countermeasures.