Live data from Hacker News

Hardening cellular basebands in Android

security.googleblog.com

101–109 of 109 posts

Re: Hardening cellular basebands in Android

#101
post #89

Earlier quoted context omitted.

> the latter is how you get choppy audio Tell me, if Discord can stream high-quality audio in real-time, what makes a phone call that much harder to handle, especially given how awful the sample rate is? Shouldn't an 8-bit micro from the 80s be able to handle that? Aren't there even already pieces of homebrew software for those micros that can handle audio of that quality?

For me it feels just wrong? Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low level? Think anything space, aviation or automotive. If your remedy to writing bad software is "just put it into a sandbox", then who says that sandbox isn't bad software as well? So now you got bad software in a sandbox that may or may not be safe and is less…

It's just as much software engineering as it is "politics". Baseband vendors could put in as much effort as aviation manufacturers, but they won't. The status quo of overcomplicated, insecure, buggy software is hard to change. So the only tenable approach is one that relies as little on baseband vendors cooperating.

Re: Hardening cellular basebands in Android

#102
post #89

Earlier quoted context omitted.

> the latter is how you get choppy audio Tell me, if Discord can stream high-quality audio in real-time, what makes a phone call that much harder to handle, especially given how awful the sample rate is? Shouldn't an 8-bit micro from the 80s be able to handle that? Aren't there even already pieces of homebrew software for those micros that can handle audio of that quality?

For me it feels just wrong? Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low level? Think anything space, aviation or automotive. If your remedy to writing bad software is "just put it into a sandbox", then who says that sandbox isn't bad software as well? So now you got bad software in a sandbox that may or may not be safe and is less…

> Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low level?

Why would we sandbox code against vulnerabilities rather than simply writing code without vulnerabilities? Because writing code without vulnerabilities is not possible to achieve 100% of the time.

I love Rust as much as the next guy, but you need to know how to use it, too. We're back to "just do it perfectly" again: write perfect code, using perfect languages with perfect compilers. In order to know how to do that, hire perfect employees. In order to hire perfect employees, you need a perfect interview process, etc. I'm sure this would be easy in a perfect world.

But do you have any idea how unrealistic this prospect is? About why you can't just place your trust in being able to write perfect code that has no bugs, and about why defense in depth is so important?

If you have no sandbox, you have to write code that contains zero vulnerabilities. If you cannot perfectly guarantee the complete absence of bugs, you cannot perfectly guarantee that your code contains zero vulnerabilities.

Re: Hardening cellular basebands in Android

#103
post #62
post #58

Earlier quoted context omitted.

Europe is approximately 7% of the land surface area of the world. We don't all live in small, densely populated places :)

And US is 6.1% Your point?

My point is exactly what I said. There are lots of parts of the world where mobile service is not good (or available at all) because it's not economically sensible to build out coverage where populations are very low.

You wrote "there are about zero places in Europe where you have Wifi but do not have cheap almost-unlimited 4G/LTE" on a site with a global audience.

Re: Hardening cellular basebands in Android

#104
post #22
post #18

Earlier quoted context omitted.

It can but doesn't necessarily, right? There's a variety of interconnect and IOMMU architectures here, so it's not a given that a baseband processor has or is one step away from unrestricted access to the whole platform.

it can't and it shouldn't IF IOMMUs were properly used

Indeed, hardware security building blocks are just that, necessary but not sufficient. Eg Unix and Windows took a very long time from "we have hardware MMU and are using it for some stuff" to "we have a real world tried and tested, somewhat working multiuser security separation".

Re: Hardening cellular basebands in Android

#105

Earlier quoted context omitted.

Probably this one, from March: https://googleprojectzero.blogspot.com/2023/03/multiple-inte... > The four most severe of these eighteen vulnerabilities ... allowed for Internet-to-baseband remote code execution Affected the Pixel 6 and 7, among other devices.

yeah. and the fix came on the system wide update. which does not touch the modem firmware. so they fixed the root from modem to phone end point. not the modem problem. also, it was the first update to be delayed over 40days from the usual calendar. because the issue was seen in the wild a week before the release date so they scrambled to include a patch and delayed everything

Are you sure this didn't update the modem?

Re: Hardening cellular basebands in Android

#106
post #41

Earlier quoted context omitted.

WhatsApp, FaceTime, etc. all require both endpoints of a call to use that app. VoWiFi lets you receive calls to your regular phone number from any normal phone. The fact that the last mile of the call is being carried over WiFi becomes an invisible implementation detail.

The phones could just use the SIP protocol for voice. You don't need an accompanying chat app. The huge disadvantage of that is that the customer could then use any VOIP supplier for their phone calls. ... or none at all for SIP to SIP calls. That would create a competitive market in voice. A competitive market is the last thing any cell phone provider wants. They need to maintain their monopoly on the last mile conn…

VoLTE is literally SIP + IPSec + auth with SIM card (+ some pretty usual SIP optional extensions marked as required)

Re: Hardening cellular basebands in Android

#107
post #103
post #62

Earlier quoted context omitted.

And US is 6.1% Your point?

My point is exactly what I said. There are lots of parts of the world where mobile service is not good (or available at all) because it's not economically sensible to build out coverage where populations are very low. You wrote "there are about zero places in Europe where you have Wifi but do not have cheap almost-unlimited 4G/LTE" on a site with a global audience.

And even where the connectivity is there, the "cheap almost-unlimited" bit might not necessarily be true – that, too, significantly varies from country to country.

Re: Hardening cellular basebands in Android

#108
post #17
post #11

Earlier quoted context omitted.

> Qualcomm actively botches the security of their products as per request of many governments. Interesting, I was not aware that's what they're doing. Is there evidence of this?

I doubt there's publicly available evidence. Assuming incompetence before malice, I'd say that Qualcomm and the other 5G baseband manufacturers have such a moat around cellular modems that it doesn't need to be secure. It's not a competitive advantage. A security critical application simply assumes that the network and the 5G baseband are compromised.

I have no idea how the bugs ends up where they end up.

I remember a pretty egregious mis-implementation in a qualcomm rsa encryption module many startups ago when I was using that, I never heard back about the bug report.

That was over a decade ago so surely it's fixed by now I guess. I guess?

Re: Hardening cellular basebands in Android

#109
post #26

I'd rather say the issue is NOT that basebands need hardening (ok they do need it), but that we should stop putting things there. The article mentions parsing XML, doing DNS, IMS, TCP and IP stacks. As far as I know, all of those are down for one single purpose which is VoLTE (And VoWifi, and other related features which all go under the umbrella of "IMS"). On top of that, they also need to do IPSec (should be pretty…

I've played with doubango for some time trying to get it to work against the flavor of IMS used in VoLTE / VoWiFi, and it is not all that close to it, even with various hacks applied from https://gitea.osmocom.org/ims-volte-vowifi/doubango/commits/... in which I tried to add a Linux kernel IPsec plugin as well as various other bits and pieces.
Post reply on HN