[HN Gopher] New dog, old trick: DaMAgeCard attack targets memory...
___________________________________________________________________
New dog, old trick: DaMAgeCard attack targets memory directly via
SD card reader
Author : thebeardisred
Score : 176 points
Date : 2024-12-09 18:15 UTC (1 days ago)
(HTM) web link (swarm.ptsecurity.com)
(TXT) w3m dump (swarm.ptsecurity.com)
| Syonyk wrote:
| 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?"
| assusdan wrote:
| 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)
| Syonyk wrote:
| 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.
| denotational wrote:
| > 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...
| Syonyk wrote:
| 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.
| gesser wrote:
| 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.
| Syonyk wrote:
| 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. ;)
| trollbridge wrote:
| 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.)
| gesser wrote:
| 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
| aidenn0 wrote:
| 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.
| bpye wrote:
| > 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.
| Syonyk wrote:
| 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.
| moreati wrote:
| 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.
| cjbprime wrote:
| 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.
| speransky wrote:
| Read like a novel, well done
| Animats wrote:
| 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.
| 01HNNWZ0MV43FF wrote:
| 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
| KeplerBoy wrote:
| PCIe is also a packet based point to point connection.
| Everything revolves around transaction level packets (TLPs).
| snvzz wrote:
| DMA. The gift that keeps on giving.
|
| God bless the blitter.
|
| Fat Agnus be fat.
| formerly_proven wrote:
| 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
| exsiting -- 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).
| KeplerBoy wrote:
| 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.
___________________________________________________________________
(page generated 2024-12-10 23:02 UTC)