It's good to draw attention on baseband processors, but there are technical assertions in this post that are probably not accurate (lack of auditing and the notion that you can assess the security of a whole phone system by whether or not there's an IOMMU).
The systems security of modern phones is surprisingly complex. Google and Apple both care very deeply about these problems, and both have extremely capable engineers working on them. Without getting too far into the weeds: they haven't ignored the baseband.
The team behind Replicant reported that they found a baseband backdoor in Samsung Galaxies[0][1]. I think it's perfectly fine to extrapolate from that that you probably shouldn't trust the baseband, even if Google and Apple are looking into it. Until they have a concrete solution shipped, all the in-the-closet work on the problem is meaningless.
My objection is with the idea that you can look at a design, not see an IOMMU, and extrapolate from that the notion that the baseband has full access to the memory of the other chips in the design.
That's a reasonable assumption in a PC design. There may have been a point, for some phones, where it was a valid assumption for phones. It's not with a modern phone design.
In my research on phones from the Unrevoked project (admittedly, 4+ years ago), this was the case: the baseband and the CPU shared the same memory. The baseband memory was carved out from the CPU such that the CPU could not access it, but the microcontrollers serving the baseband had CPU access, as I recall from the Qualcomm boot documentation: the chain of trust from CPU boot was established by the baseband processor, not the other way around.
I would imagine that things have changed a little bit, but the baseband back then, and I imagine still now, is considered to be the ultimately trusted element of the system. I'd be surprised to hear that they've changed so much that the baseband doesn't still have full control over its host system.
You should qualify which specific phone designs you are referring to (or if it's "all new phones", when the cutoff date was). After all, you are responding to someone who has researched this and found (like others) that indeed, the baseband in older phones did have full control.
Your statement is general to the point of misinformation.
Bear in mind that the baseband's host system doesn't necessarily need to be the same as the phone's core systems. You could just isolate the baseband and only communicate with it via a defined interface.
This is why I wish Replicant was more successful. They mention a CM issue to fix it, and nobody did. As an owner of several Samsung devices, the fact there is a wholly proprietary processor in my phone with complete control of it makes me not treat it like a computer.
The premise of the article is flat out wrong. Mainstream smartphones do not provide DMA access from the baseband to the application processor's memory.
The connection is usually HSIC, which is a chip-to-chip USB derivative.
The AP is responsible for setting up buffers for communication and manages its own host controller. But like I2C or even older UARTs, the AP remains in control of the communications.
Yes, basebands need more auditing and a security model more like modern APs (e.g., separation of privileges and exploit countermeasures like ASLR and non-exec). Yes, getting baseband access then lets you monitor regular voice and SMS comms. But no, it does not instantly compromise the AP so using the Signal app would still be secure.
What is the impetus to trust assertions of independence given both processors are still on the same die?
Mobile phones have a readily available control/backhaul channel and there's a long history of carrier enforced device control and state mandated telecom surveillance effecting [sic] the design culture. Qualcomm obviously works with the NSA, if only to protect against infiltration by other intelligence agencies. So it's really a question of whether the NSA is willing to have their root kits require physical installation or not.
The original post talks about DMA being a method the baseband can use to compromise the AP, which is false for any mainstream design. Trust doesn't have anything to do with it; the protocol literally does not support DMA.
The conclusion of the original post isn't wrong though, despite the exact details being out of date by (a scant) 5 years.
I have a hard time believing that HSIC is the entire extent of interconnection, with the processors being on the same die and all. Are you asserting that the baseband and application processors use completely independent rams and flashes? Independent memories seem more expensive (price+power) than a single shared bank with MMU, but since the storage requirements of the baseband are known at design time then perhaps not terribly.
If they aren't independent memories, then the term DMA actually still applies even if the interconnect protocol is not based on it. Mobile literature is quite inaccessible (another symptom), but everything I've seen refers to having an MMU as the advancement. I have a hard time believing that would be controlled by the application processor (leaving the baseband vulnerable), but please correct me with specifics if this is wrong.
You can use this same kind of logic to suggest that any system is broken.
Some of the cores on a complicated mobile device might have their own memories, and some of them might be isolated from the memories of other cores with silicon. I'm sure there are devices where there are insecure cores with no isolation at all --- just like there's a ton of C code that will read a URL off the wire into a 128 buffer on the stack.
The problem you're suggesting device designers have to solve --- allowing core A access only to a range of the total memory available "on the die" --- isn't a hard one.
From the suggestions you've made in your comments --- and I mean this respectfully --- I think you'd be very surprised by the hardware systems design in a modern mobile device. They are in some ways more sophisticated than the designs used for PCs.
So, the point of this subthread is that mobile devices are much more complicated than the simplistic ("no IOMMU? the baseband can read/write AP memory!") model proposed in the article. It makes an OK overall point (we should care about baseband security!) but uses a very flawed argument to get there.
Actually the real problem I'm suggesting device designers need to solve is doing the bare minimum to make the public (ie decentralized vulnerability seekers) believe that the application processor is likely secure from the cell network. Doubly so because the entire history of their industry has been the exact opposite philosophy.
I have no doubt mobile chipsets contain a surprising amount of complexity. I'd love to be surprised by it! But I've only ever run across vague references to various improvements, which are worth just as much as saying "Our code uses AES!".
It's obviously easy to restrict a core to certain memory ranges. But how is that restriction set? Is it fixed in the mask (leading to inflexibility), or is it set through registers? The bullet point is enough to satisfy a PHB's sense of security, but we know it's the details of those loose ends where the exploits lie. And the threat model of Qualcomm is quite different from the threat model of a phone's owner.
Simplistic points like the OP are really a symptom of this not knowing. Can you blame them for not knowing the exact vulnerability? It's like someone picking on a binary blob, saying it can contain a backdoor password. Well, the industry having moved from backdoor passwords to challenge-response isn't really a defense to the overriding point, is it?
Rather than asking us to take this on faith, do you know of any resources where it's possible to learn about the technical details hidden "in the weeds"?
What I'm able to find looking around amounts to Apple verifying that the firmware loaded matches what's expected--but that's simply checking the binary, and doesn't give users any assurance whether that baseband enables backdoors or not. I didn't find anything about mitigations present in Android.
Articles like this one (http://mobile.osnews.com/story.php/27416/The_second_operatin...) indicate that it's pretty easy for an attacker running a cell tower (so, organized crime, or governments, or a blackhat with a few thousand bucks) to get code execution on (some) baseband processors. How do phone vendors mitigate this? My (admittedly pedestrian) knowledge of typical SoC setup makes it seem like that would be very difficult to do in software.
The way manufacturers "mitigate" baseband to main CPU compromise is by using a protocol that allows no initiation from the peripheral device (baseband). It can only talk to the main CPU via a serial-like protocol, not access its memory directly.
Other routes, such as side channel leakage or possible flaws in the main CPU software that interpret messages received from the baseband are still a potential source of problems, but there is no such DMA capability in the HSIC protocol.
It is valid to have general distrust and annoyance with the spy agencies for their actions to create backdoors. But there is no technical basis for this article's claims, and the author should retract them.
There's a difference between "what it does" and "what it can do" however. I mean, whatever well-defined interface is used, hardware design may leave other options open and unused.
Kind of like vmware provides nice interface for folder sharing, but in practice can just write directly to whatever files/memory they want.
It all depends on particular design. There are even some out there where baseband OS and Linux run under the same proprietary hypervisor. On modern phones it's pretty rare to be able to say with 100% certainty that the baseband OS doesn't have any access to user memory - and often you can say with 100% certainty that it can access other interesting stuff, like GPS or microphone, without any supervision from the user.
I think this is an instance where the truth is somewhere in the muddle. I'm sure there are engineers who care very much about securing cellular devices and making the attack surface as small as possible, probably working for Apple, Google, and perhaps for a few of those nation-state actors as well. I'm equally sure there are time crunched engineers who are more than happy to not go looking for problems when they have a piece of hardware that works (for their employer's intents and purposes), and that there are actors and entities out there who are dedicated to taking advantage of those insecurities.
However, that doesn't make for a very sexy headline.
Nice Freudian slip. "Muddle" to me sounded like one, probably because of its similarity to huddle, but a bit to my surprise it is a word, with an even more appropriate meaning "an untidy and disorganized state or collection."
As I understand the author, the implication is that the baseband firmware is closed source. So, it's possible that Google/Apple have done an audit. But, in my experience, and the author's suggestion that's unlikely to have happened.
I belive he is saying that the baseband code is closed source even to google and apple. Thats where much of he danager lies, it has exterordinary levels of access to tne device and there is no accountability for its security.
I think the author is radically oversimplifying the access the baseband has, based on the erroneous notion that the baseband in a phone design is connected in the same fashion as a peripheral is in a PC design --- hence the "IOMMU" bit.
I'd very much ask you to go into the weeds here, because right now basebands implement specifications that are diametrically opposed to any notion of security from the "application processors" and users perspective. They trust the network unconditionally.
The systems security of modern phones is surprisingly complex. Google and Apple both care very deeply about these problems, and both have extremely capable engineers working on them. Without getting too far into the weeds: they haven't ignored the baseband.