Live data from Hacker News

There are no secure smartphones

devever.net

71–80 of 124 posts

Re: There are no secure smartphones

#71

Earlier quoted context omitted.

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. https://www.synopsys.com/dw/dwtb.php?a=hsic_usb2_device 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…

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…

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.

Re: There are no secure smartphones

#72
Based on what I've read from more authoritative sources (or is the author an authority in this area?), this information is outdated:

> It can be safely assumed that this baseband is highly insecure. It is closed source and probably not audited at all. My understanding is that the genesis of modern baseband firmware is a development effort for GSM basebands dating back to the 1990s during which the importance of secure software development practices were not apparent. In other words, and my understanding is that this is borne out by research, this firmware tends to be extremely insecure and probably has numerous remote code execution vulnerabilities.

I've read in several places that basebands now widely use the OKL4 microvisor,[1] based on the formally verified (fwiw) seL4 microkernel, and are much more secure than before. Does anyone know more about this?

[1] https://gdmissionsystems.com/cyber/products/trusted-computin...

Re: There are no secure smartphones

#73
post #8
post #4

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 engine…

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…

For one example, see the Android kernel for Qualcomm HSIC baseband interface (baseband-qct-mdm-hsic.c)

https://git.sphere.ly/Lloir/android_kernel_htc_evitareul/tre...

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.

Re: There are no secure smartphones

#74
post #68

This is just a special case of the fact that there's no secure anything. In 2016 that's just the price you pay for using computers. You just have to live with it. Mitigate it the best you can, rely on the ol' "mossad or not mossad" strategy now and then, hope for the best, etc. If you have a strong need for increased security, well, god help you (spoilers: you will receive no help), you're going to pump a lot of effo…

Just get an FSF laptop for security. You can even trust the hard drive if you use software encryption of all your data. I'm not sure what remains insecure on that class of hardware?

They have a better story about firmware than other devices, but they're still running Linux and GNU software, which often has remotely exploitable vulnerabilities. Just today OpenSSH (which is neither Linux nor GNU but which you would obviously use on your FSF laptop) announced an extraordinarily serious remotely exploitable vulnerability. That's presumably not the last vulnerability of that severity in an operating system you install today onto your FSF laptop.

It's not obvious that FDE will totally mitigate hard drive firmware attacks because your boot loader and kernel are likely running from an unauthenticated partition (for instance, most Linux-based systems with LUKS today have all of /boot on a separate non-LUKS partition, and something like a GRUB boot sector too). If the hard drive understood how to recognize the kernel in /boot, it could inject a vulnerability into it. In a few presentations a couple of years ago, I walked through a real example of how a single bit flip in a binary can introduce (or re-introduce) a fencepost error that can compromise security, because the opcodes for extremely similar yet different conditional branches often differ by a single bit. One form of the conditional branch like jump-if-less may be the correct invariant, while another form like jump-if-less-or-equal may be the exploitable erroneous form of the same loop.

I'm not knocking people's work on trying to get a handle on what firmware is running on their devices; I think that work is great. The trouble is that attackers are looking for exploits and persistence in every layer of the system, so you won't get a silver bullet against all attacks by shoring up one aspect.

Good stuff on this: Halvar Flake's "Why Johnny Can't Tell if He is Compromised", and Joanna Rutkowska's recent CCC presentation on persistent state.

Re: There are no secure smartphones

#75
post #13

Earlier quoted context omitted.

> 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…

"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 c…

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.

Re: There are no secure smartphones

#76
post #13
post #3

The folks at http://neo900.org/ are well aware of this and that phone is designed accordingly (details at http://neo900.org/faq#privacy ). Hype-driven products like BlackPhone misrepresent their devices as being perfectly secure when this significant attack vector is completely unmitigated. On the Neo900, the modem is connected via USB (bus; there is no physical connector) which means it doesn't have DMA. There is no…

> 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…

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.

Re: There are no secure smartphones

#77

Earlier quoted context omitted.

"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 c…

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 initia…

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.

Re: There are no secure smartphones

#78
post #58
post #22

Earlier quoted context omitted.

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. 0: https://www.fsf.org/blogs/community/replicant-developers-fin... 1: ht…

I don't think you should trust the baseband. 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.

Re: There are no secure smartphones

#79

Earlier quoted context omitted.

"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 c…

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 initia…

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.

Re: There are no secure smartphones

#80
Don't modern ARM chips encrypt memory (for DRM reasons)? If that's in use (modulo the area the the baseband needs to read/write), it doesn't matter. An adversary can read the memory, but can't read the encryption key out of the CPU.

If it could, anyone with a logic probe could grab un-DRM'd video data out of the RAM, which would make many people very unhappy.

Post reply on HN