Pandora's Box in Your SSD: The Untold Dangers of NVMe

TL;DR

The eNVMe platform is introduced, a malicious NVMe storage device that provides a novel and unique tool for security researchers, enabling deeper exploration of vulnerabilities in operating system storage subsystems.

Abstract

Modern operating systems manage and abstract hardware resources, to ensure efficient execution of user workloads. The operating system must securely interface with often untrusted user code while relying on hardware that is assumed to be trustworthy. In this paper, we challenge this trust by introducing the eNVMe platform, a malicious NVMe storage device. The eNVMe platform features a novel, Linux-based, open-source NVMe firmware. It embeds hacking tools and it is compatible with a variety of PCI-enabled hardware. Using this platform, we uncover several attack vectors in Linux and Windows, highlighting the risks posed by malicious NVMe devices. We discuss available mitigation techniques and ponder about open-source firmware and open-hardware as a viable way forward for storage. While prior research has examined compromised existing hardware, our eNVMe platform provides a novel and unique tool for security researchers, enabling deeper exploration of vulnerabilities in operating system storage subsystems.

Figures (4)

• Figure 1: Overview of NVMe write data example: An NVMe SSD is connected over PCIe and has direct memory access to the system RAM. In order to write (or read) data to an NVMe SSD the CPU prepares IO submissions (requests) in an IO submission queue (SQ) in RAM. These submissions describe the source location of the data and destination inside the SSD. (1) The CPU rings the NVMe SSD's doorbell by writing a PCI register, letting the NVMe SSD know there is work to do. (2) The SSD controller fetches the submissions from the IO SQ in RAM. (3) The SSD reads data from RAM with DMA and stores it in flash. (4) The controller writes the completions in the IO completion queue (CQ) in RAM and sends an IRQ to the CPU to indicate the submissions have been completed. Read transactions are done in a similar manner but with data being moved from flash to a buffer in RAM. Green regions in RAM are supposed to be accessible to the NVMe SSD, gray and red regions are not supposed to be accessed by the NVMe SSD.
• Figure 2: Top: Rockchip RK3588 SoC based single board computer (SBC) FriendlyElec NanoPC-T6 (bottom and top view). The T6 runs our NVMe firmware and comes with adapter PCBs to connect to target computer M.2 or regular PCI express interfaces. Unpopulated adapter PCBs are shown on top. Middle: a screenshot of our eNVMe platform inside the target host computer, where it is recognized as a regular NVMe SSD. We chose a model name that allows us to differentiate it, but we can choose any model name. Bottom: Our aNVMe platform mounted in a target host PC (bottom M.2 slot) alongside a regular NVMe SSD (top M.2 slot). Access to the T6 is done through an Ethernet cable and UART, but a screen keyboard and mouse can also be connected as it is a full-blown single board computer.
• Figure 3: Architecture of our eNVMe platform. The NVMe firmware is implemented as an endpoint function that takes care of the normal IO redirected to a storage backend and provides means to execute extra functionality in kernel or user-space. The fully customizable root file system of the SBC (not visible to host) allows to take advantage of numerous cyber-security software toolchains to probe the target host through PCIe, as well as any file stored on the eNVMe itself.
• Figure 4: Remote activation of dormant evil NVMe SSDs. The attacker uses http cookies that contain hidden commands to remotely activate or control the NVMe SSDs. Tracking cookies through ad campaigns is a widely available tool to get small quantities of arbitrary data written to drives all around the world.