New dog, old trick: DaMAgeCard attack targets memory directly via SD card reader

FireWire had a backdoor into memory. FireWire isn't a "bus", it's a local area network. Mostly you send packets around. IP over Firewire was a thing. But there are also built-in packets to read and write memory, one word at a time. That's how commands are sent. This probably made sense to people who thought in terms of device registers, rather than a command with parameters.

There's a register in most Firewire controllers where you can set the address bounds for which that function is available. I once noted that the hard-coded default values for Linux were 0 .. 2^32-1, that is, the first 4GB. I reported this as a security bug and was told it was needed for the kernel debugger.

Sigh.

That's a solid writeup on the history of external DMA attacks! Very nicely done, and well worth a read.

This sort of thing is why QubesOS tends to put hardware controllers in isolated VMs and only pass access through. With a working IOMMU (any modern hardware has this), all you can get is DMA access into a VM that doesn't actually have much of interest in it, and no access into other VMs...

//EDIT: Though at a closer read, there's some that... isn't quite right, in how terms and examples are done. I'd expect better from someone doing low level security work - INB copies to a general purpose register, not a memory address, a DMA controller is a "discrete" bit of hardware, it's not very "discreet," etc. I'm not sure. This is starting to feel very AI-assisted to me. The overall concepts are fine, but a lot of the background section doesn't read reasonably, or goes off into weird weeds and... never explores them. The Intel Xeon is not a less exotic example of a DMA controller. The PC/AT platform did not have a PCI bus.

Eh. I remain convinced it's a decent enough overview of the matter, but a lot of the details just read really weird to me in the background sections. To the point that this could be an interview discussion question. "What does this get subtly wrong?"

I'm pleasantly surprised there are any devices supporting SD Express. I thought the standard had died on the vine. So Apple, please pull your finger out and include SD Express in the MBP models that have an SD slot.

It would have been good to hear about whether there are still any mainstream computer platforms that ship with IOMMU off, since it is the mitigation here.

While SD Express remains profoundly unpopular, the CFExpress standard (preceded by XQD) is the norm for mid-range and up cameras these days. And CFX is, just like you expected, simply a (well-specified subset of) NVMe SSD in a somewhat more robust case. CFX readers are generally just like the article describes the SDX USB reader: There's a chip in there which talks PCIe and NVMe to the SSD and emulates SCSI over USB (UASP) on the host side:

> Wait a second. USB3 doesn’t do Bus Mastering. Either there’s something wrong with the device description, or there’s some hardcore multiplexing of lines going on. But the reality was less exсiting — it uses a JMicron JMS581LT host controller chip, which implements PCIe root/switch/something at least partially, and communicates with the card over PCIe. But it doesn’t pass it to the host, and communicates with the host over 10 Gib/s USB. Interesting chip overall, but not interesting as a DMA target.

However, there are also Thunderbolt CFX readers. And those do actually hook up the SSD to the host directly.

> By the way, the photo camera probably doesn’t need the speed of PCIe

"need" is a curious question, if you're inclined to shoot RAW + JPG and let 'er rip at 20 frames per second (no shutter means no wear, after all!) you're producing around 1.5 gigabytes of photos... per second. (In practice, card write speeds seem to tap out at around 850 MB/s).

DMA. The gift that keeps on giving.

God bless the blitter.

Fat Agnus be fat.

Read like a novel, well done

[dead]