ProTIP : You Should Know What to Expect From Your Peripherals

Rogue peripherals are not reserved to elite attackers with physical access to the machine anymore: practical tools are regularly published and virtualization has led to widespread use of remote services provided by third-parties. In this paper, we advocate for a new more systematic approach in analyzing PCIe device security. Related works comprise attacks, from proof of concepts to more systematic tools, and the IronHide fuzzing device. But to our knowledge, no formalization or methodical analysis has yet been published. To fill in this gap, we introduce ProTIP, a Prolog Tester of Information Flow in PCIe networks. This open-source tool implements a model comprising all PCIe components, the CPU, I/OMMU and system RAM. It uses the constraint solving ability of the Prolog engine to enumerate all possible transactions between components. ProTIP naturally rediscovers all problems listed previously in the litterature, including the need for Access Control Services in switches and their limits. It also highlights two subtleties: firstly, a race condition enabling an attacker to arbitrarily answer read requests and secondly, that I/OMMUs base their access right check on an ID that can change. While the tool currently models specification-conformant behaviors and rogue endpoints, it is meant to be extended, e.g. with potential specific defects of given hardware, to evaluate the severity of their security impact. Thus, we believe ProTIP can quite efficiently be combined with other tools such as IronHide. 1 Motivation of Our Approach This paper1 initiates a new approach to systematically characterize the security issues raised by PCI Express peripherals. 1.1 Rogue Peripherals: an Underestimated Threat ? While it is widely acknowledged that peripherals form a very concrete threat to computer security, it remains commonplace to think that only 1 An updated version of this paper (with the URL of the tool) is available on the conference website (https://www.sstic.org/2017/presentation/protip/). 198 ProTIP : You Should Know What to Expect From Your Peripherals attackers with physical access to equipments can make use of rogue peripherals. We argue that this point of view is simplistic. First of all, hardware is rarely meant to remain in its initial state of deployment. Indeed, for practical reasons, hardware relies on firmware to support all kinds of execution environments. Firmware is a very low-level software embedded in hardware components. It is often meant to be updatable, on both functional and economical accounts. As a result, even a trusted and perfectly sound device can become malicious. This should be factored in a pragmatic security analysis. The BadUSB attack [12] has acted as a spectacular reminder of this fact a couple of years ago. The extreme difficulty to efficiently protect oneself against such attacks has renewed interest in the topic. Even so-called controlled information systems massively use USB devices, which tends to make the former remotely accessible. We do not dive into details about USB sticks here, since this is not the topic of our research. In our work, we rather focus on PCI Express (PCIe) devices, which have been shown to suffer from the same problems. Indeed, in [13], Perez et al. pave the way to the remote exploitation of a faulty firmware to gain control of a Network Interface Card (NIC), and then control its host using a Direct Memory Access (DMA) operation to write in system RAM. Secondly, the current tendency is to extensively use services hosted in datacenters and clouds of various kinds. These solutions rely on virtualization technologies to efficiently share hardware amongst end users, which get access to virtual machines. Service providers have to let users remotely use their hardware by design. In this context, attackers with no physical access to the servers obviously qualify. Providers have to guarantee customers that they can safely ignore that other – potentially ill-intended – customers are hosted on the same machine. In order to hamper the consequences of their potential compromission, peripherals should be compartmentalized. This security goal seems as desirable as user isolation. Providers are aware of the threats, as illustrates a recent publication of Google Cloud Platform [6]. Perhaps less popular but still relevant, multi-level security systems such as the Xen-based solution Qubes [16] or deployments based on Linux-KVM also have to address the same security concerns when it comes to compartmentalization and defense in depth. 1.2 PCI Express Devices and Why They Matter PCIe is often advertised as a bus protocol, because it was designed to be fully compatible with its predecessor, the PCI bus protocol. While PCI M. Daubignard, Y. -A. Perez 199 really deals with components on buses, PCIe components form a switched fabric of peer devices. They communicate with each other by sending packets routed by the switches interconnecting them. PCIe peripherals are called endpoint devices. The CPU and memory controller of the system RAM in a board do not directly send PCIe packets on the fabric: they do not have PCIe interfaces. Instead, their demands go through a root complex, which translate them into PCIe packets sent in the fabric2 (Figure 1). The fact that a PCIe endpoint device can communicate with the memory controller of system RAM without intervention of the CPU is the reason why DMA is efficient. Indeed, the CPU does not waste time scheduling the slow interaction with the peripheral. This architectural choice has a serious security impact though. In layman’s terms, the Memory Management Unit (MMU) in the CPU remains out of the loop during DMA transactions; hence, it cannot enforce memory access rights. As a result, the whole memory can be read or written by a rogue device. This can be prevented by separating the address space of the peripherals from that of the system memory. In other words, peripherals need to use their own virtual addresses. This requires a component dedicated to performing address translations and access right checks. This is the role of the I/OMMU, placed between peripherals and system RAM.