Hacker News Reader

Comment by pslam | Hacker News Reader

> On the Neo900, the modem is connected via USB (bus; there is no physical connector) which means it doesn't have DMA.

You'll find the modem on most smartphones is connected via USB - or rather its chip-to-chip version, HSIC. For SoCs where it's on-die - on the same bus/fabric - they will (if it's not an idiotic design) use an IOMMU of some sort, to prevent DMA from having access outside of its sandbox.

Even if it's a modem on the other end of USB - which will almost certainly be using DMA, but at least host-programmed DMA - that's no guarantee. Google "Evil USB". USB is a overly complex stack which has and will continue to result in countless vulnerabilities, regardless of what you do with it.

View on HN

"Evil USB" (or "bad USB") is possible thanks to the U part of USB - universal. If you connect a pendrive to your computer, it can easily say that it's a keyboard, because your computer cannot easily verify that you haven't just connected a keyboard. It would need to ask you in some trustworthy way to be sure, which sometimes can be problematic.

OTOH, on the device like Neo900 it is well-known what kind of device is connected to the internal bus and software stack (at least on Linux) can easily be advised to not accept anything that doesn't look and behave like the included modem should.

In a properly configured user OS, the modem would need to use some software vulnerability to exploit the USB stack, so the same principles apply there as with, say, OpenSSL, browser or the kernel. Secret zero-days aside, when some bug is found, it is patched and you upgrade the vulnerable component, just like on PC.

This is correct. The problem in this example is not the pendrive, but the automatic selection of device drivers based on the PC OS 100% trusting physical access.

An easy way to see this is recompile the USB keyboard driver to ignore keyboard descriptors with a particular address or vendor ID. If you do this, the pendrive can't do anything because USB is host-controlled, as implemented by the OS. Without the OS initiating a conversation with the pendrive and saying "ok, I'll configure you as a keyboard and interpret responses from you as keystrokes", it can't happen.

As you point out, the main CPU on a phone does not implement HID autoconfig on the internal baseband bus.

I'm sure a udev rule would be sufficient to whitelist only the trusted hardware. However, nothing can stop a malicious one to spoof serial numbers or other characteristics of a trusted hardware.

I picked a terrible example which doesn't demonstrate what I intended to.

Any USB link requires the host to maintain some persistent state in data structures mirroring what it thinks the state of the device is. There's no "DMA" in the sense that the device has direct access to the host - but that doesn't preclude something as mundane as a buffer overflow, use-after-free and so on.

"DMA", with appropriate IOMMU, is just fancy shared memory communication. You're just as likely to mess that up as a serial link. It's happened. A lot.

Yes, parsing of untrusted data, race conditions, etc. are still a problem in general. My complaint was with the uninformed article, not your analysis.

If you connect a pendrive to your computer, it can easily say that it's a keyboard, because your computer cannot easily verify that you haven't just connected a keyboard.

Sure it can. Just pop up a dialogue on the screen displaying a random character string and ask the user to type the string. The dialogue could simply instruct the user to unplug and cast suspicion upon a device that is pretending to be a keyboard.

There is no IOMMU in USB. You've got it backwards: the IOMMU in PC's is on the host side of the USB controller, not the device side.

There's an easy way to tell. Does the bus carry memory addresses? Then it supports DMA. Does it just send messages? No DMA to protect against.

The USB controller on a PC does support DMA. The OS device driver allocates buffers and passes them to the controller to fill. If it's properly programmed, it will only store data into those buffers. An IOMMU is there to prevent malicious kernel privileged code from bouncing through peripherals that support DMA to compromise other privileged code.

Messages on the USB bus side have no addresses in them and there is no DMA involved.

This is exactly what I'm saying.

"DMA" as the parent puts it implies a core in the same SoC, rather than external. It would be hair brained to let this have unfiltered access to the fabric. However, that's exactly how older SoCs used to do it - in fact it used to be in charge and the AP shoved behind the IOMMU.

These days nobody I know of is stupid enough to have that arrangement. So it's not really a choice of "DMA" vs USB. External isn't buying much, unless you distrust the fabric filter (IOMMU), which isn't necessarily paranoid... but a level beyond this kind of system decision.

How does one find out about this for a particular phone? I just tried it for one model and the SoC was on the Wikipedia page, but a cursory web search couldn't tell me what kind of modem setup is in it. The SoC in question was the Snapdragon 410. I suppose a dmesg or lsusb on a (rooted?) Android device might do it.

> For SoCs where it's on-die - on the same bus/fabric - they will (if it's not an idiotic design) use an IOMMU of some sort, to prevent DMA from having access outside of its sandbox.

Do you happen to know whether this is the case for the latest generation of Qualcomm SoCs such as the Snapdragon 810 / MSM8994?

Reply on news.ycombinator.com