Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hardening cellular basebands in Android

security.googleblog.com

Post reply on HN
Print view View original

41–50 of 109 posts

Re: Hardening cellular basebands in Android

#41

Post by wtallis »

dwbehappy wrote: post #33
phh wrote: 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…

Not to take away from your excellent work, but what the hell is the point of VoWifi ? Why not just handle this with a well tuned user space app that runs on udp/whatever over any network connectivity you have already, whether it's wifi/cellular/pigeon carrier. It seems like its an entirely US-centric thing, motivated by a] cost savings from not using data on the cell network (not a problem for most of the world who h…

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.

Re: Hardening cellular basebands in Android

#42

Post by eightysixfour »

dwbehappy wrote: post #33
phh wrote: 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…

Not to take away from your excellent work, but what the hell is the point of VoWifi ? Why not just handle this with a well tuned user space app that runs on udp/whatever over any network connectivity you have already, whether it's wifi/cellular/pigeon carrier. It seems like its an entirely US-centric thing, motivated by a] cost savings from not using data on the cell network (not a problem for most of the world who h…

VoWifi is neither US centric nor purely about efficiency - it allows you to make calls with your phone to another phone via a third party network when you don’t have cellular connectivity.

For example if you have poor cell coverage at your home or office, you can still make and receive calls via a wifi connection using your phone number instead of forcing everyone to sign up for some third party service.

Re: Hardening cellular basebands in Android

#43

Post by alufers »

dwbehappy wrote: post #33
phh wrote: 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…

Not to take away from your excellent work, but what the hell is the point of VoWifi ? Why not just handle this with a well tuned user space app that runs on udp/whatever over any network connectivity you have already, whether it's wifi/cellular/pigeon carrier. It seems like its an entirely US-centric thing, motivated by a] cost savings from not using data on the cell network (not a problem for most of the world who h…

I used to live in an old apartment block with thick concrete walls, and away from a cellular base station. VoWifi was really helpful if I wanted to make calls from my home. I guess I could use WhatsApp/Facetime/Signal, but the insurance agent won't call me on WhatsApp from her landline phone :)

And it is not handled by an app on your phone, because of legacy reasons. I believe that, before LTE was introduced, 2G and 3G had a distinction between IP and voice traffic, so the baseband handled the voice transmission. Then they thought that LTE should be IP only and voice should be sent as VOIP over it, but it still had to be handled by the baseband for backwards compatibility with 2G and 3G. And then they came up with the idea that the VOIP traffic could also be piped over Wi-Fi (through the main processor of the phone), and so VoWi-Fi was created.

Re: Hardening cellular basebands in Android

#44

Post by ignoramous »

winter_blue wrote: post #36
acaloiar wrote: post #16

For those who don't eat and breathe this stuff, "basebands" are the processors that do all the cellular radio stuff on your smartphone. They're separate from device CPUs (referred to as the Application Processor), and are loaded with firmware. This post is about securing the firmware that runs on these little processors. When baseband firmware is compromised, it can lead to complete device compromise.

The device drivers for these baseband processors really should be run inside virtual machines. Most modern processors support IOMMUs [1], and assuming that (hopefully) modern cellphone processors have IOMMU support, the operating system should be updated to running device drivers in an isolated container or VM. With Linux not being a microkernel there’s a high likelihood the device driver expects to run in kernel mod…

