Use a Google or Apple phone and stop worrying about their basebands, which are effectively USB peripherals.

> While working on Replicant, a fully free/libre version of Android, we discovered that the proprietary program running on the applications processor in charge of handling the communication protocol with the modem actually implements a backdoor that lets the modem perform remote file I/O operations on the file system.

Are there cases where a similar situation has been described with a USB 1.1 audio device using an open source driver? Or any other class of USB device used by tens of millions of people?

You have to be very specific about what Android phones you're talking about, and I'm the wrong person to debate Android security with. I have friends who work on Android platform security and I am very hesitant to cast aspersions on the Android security effort as a whole. But my advice for people who really care about security is: get an iPhone.

The radio typically has DMA on the primary CPU, and remotely exploitable vulnerabilities.

Which phone are you talking about, and which vulnerability?

A specific list requires a lot of research to produce, and I don't have one handy. It's generally understood that the answer is "most" phones.

As for vulnerabilities, I'm just assuming here, but it's a pretty reasonable assumption. Radio firmwares are old legacy code, written by hardware people, likely in C or even assembly, closed source, and are highly guarded secrets. We already know that they, you know, have a radio in them, and that LE can use devices like stingrays to spoof towers. This sounds like a disasterous combination of factors for security. I'm 99% certain that most phones have an RCE waiting to happen, and most of them will have DMA on the primary CPU.

I don't think this is accurate for modern Android or iOS devices. AIUI basebands are connected via HSIC (a chip-to-chip variant of USB) nowadays, which doesn't give the baseband DMA.

My assumption is that they're talking about a component that is not the baseband. The baseband itself definitely isn't connected via DMA. I'm trying to make sure we're using the same terminology before I respond.

For what it's worth, at least for Apple phones, I think he's wrong about there being any component that matches the description he's provided that is a memory corruption bug away from being able to overwrite AP memory (and I'm even more sure there's no component that can do that to the SE).

But I'm not sure what exactly they're talking about, so it would be weird to rebut at this point.

HSIC (and USB in general) is a very complicated stack. Host-controlled DMA is probably in use, which is fragile at best. Historicically evil has definitely been possible with USB, and we all know how good phones are about getting updates.

Wait, so you were talking about the baseband chips?

Both Google and Apple design against the baseband chips as adversarial components. Before we play the "but HSIC is complicated and there's DMA in it", we're talking about security teams that have designed and implemented encrypted memory busses; I think they can handle bog-standard interconnects. I can't speak to random Xiaomi phones, but the baseband security risk story on modern flagship phones is pretty much a myth.

"Phones are insecure because baseband DMA" is a pretty reliable way to spot people who, for lack of any better way to put it, tend to get their security news from Boing Boing.

I've done some platform work on phones, but I'm not close to a leading expert on this stuff (I'm an old-school bug hunter with a focus on crypto bugs, which drags me into some odd corners sometimes). I try hard not to assume that my exposure to this stuff means I know more than other people, not least because that habit has gotten me pantsed in debates with people who know a lot more than me. Modern phones are super complicated and I do not have their block diagrams available to recall from memory. Maybe there is some component that can DMA over arbitrary AP memory that I just wasn't aware of. Are you aware of one? Have you worked on these systems?

I trust Google, but I don't trust vendors. I expect vendors to make compromises left and right to deal with shitty hardware (oh, the radio doesn't work with this security feature enabled? Meh, we don't need it).

However, I'll admit that you seem more knowledgable than me on the subject, so I won't spout FUD if you say so.

This is a valid concern for off-brand Android phones. Google's Android security team is on top of this stuff with their hardware vendors. Nobody in the industry does hardware security better right now than Apple. In neither case is the Boing Boing narrative of "bug on the baseband means you own the whole phone" true. I'm sure there's an Android phone on the market where it is true, but there are a lot of crappy Android phones.

For those of you playing along at home, it's this "there are a lot of crappy Android phones" thing that dominates our concerns about Android, and is the reason we recommend to laypeople (lawyers, reporters, NGOs) to get iPhones and avoid Android phones.

I'm not sure if "Evil/BadUSB"-style vulnerabilities really apply to HSIC, where the code would know what kind of device to expect. It's possible there are ways to make this work - I'm not aware of any past vulnerabilities of this nature, but I'm not familiar enough with this topic to really make an educated guess. Either way, it doesn't seem like a matter of "just find a zero-day in the baseband and you get DMA", it's more along the lines of a vulnerability in, say, Safari, which then needs all kinds of sandbox escapes and privilege escalations to be useful for an attacker, and it still does nothing to get past Secure Enclave (and possibly Android's variant of that).

If the threat was solely limited to an attack on the baseband that could be valid.