S
Story
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.

PCIe is also a packet based point to point connection. Everything revolves around transaction level packets (TLPs).
I remember a security presentation on USB saying the same thing. It's a network, not a bus, and anything on a network can be malicious
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).

CFX seems like a great form factor for external/swappable disks. Would love to have one or two of those slots on my laptop.

Shame we aren't living in that kind of world.

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?"

Thank you for noticing (and reading at all). We'll try to fix these asap. "INB" is a genuine mistake, "PC/AT" should be "PS/2" and "discreet" is a translation error.

Some Xeon chips have additional DMA controllers "onboard".

No AI was used, each mistake here is handmade with love and 100% organic :) We wanted to give a decent (but not too deep) historical overview, however first and foremost we introduce new vector to conduct the attack.

Thanks for responding! Welcome to HN!

I write long form text posts as well, so I appreciate the format. It just had a number of things that didn't seem quite right to me, being in similar deep technical weeds.

Now try the attack on Qubes. ;)

Generally speaking, PS/2s did not have a PCI bus either, although some of them did have an ISA bus.

(Both ISA and PS/2 microchannel would allow busmastering of exactly what your article describes, though, so the point might as well stand - for that matter, so would other buses like EISA and VESA local bus.)

Well yeah, PS/2 didn't have PCI, they got MCA. Then MCA-led takeover failed, and industry adopted PCI instead. That's the thought process. We'll have to come up with better wording, I guess
Russian version of this article, published slightly earlier AFAIU ( https://habr.com/ru/companies/pt/articles/863536/ ) does not look very AI-assisted, but still contains some of the weird moments you mentioned.

"discreet" looks like translation error, in russian version word "special" is used. PC/AT is still there, as well as Xeon example (latter does not seem "not quite right" to me)

Yeah, there were a few words early on that struck me as "This is a non-native English speaker" sort of translation issues, which don't bother me in technical writing like this. But when they started doing INB/OUTB examples as memory addressed instructions, vs copying into a register... I get the point being made, but also, that's not a translation error. Don't use the "This is an actual instruction" font if you're not quoting actual instructions that exist on the hardware. "inb 0x8, 0xFF" is not a valid x86 instruction, not even close.

Anyway, I'd also like to see some of their source, or hardware diagrams, but... it'll come out eventually, I suppose.

Proper IOMMU configuration and assigning anything with DMA to a disposable service VM still solves a lot, though at least these attacks require physical access. So far. I'm sure someone, at some point, will release a SD Express card with awful enough firmware that you can pivot through it for a software-only attack on this sort of system.

With a working IOMMU (any modern hardware has this)...

I agree with the "IOMMU" part, but my experience with the "working" part is more hit-or-miss.

> The Intel Xeon is not a less exotic example of a DMA controller.

The full context is:

> The DMA controller is just used as an “memcpy() hardware accelerator”. And this is not a joke. Sometimes those blocks are used in microcontrollers to copy large swathes of data inside RAM. A less exotic example of this we can mention are Intel Xeon platforms.

I interpreted this as a reference to the Data Streaming Accelerator (DSA) [1], which is a programmable DMA peripheral on the SoC that can be used to accelerate writes to and from I/O devices (amongst other things).

[1] : https://www.intel.com/content/www/us/en/products/docs/accele...

But they never expand on that in the article. They just drop the Xeon reference there, and carry on as though they'd never said a thing about a Xeon.

I agree, that's probably what they're referring to, but it was neither needed to make the points they were trying to make, nor expanded into something to further strengthen the points made.

  • bpye
  • ·
  • 2 weeks ago
  • ·
  • [ - ]
> 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...

Of course you have to ensure that you harden the interface between that VM and the host sufficiently.

Sure, this is literally the core of Qubes security model. They run a massively stripped down Xen that eliminates a lot of the complex interfaces, the old legacy hardware emulation models, etc. If you can pivot through Xen, you own Qubes entirely - you can get to Dom0, and do whatever you want. They've gone very much out of their way to ensure that the VM to hypervisor interfaces are as limited as possible, and as hard as possible.
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.
  • snvzz
  • ·
  • 2 weeks ago
  • ·
  • [ - ]
DMA. The gift that keeps on giving.

God bless the blitter.

Fat Agnus be fat.

Read like a novel, well done
[dead]