Android has transitioned to secure DMA-BUF (after much controversy with ION), which more or less alleviates the need to use a mutually-untrusted VM (pKVM https://youtu.be/edqJSzsDRxk) for Baseband isolation?

Note though, OEMs are known to run 'device management' stuff with elevated privileges (not just the Baseband). Ex: see this write-up on Samsung RKP (realtime kernel protection): https://archive.is/6ClWm

As for 'drivers', the GPU drivers have also a viable attack vector: https://news.ycombinator.com/item?id=34490471

Re: Hardening cellular basebands in Android

#45

Post by gavinsyancey »

gruez wrote: post #32
ksjskskskkk wrote: post #20

Earlier quoted context omitted.

> , it can lead to complete device compromise. lile they had on the flagship pixels just 8mo ago. the csv google downgraded the severity because there was a work around of "disabling 5/4g" in a market that offset 3g. heh.

Source? If you're talking about this[1] from a few days ago, all the vulnerabilities were DoS (ie. they can crash your phone). Hardly "complete device compromise". [1] https://news.ycombinator.com/item?id=38567149

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.

Re: Hardening cellular basebands in Android

#46

Post by rollcat »

deepsun wrote: post #38
uncertainrhymes wrote: post #37

Earlier quoted context omitted.

This particular comment became the first Google search result (or 'featured snippet') for me for "What is Android Baseband" -- weirdly claiming to be posted four hours ago when this comment was two hours old. That is mindblowing to me. Full credit to the poster for becoming the canonical answer, but I'm not sure how I feel about Google picking comments without even some kind of page-rank-weighted attempt at deciding…

Google still employs a lot of manual page rankings.

Also probably enough Googlers just hanging out on HN.

Re: Hardening cellular basebands in Android

#47

Post by DiabloD3 »

abdullahkhalids wrote: post #40
DiabloD3 wrote: post #8

Earlier quoted context omitted.

It isn't about "sufficient contact". Google knows exactly who to call at any of these companies, and those people will pick up the phone when they see Google is the one calling. Qualcomm actively botches the security of their products as per request of many governments. The purpose of the letter is to openly shame these companies without directly accusing them of foul play, instead of gently painting them with the br…

What's stopping two trillion dollar corporations who assemble/build their own phones and phone OSes from designing/manufacturing their own secure baseband chip and getting it certified?

Qualcomm owns patents on an international standard.

They sued Apple and arguably won, although they settled out of court.

Apple had bought Intel's LTE unit and the patents that came with it, and Qualcomm and Intel both licensed patents into a common pool (and as such, any member of that pool did not owe any other member royalties); Apple inherited Intel's position in the pool and continued licensing patents to the pool with no change. Apple stopped paying Qualcomm the LTE blood money.

_Qualcomm still sued and made money_.

If Apple can't secure a win against Qualcomm, how the hell can Google?

Also, Qualcomm will _never_ license patents (under FRAND or otherwise) to competing vendors; the only way to be allowed to make LTE modems for the west is to be part of that pool.

Oh, and btw? Apple was making their (Intel-based) modem in-house for like two generations while that whole thing happened. They're back to buying Qualcomm modems again.

Re: Hardening cellular basebands in Android

#48

Post by csdvrx »

DiabloD3 wrote: post #35
csdvrx wrote: post #13

Earlier quoted context omitted.

> Until basebands are mandated to be FOSS for security and safety reasons, Google is just moving the chairs around on the deck of a sinking ship. I agree. I couldn't see much of a point in the techniques discussed when there's a huge elephant in the room, and you can't fix it, so I thought I was missing something obvious. I wasn't: it's just security theater, doing something for the sake of doing something, while the…

Arguably, any system that uses a Qualcomm SoC is not secure: either they do it on purpose, or they truly are incompetent, or it is a mix of both. No Qualcomm phone I've ever owned I've been truly happy with from the SoC SDK perspective (makes the job of community ROMs a thousand times harder). I do consider the Pinephone and Pinephone Pro secure, however. It doesn't use Qualcomm, and the broadband SoC is an isolated…

> I do consider the Pinephone and Pinephone Pro secure, however. It doesn't use Qualcomm, and the broadband SoC is an isolated part.

Good, I'll play with my pinephone then! I didn't want my efforts to be wasted if I discovered some horrible security hole that I would find as distracting as this obvious huge elephant in the room

> The only problem with Allwinner and Rockchip is they are both Chinese companies that may be tampered with by the Chinese government.

I do not believe this is a likely problem. And even if it was, "not for me": I already have a few eink android Chinese devices so I'd be toast anyway, so it shouldn't influence my decision.

> Qualcomm and Mediatek just have a record, today, of security flaw after security flaw.

I see that and I find it concerning, so I'd rather take my chances with something I can explore, see the flaws and limit them, than something that doesn't let me do that.

BTW I love how they are more flexible that US devices, letting me root and change their mtd content! Check the boox and bigme devices if you are interested in linux on baremetal color eink, yet with full control.

Re: Hardening cellular basebands in Android

#49

Post by lstodd »

eightysixfour wrote: post #42
dwbehappy wrote: post #33

Earlier quoted context omitted.

Not to take away from your excellent work, but what the hell is the point of VoWifi ? Why not just handle this with a well tuned user space app that runs on udp/whatever over any network connectivity you have already, whether it's wifi/cellular/pigeon carrier. It seems like its an entirely US-centric thing, motivated by a] cost savings from not using data on the cell network (not a problem for most of the world who h…

VoWifi is neither US centric nor purely about efficiency - it allows you to make calls with your phone to another phone via a third party network when you don’t have cellular connectivity. For example if you have poor cell coverage at your home or office, you can still make and receive calls via a wifi connection using your phone number instead of forcing everyone to sign up for some third party service.

Well, this sort of reinforces the point - there are about zero places in Europe where you have Wifi but do not have cheap almost-unlimited 4G/LTE. In fact it's wifi that's dying out here, the only thing that keeps it alive is that in a cafe setting it's still somewhat faster, and it eats a bit less battery.

Re: Hardening cellular basebands in Android

#50

Post by numpad0 »

phh wrote: 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'm just guessing here; but the reason why it's not implemented in userspace, not written in Rust, not using IOMMU, BP is allowed full DMA, the system is split into AP and BP in the first place, etc etc, is probably because of lags those stuffs introduce - difficulty of meeting and maintaining required realtime constraints.

ALL of those desktop-derived event driven technologies, with deep call stacks and abusive use of interrupts, tend to run NOT like a marathon runner, but like an attention deficit man, and the latter is how you get choppy audio.

IIUC, Nokia in '00s already used an architecture that baseband OS and application OS(Symbian) would run on the same CPU, with RTOS below the application OS forcing regular switch to baseband or something, because baseband code is synchronized to physical IRL time, managing physical phenomena, and the user, can wait.

If anyone's going to move phone signaling and audio processing to AP, they'll have to first show the embedded guys that their fancy stuff is better than the existing realtime stuff, and is not an elaborate prank. Which, I think, isn't easy. I mean, one of news for Raspberry Pi 5 was addition of a programmable I/O processor for realtime/low-level tasks, not removal of.

Post reply on HN