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

31–40 of 109 posts

Re: Hardening cellular basebands in Android

#31

Post by phh »

mschuster91 wrote: post #27

Anyone surprised by basebands being vulnerable should know these things: - there are only three big players in town: Qualcomm, Mediatek and Samsung, and the latter is pretty rare to find outside of Samsung's own devices and the Google Pixel lineup (where they also have been implicated in security [4] and battery performance [5] issues) - Qualcomm is infamous for suing anyone including Apple for patents crap, which is…

> - there are only three big players in town: Qualcomm, Mediatek and Samsung, and the latter is pretty rare to find outside of Samsung's own devices

For basebands yes. I'll complete this for a quick overview for IMS/VoLTE, which is often in baseband, but not always. (And VoLTE is at least partly what the article is about, and the last public Pixel remote flaw was caused by VoLTE)

Just to give a quick approximate overlook:

- If you're on a Verizon-branded device, Verizon probably made their own IMS implementation mandatory [1]

- If you're on a Samsung or LGE-branded device (no matter the SoC), they use their own IMS implementation [1]

- If you're using a non-Samsung-branded Samsung Silicon device (=SLSI: Pixels, Moto One Action and few others), they use a different IMS implementation than the IMS Samsung uses in their smartphones

- In other cases, you're indeed likely using the IMS/VoLTE implementation provided by the baseband/SoC vendor

As far as I know, the implementations I've marked with [1] are at least partially [2] done in userland in application processor rather than in modem, but it's hard understanding really. The ones that are not marked with [1] are in modem afaik.

[2] Partially meaning the annoying protocol stuff, but audio encoding/decoding + RTP encapsulation might remain in hardware

Re: Hardening cellular basebands in Android

#32

Post by gruez »

ksjskskskkk wrote: post #20
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.

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

Re: Hardening cellular basebands in Android

#33

Post by dwbehappy »

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 have unlimited data plans cheap enough for everyone to afford) and b] some kind of vendor feature contest/lock-in type incentives.

What is the selling point of it, I don't get it. WhatsApp/Facetime/Signal or similar voice calls are not perfect, they obviously do introduce some extra latency and inefficiencies compared to using that lower level data pipe, but it just strikes me as a very strange avenue for people to be going down with very marginal benefit (efficiency) but a ton of extra work.

EDIT: Btw if its not clear, I fully agree with you that it, whatever it is, should be in userspace as much as possible, and as an open standard, I'm just trying to figure out why this stuff has been introduced in this way at all.

Re: Hardening cellular basebands in Android

#34

Post by danielheath »

vlovich123 wrote: post #24
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.

> When baseband firmware is compromised, it can lead to complete device compromise. I believe that’s generally only still true for Android and fixing that is what this is talking about. I don’t actually know but I recall when I worked at Apple many years ago that the baseband was firewalled already for this exact reason. Edit: can’t find any reports of a baseband compromise for iPhones although I wouldn’t rely on a 3…

There have been, but iPhones all have the baseband connected via an MMU, so even if you get code execution it's hard to exploit usefully (you can see/modify packets, but nearly everything is encrypted these days).

Some android manufacturers also have an MMU but others connect the baseband directly to main memory, leading to total device takeover when the baseband is compromised.

Re: Hardening cellular basebands in Android

#35

Post by DiabloD3 »

csdvrx wrote: post #13
DiabloD3 wrote: post #7

Earlier quoted context omitted.

The problem is it isn't "Android baseband", it doesn't run on the CPU that Android does at al. Instead, an entire second whole computer (not even a "microcontroller", in many cases they are just as powerful per-core as your real CPU) that runs a closed source realtime OS that Google (et al.) has zero visibility into. Some phones straight up admit the baseband is actively hostile and only communicates with it via seri…

> 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 part. Allwinner and Rockchip do not have the security nightmare track record that Qualcomm does. They also ship with Postmarket instead of an Android that isn't security focused, which is nice.

The only problem with Allwinner and Rockchip is they are both Chinese companies that may be tampered with by the Chinese government. Qualcomm and Mediatek just have a record, today, of security flaw after security flaw.

The new Samsung-made SoCs in the new Pixels are also an interesting choice. They do not use the Samsung TPM, instead opting for Google's newest version of the Titan TPM. Shortly after the Pixel 6 came out, Google Project Zero issued a story about the Samsung TPM having security issues. Hmmmmmmmmmmmmmmmmmmmmmmmmm.

Re: Hardening cellular basebands in Android

#36

Post by winter_blue »

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 mode. We probably will need to have a little a Linux VM containing the driver, and create a system that propagates its I/O back to the host. It’s a lot of overhead, but I’m not sure if there any other way of ensuring secure device drivers on Linux.

[1] Ancient device drivers expected full unrestricted DMA, i.e. full unlimited read/write access to RAM. But IOMMUs (VT-d on Intel) let us pretend to give such device drivers full DMA while isolating them.

Re: Hardening cellular basebands in Android

#37

Post by uncertainrhymes »

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.

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 what is 'best'.

Re: Hardening cellular basebands in Android

#38

Post by deepsun »

uncertainrhymes wrote: post #37
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.

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.

Re: Hardening cellular basebands in Android

#39

Post by iforgotpassword »

danielheath wrote: post #34
vlovich123 wrote: post #24

Earlier quoted context omitted.

> When baseband firmware is compromised, it can lead to complete device compromise. I believe that’s generally only still true for Android and fixing that is what this is talking about. I don’t actually know but I recall when I worked at Apple many years ago that the baseband was firewalled already for this exact reason. Edit: can’t find any reports of a baseband compromise for iPhones although I wouldn’t rely on a 3…

There have been, but iPhones all have the baseband connected via an MMU, so even if you get code execution it's hard to exploit usefully (you can see/modify packets, but nearly everything is encrypted these days). Some android manufacturers also have an MMU but others connect the baseband directly to main memory, leading to total device takeover when the baseband is compromised.

I can't find any trace of this with a quick Google search, but I'm super sure I read about the very first iPhones having the baseband module talk to the soc via USB as an isolation measure, since USB didn't have DMA or anything "dangerous". Anybody else heard that, or am I hallucinating?

Re: Hardening cellular basebands in Android

#40

Post by abdullahkhalids »

DiabloD3 wrote: post #8
xiipie wrote: post #4

All good points, but why write this in an 'open letter' style to unnamed baseband vendors? Does Google not have sufficient contact with key decision makers at Qualcomm, MediaTek, Samsung, etc. to encourage them to improve the the security of their baseband firmware? Those are the people who really need to be convinced.

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?
Post reply on HN