The idea here would be to see if it was possible to control the NVMe
over jtag in order to ask it to perform a DMA read over the PCIe Bus.
In order to do so, the PCI_COMMAND_BUS_MASTER has to be set to 1. We
can assume that since the chip is using remote RAM, it is allowed to
act as a master over PCIe. Here is a snippet of the probing function
of the kernel driver.
(code)
Our goal here is to force the DMA to happen just by controlling the
ARM of the NVMe over JTAG, in order to ask it to dump the region we
alloc'd in kernel and see if we get the data out of it.
In other words, full root exploit of the phone from the NVMe JTAG pins.
In other words, full root exploit of the phone from the NVMe JTAG pins.
Sure, except the data on the device will be encrypted. The keys are kept in the iphone's tamper resistant security enclave. Android and iOS both have full disk encryption enabled out of the box these days. (On iOS I don't think you can disable it.)
No, it doesn't exploit the host. The "Host" in the case of such an NAND device is the Baseband SoC, not the ARM controller on the NAND device. You can be pretty sure that Apple did not include decryption on the NAND chip itself. That would defeat the point.
However, he does this by using the NAND as a PCIe master, which implies that the peer (main SoC) would be switched to device mode, and the whole PCIe handshake happens properly.
While I can't dismiss that possibility entirely, I'm not holding my breath for it to work out.
No, you don't have to switch "Master" and "Device" mode (what does that even mean in PCIe?).
You might be surprised to hear that your networking card, the AHCI-SATA interface and even the sound-card soldered onto your computer's mainboard is allowed to, and does, read from and write to your computers memory whenever you are using it. {that's just where I had to dig in, in the past, almost any modern peripheral uses DMA}
If the operating system needs a block from your harddisk to be read, and stored in a certain memory location it will actually tell the physical memory location to the AHCI controller and tell it to write the contents into memory, on it's own. It will signal an interrupt when it has finished transfering the data.
Your networking card will have "ring descriptors" which tell the card a list of buffers (in RAM) into which to save new incoming packets. It will raise an interrupt after it has finished writing to the first buffer.
Your sound-card will likewise have a list of buffers from which it reads, and to which it writes just as you are listening to mp3s, or having a phone conversation with google hangouts.
The worst offender would probably be Firewire which, ifnotconfiguredtoblockthis (modern OSes do), allows these reads from/writes to memory triggered by any connected external device, and from/to addresses supplied by this external device. It can be a huge help for debugging, though.
On typical computers, there's no safeguard against this happening. But some have a IOMMU which can be used to limit DMA and redirect DMA accesses with respect to physical memory.
To what degree can misbehaving PCIe devices (as in the device as a whole being malicious, not simply manipulated) override IOMMU protections? Can they pretend to be another device or otherwise send unexpected signals to confuse this defense?
Violating the timing specs for PCI signalling would put the whole system into an undefined state. It's possible you could glitch the thing on the other end into doing whatever you want. Who knows?
PCIe devices can identify themselves to the host with whatever vendor and device IDs they want.
Since PCIe is a point to point link rather than a shared bus, it is not really possible for a malicious peripheral to pretend to be connected through a different port. PCIe switches may weaken this security somewhat.
No, root pendrives must exploit bugs in USB/block/fs/UI subsystems of the OS. PCIe devices can read/write RAM directly as they please unless isolated behind IOMMU.
The JTAG angle is unnecessary, and difficult to do in practice with this LGA70 chip face-down soldered onto the logic board.
It really means there is a Cortex-A (so lots of brunt) with a firmware update mechanism that has 1) direct access to the application processor RAM and 2) direct access to the plentiful permanent storage.
Comments
The gold is at the bottom:
(code) In other words, full root exploit of the phone from the NVMe JTAG pins.Sure, except the data on the device will be encrypted. The keys are kept in the iphone's tamper resistant security enclave. Android and iOS both have full disk encryption enabled out of the box these days. (On iOS I don't think you can disable it.)
That isn't the point. This exploits the host, which holds plaintext data in memory.
No, it doesn't exploit the host. The "Host" in the case of such an NAND device is the Baseband SoC, not the ARM controller on the NAND device. You can be pretty sure that Apple did not include decryption on the NAND chip itself. That would defeat the point.
That isn't what he's describing. He is commanding the storage controller to initiate DMA from host memory over the PCI-Express bus.
Ah good point.
However, he does this by using the NAND as a PCIe master, which implies that the peer (main SoC) would be switched to device mode, and the whole PCIe handshake happens properly.
While I can't dismiss that possibility entirely, I'm not holding my breath for it to work out.
No, you don't have to switch "Master" and "Device" mode (what does that even mean in PCIe?).
You might be surprised to hear that your networking card, the AHCI-SATA interface and even the sound-card soldered onto your computer's mainboard is allowed to, and does, read from and write to your computers memory whenever you are using it. {that's just where I had to dig in, in the past, almost any modern peripheral uses DMA}
If the operating system needs a block from your harddisk to be read, and stored in a certain memory location it will actually tell the physical memory location to the AHCI controller and tell it to write the contents into memory, on it's own. It will signal an interrupt when it has finished transfering the data.
Your networking card will have "ring descriptors" which tell the card a list of buffers (in RAM) into which to save new incoming packets. It will raise an interrupt after it has finished writing to the first buffer.
Your sound-card will likewise have a list of buffers from which it reads, and to which it writes just as you are listening to mp3s, or having a phone conversation with google hangouts.
The worst offender would probably be Firewire which, if not configured to block this (modern OSes do), allows these reads from/writes to memory triggered by any connected external device, and from/to addresses supplied by this external device. It can be a huge help for debugging, though.
On typical computers, there's no safeguard against this happening. But some have a IOMMU which can be used to limit DMA and redirect DMA accesses with respect to physical memory.
To what degree can misbehaving PCIe devices (as in the device as a whole being malicious, not simply manipulated) override IOMMU protections? Can they pretend to be another device or otherwise send unexpected signals to confuse this defense?
Violating the timing specs for PCI signalling would put the whole system into an undefined state. It's possible you could glitch the thing on the other end into doing whatever you want. Who knows?
PCIe devices can identify themselves to the host with whatever vendor and device IDs they want.
Since PCIe is a point to point link rather than a shared bus, it is not really possible for a malicious peripheral to pretend to be connected through a different port. PCIe switches may weaken this security somewhat.
It is a similar vector of attack as with root achieving pendrives, except PCIe devices are even less verified.
TCB verification in TPM and firmware to verify the code running on the microcontroller is required to prevent such an attack.
No, root pendrives must exploit bugs in USB/block/fs/UI subsystems of the OS. PCIe devices can read/write RAM directly as they please unless isolated behind IOMMU.
Unless they are USB-C devices and the host supports Thunderbolt 3 without an IOMMU. An innoculous looking device could perform a DMA exploit.
The JTAG angle is unnecessary, and difficult to do in practice with this LGA70 chip face-down soldered onto the logic board.
It really means there is a Cortex-A (so lots of brunt) with a firmware update mechanism that has 1) direct access to the application processor RAM and 2) direct access to the plentiful permanent storage.
He made a board so that he can do JTAG in-line. Not sure how else he could tell the processor to do something.
By flashing custom unverified firmware, of course.
Flashing custom unverified but somehow-signed-with-Apple's-secret-key firmware?
Does the phone's ARM CPU have an IOMMU?
Yes