Couple of weeks ago I read brilliant posts [1], [2] published by Project Zero team member, Gal Beniamini. In a nutshell he showed how to perform a remote attack on smartphones using vulnerabilities in a WiFi device and in SoCs, and then take over the operating system running on the smartphone leading to a full control of the smartphone.

In the first blog he very nicely describes that a modern SoC consists of a number of computing systems having their own CPUs, memory, operating systems, SW stacks. Many of those “small” devices on SoC are facing the outside world and are immediate part of the attack surface.

Roughly, a system architecture of a deployed modern SoC looks as follows:

A WiFi device has an antenna to the outside of the smartphone and is connected to the memory bus via SMMU (we will cover SMMU a bit later). On the other side of the memory bus there are CPUs where a host operating system is executed. In this case, the host OS is Android. The host OS provides a driver for this WiFi device. SMMU (System Memory Management Unit) together with a DMA (Direct Memory Access) controller allow a WiFi device to execute direct access to RAM. This direct access mechanism speeds up the data exchange between the driver and the device. In the red boxes we depict a simplified paths needed to take over a smartphone. We describe these paths below.

In this Google Project Zero blog a Broadcomm WiFi device is analyzed. The WiFi device consists of an ARM CPU, has its own memory, and has about 700kb of executable code. I would like to highlight the number 700kb, thus, this device definitely is a very complex system. The researchers have exploited weaknesses, in how device process incoming packets to implement WiFi functionality (e.g. network scanning, packet filtering), to remotely force the WiFi device to execute their code (Step 1: takeover).

Gal Beniamini described two different attack paths to hack the smartphone: one is going through tricking the driver on the host OS (Step 2.a) and another via bypassing the SMMU (Step 2.b). Both paths allowed modification of RAM (Step 3) and finally taking over the device (Step 4).

In this blog I would like to focus on the second attack vector (Step 2.b). SMMU stands for System Memory Management Unit and on x86 it is also known as IOMMU (Input/Output Memory Management Unit).

IOMMU has been introduced to restrict devices accesses to the memory. Devices can use DMA to increase performance of I/O operations whenever devices and the drivers need to exchange big amount of data. In a nutshell DMA allows a device to write data directly to the RAM where the driver/OS expects those data. IOMMU introduces virtual memory for the device and works similar to a usual MMU on CPU.

Gal Beniamini has found out that SMMU was not used (i.e. not configured) in the analyzed deployments: Nexus 6 based on Qualcomm’s Snapdragon 810 SoC, Galaxy S7 Edge based on Samsung’s Exynos 8890 SoC. The missing separation between SoC devices and RAM allowed to initiate direct memory accesses from the compromised WiFi device, i.e. a direct modification of the host OS memory. This direct access enables control over the complete smartphone.

This work illustrates that the security model of the SoC and/or smartphone assumed a non-hostile WiFi device. Indeed, in the past, IOMMU was considered merely as a protection against buggy drivers. Nowadays, the role of the IOMMU is transforming to a safety and security guard between various parts of the same SoC. Thus, configuration of IOMMU and OS/Hypervisor defines security domains within an SoC.

On the market there are a lot of different IOMMU implementations, e.g. Intel VT-d, AMD-Vi, ARM SMMU, Samsung SMMU, Qualcomm SMMU, NXP PAMU, TI Firewalls. Some have the same name SMMU but are in fact very different designs. We had a number of projects with various IOMMU/SMMU implementations with safety, security, and performance requirements. One of the most complex designs we faced was on TI Jacinto6, where IOMMU design (called firewalls on that SoC) is spread over hundreds of functional blocks making a coherent configuration very complex. This experience was published as part of the EURO-MILS project in a paper on “Supporting MILS on platforms with distributed IO virtualization”. It is interesting to note that ARM SMMU design has begun receiving a good acceptance among SoC vendors and it seems that ARM-based SoCs tend to converge on SMMU designs, thus, the corresponding SW will be more portable.

As a summary I would like to stress not to trust the devices on SoC per se since these are very complex computers living on an SoC having their own CPU, operating system, and their own attack surface. As illustrated above, an attack can come from such a seemingly trusted device.