Hardening cellular basebands in Android | Hacker News Reader

Hardening cellular basebands in Android

security.googleblog.com

219 pointsel_duderino103 comments

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 how this oligopoly formed in the first place, and why there's barely any competition

- It's not the first time serious vulnerabilities have appeared in baseband chips [1]

- and finally, to a possible cause, Qualcomm's development practices [2] are even worse than what's reported about Oracle [3], if these (anonymous) HN comments are to be believed.

[1] https://www.bleepingcomputer.com/news/security/qualcomm-vuln...

[2] https://news.ycombinator.com/item?id=38607205

[3] https://news.ycombinator.com/item?id=18442941

[4] https://www.notebookcheck.com/Google-warnt-vor-massiven-Sich...

[5] https://www.nextpit.com/google-pixel-8-pro-5g-modem-battery-...

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

The ASAN etc. are nice suggestions for parsing the OTA messages delivered over a link. It really mattered with serial links

But if there's a CPU, and the link has access to the IO space, I'd prefer to first have IOMMU to avoid giving too much trust to the baseband: a takeover or exploit of whatever's parsing the messages would then be a lesser concern.

Most 4G/5G modems are connected straight to the PCI bus and I believe that's far more unsafe: with no IOMMU, in case of a baseband takeover, it's game over.

Old serial ports on well-known IO (ex: COM1 0x03f8, COM2 0x02f8) seem to have provided a natural checkpoint and chokepoints.

Or am I missing something obvious?

Take a few steps back, the obvious problem is that all phones are chock full of mysterious black boxes that the owner of the device has zero say over.

Android has the problem of being too open to prevent backwards implementations and shitty, vulnerable, and bug prone code, but not open enough for anyone with the incentive to fix those issues to actually be allowed to fix them.

I see the eventualities to be either Google locks down android significantly, and the market shifts to something more akin to Nvidia's board partner model, or, it opens way up, and device manufacturers open source their implementations of various system devices in order to crowd source fixes/improvements/etc. The former is much more likely than the latter, but, as a consumer, the latter would be preferable.

At least modern Google Pixel phones have an IOMMU (https://grapheneos.org/faq#baseband-isolation)

> A component being on a separate chip is orthogonal to whether it's isolated. In order to be isolated, the drivers need to treat it as untrusted. If it has DMA access, that needs to be contained via IOMMU and the driver needs to treat the shared memory as untrusted, as it would do with data received another way

YES!

It's actually strictly worse: even if they had an IOMMU and the drivers were implemented correctly, phone vendors provide remote access tools as part of their firmware stack (e.g., see https://www.fsf.org/blogs/community/replicant-developers-fin...). To reiterate one of the other commenters, as long as users don't control what code runs on the baseband, they do not in fact have ownership of the device. The same holds for anything else that has a baseband (such as most modern cars). This sentiment is publicly communicated by telco's and manufacturers and convenient for regulators.

That's true, but as long as the baseband doesn't have access to the rest of the device, there is at least a limit to how much damage it can do, which is a good incremental step. If it can't exploit the OS, then worst case, it has access to network traffic (just like the next router in the chain, which is why all the traffic should be encrypted), and it has the ability to help locate the device against the user's wishes (but so do the cell towers).

Rewriting baseband firmware is also a great opportunity to make it Open Source, and I hope that happens as well.

It looks like https://osmocom.org/projects/baseband is still somewhat active.. they mainly develop for the TI Calypso (Motorola C123 and some others). My understanding is that all "modern" (meaning 3G and up) modems are basically sealed black boxes.

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 safe) and SIP (gosh wait too much string handling). The remote Pixel security flaw few months ago was in that VoLTE stack.

This stack should NOT be in an embedded closed source un-auditable system. It should be in a "dumb" sandboxed opensource app in a sandboxed language.

This is exactly what I'm doing: https://github.com/phhusson/ims This is a FLOSS VoLTE + VoWifi[1] implementation for Android written in kotlin with no native code [2].

I'm not recommending it for anyone (I managed to make my first outgoing call with it yesterday), it has real issues (you do want baseband cooperation on various parts, like QoS or roaming to 3G, which I'm choosing to ignore), but I think software IMS is the way of the future.

In addition to security, this allows for a lot of de-obsoleting:

- It helps *a lot* for custom Android ROMs, and compatibility with annoying carriers

- I can integrate top-notch audio codecs (EVS) without breaking a sweat, and deployed for everyone in a jiffy (heck I don't even to reboot user's smartphone's to apply the change, I can just deploy it over Play Store)

- I can integrate modern voice improvements

- I can enable VoWifi on 3G smartphones (Granted, I'm not sure that's extremely useful)

- I can enable features that didn't exist when that smartphone model got released like Cross-Sim VoWifi (you have your french main SIM, you're in the US with a local eSIM, you can do VoWifi of the french SIM over the local eSIM to have cheap 4G voice calls)

I see some movement in AOSP source code that make me think Google will release an opensource IMS within two years, so I'm hopeful my work will be able to go to the trash.

[1] I'm kinda cheating for the wifi part, because it's provided by AOSP, I barely lifted the little finger to enable it. [2] Okay, I added rnnoise for the sake of having a denoising, but it's fixed-size-data-in fixed-size-data-out, so I feel safe there.

PS: I know that my knowledge of 3GPP is pretty thin, so if knowledgeable people want to tell me which parts will still need to remain in modem, I'm curious.

PS2: I'm putting this just in case: For GNU/Linux smartphones (or desktops with SIM card reader), you should be able to use that C+py stack to have userspace vowifi: https://github.com/phhusson/doubango

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.

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 connection.

This might be an interesting idea for a government interested in improving this particular market. Forbid the provision of anything but reasonable latency data by a last mile provider. Establish standards.

I note that jmp.chat, a provider of SMS and voice over internet connections, is toying with the idea of providing, pay as you go, data only plans as a complement to their primary service.

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

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.

I’m not sure we are talking about the same thing - just because you have cheap unlimited 4G doesn’t mean you get that 4G signal in a basement. VoWifi lets you still call someone with your phone number when the signal is bad but you have wifi access…

I was never into insisting to only talk on the phone from the basement of my medieval castle. The view from the battlements is much better.

We're not all jamesbondesque supervillains here.

Like I said above, for like $8/mo you have in fact unlimited 4G at decent speeds here. Or for idk maybe $15 you can get a gpon, unlimited traffic, 30+Mbit to the house, depending on local laziness of course. And that is for a rural place in Balkans, not something in more civilized places.

Yes, and VoWifi lets your cell phone make a call over that fiber when your wireless coverage isn’t great. Not really sure where castles and battlements come to play here - there are plenty of completely normal places people visit with connectivity issues.

Maybe it is your experience in the rural balkans, where cellular congestion and significant building density aren’t factors, and your assumption it must be better in “civilized” places that is confusing the issue…

I just got back from a week in Paris where I frequently had limited cell service indoors on a major provider. Even with antennas all over there’s just a lot of masonry for signals to get through.

I’ve been really happy on many occasions to have Wifi calling, both where I live in NYC (where service sometimes behaves similarly to Paris) and the rural places I visit frequently (where having the cellular modem off while at home saves tons of battery vs constantly having no service).

I do love how, seemingly to counteract the US-centric nature of many discussions, some Europeans act as though Europe is this one homogeneous block where everything works the same everywhere.

I guarantee you there are quite a few people in various countries in Europe where they don't have great cellular coverage, whether because of their location, or because of the building materials used in whatever house or office building they spend a lot of time in.

Regardless, I don't really get the hate toward VoWifi. Like... it's an added option. In some cases it might be redundant (or worse than the normal VoLTE option), but... it's an added option, that you don't have to use, that can be a great fallback in some cases.

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?

Would you describe the entirety of the US as “densely populated”?

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.

That's not quite true. There are older buildings with brick walls that have bad cellular reception.

Conversely, some high rises have a too _good_ reception and the radio spectrum can get congested.

Where it does matter they put a femtocell which is about as complicated as a wifi AP.

I live in the UK and pretty much rely on VoWifi to make/receive calls when at home. I can also think of a few places within an hours drive where my reception drops to “No Service”.

You are completely wrong in your assertions.

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.

I think it was lots of parallel development - some mid-to-late 3G phones had carrier hand-rolled Wi-Fi calling, some had femtocell support instead, LTE was to be just faster packet-only Internet mode for 3G, became its own thing too late which necessitated CSFB, and then Wi-Fi calling became reimplemented as part of standard, etc.

> I guess I could use WhatsApp/Facetime/Signal, but the insurance agent won't call me on WhatsApp from her landline phone

Huh. I would expect that it's more common for the insurance agent to have WhatsApp (or equivalent) as the only option than it is for them to refuse to use it in favor of the telephone network.

I think your concerns are misplaced.

Things like TCP/IP and DNS are child’s play compared to the complexity of cellular baseband firmware — even for just a single 2G/3G/4G standard.

The SIM card layer is also another nightmare in itself.

I can make "regular" phone calls when on a different continent and on WiFi without paying any roaming fees.

> Not to take away from your excellent work, but what the hell is the point of VoWifi ?

The point is that your phone should continue to work even if you are deep inside a building without coverage. Or that you should have connectivity if you for some other reason have good wifi coverage but bad cellular.

Now, the protocol choices I won't defend, it is layers upon layers of complexity that I don't know enough to understand what is motivated or what is bad.

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.

> 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 performant than the low level variant. Maybe the software is bad in a kind that allows abuse despite the sandbox, congrats now your baseband lies to you.

The solution I like is to use strictly typed languages, formaly verified compliers, a ton of tests and fuzzing and above all: avoiding unnecessary complexity. Embedded programming sucks, but we have Ada, we have Rust and we have a chance to do things that are both safe and performant.

Nobody is attacking interfaces of plane SBCs the way mobile basebands are being attacked out in the wild. They defensive architecting and programming for aerospace most often is entirely different from the defensive programming of things that have to contend with malicious input.

> when we obviously know how to write safe software in other spaces in the low level? Think anything space, aviation or automotive.

I seriously doubt that those software is near any levels of safe. They are just not attacked as often.

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

Chromium has high quality coding, but they still sandbox their own code whenever they can. Security vulnerability results from the limit of humanity, so it cannot be eliminated by just willpower.

And to answer your question directly,

* Writing a sandbox is easier to get right than many other software. * Even if the sandbox itself is badly written and therefore has vulnerability, it must be combined with the vulnerability of the software it protects in order to achieve any attack. So sandboxing something always increase the difficulty of attackers and is a worthy investment from the viewpoint of security.

> The solution I like is to use strictly typed languages, formaly verified compliers, a ton of tests and fuzzing and above all: avoiding unnecessary complexity.

The relationship between these and sandboxing is not exclusive. One can and should do both of them.

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.

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

> is probably because of lags those stuffs introduce

There is likely some truth to this, but I think the bigger reason for these things is that Qualcomm can't be arsed.

There are two lags to take into account. Lags at connection, and lags during the call.

Connection is what is very complicated to do safely, but once its setup, except for some signaling, it is much simpler [1].

The architecture used by some people (I wouldn't know exactly who does what, it's all muddy) is that the connection/signaling is done in application processor, but the Encoding/Decoding + RTP is done in baseband processor. You do get a bit of additional of lag at connection (but anyway you have an UI to show), but you can keep your real time audio guarantees.

[1] That's for volte. For vowifi, that's more complicated, but anyway talking about lags over wifi...

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

That doesn't seem likely. All those technologies (except userspace maybe) work fine for realtime constrains down to microseconds. If your constraints are in the nanoseconds (wireless signal processing stuff?) you probably have to use some local SRAM anyway and thus not need to touch the system memory.

Hey, that looks really cool. I've been wanting to mess around with this stuff on PinePhone, which is in a unique position here since there are third-party images for the baseband which are mostly open source[1].

I've been especially interested in trying to reverse engineer what's going on with Google Fi on Android, but it is definitely a bit over my head, given that until recently I didn't even really know what an AT command was :) I'm guessing since it's Google the carrier stuff is mostly for fallback and all of the actually interesting stuff is done using protobufs over a data connection. (Fi is also interesting because you can make phone calls on the web over WebRTC. I wonder if that's some kind of gateway to SIP, or what.)

[1]: https://github.com/the-modem-distro/pinephone_modem_sdk

(Note: I didn't dig deep enough, so it wouldn't surprise me if the blobs in this are actually where the interesting stuff happens, but it's still probably a great base for experimentation nonetheless.)

The PinePhone uses a really old, slow modem (the Quectel EG25). Why not get a modern Snapdragon x62 like the RM520, drop it in a carrier board, root the modem and do all the shenanigans you want?

Useful links: https://github.com/natecarlson/quectel-rgmii-configuration-n...

https://github.com/carp4/qadbkey-unlock

Because you can't use a Snapdragon in that way, that's not how Qualcomm's business works. There's a reason that very few (or no) "open" phones actually use Snapdragons and it's because it's impossible to obtain the firmware for these without layers of very restrictive contracts and NDAs. They're almost like NXP in that way.

That looks great! I have a pixel 4xl that will not allow enabling VoWifi. (Maybe old sim card, maybe Graphene.) As you mentioned, great for other builds. PinePhone, etc. Going to try...

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.

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

If I can put my paranoia cap on for a moment. The baseband processor having privileged access to the main processor may be a "feature" not a bug. It's a powerful processor, that is running constantly, has unlimited and continuous inscrutable communication with the network, is the gatekeeper for the main processors communication with the network, and it's firmware is practically required by regulations to be an opaque blob. Seems to be pretty much the ideal place for nefarious deeds.

> The baseband processor having privileged access to the main processor may be a "feature" not a bug

yes but iff with the qualifier of "in old systems, where permissions were a tree-like state where root/uid0 could see what unpriviledged users would do - by design"

It's a dated design. More separation is needed, like what was achieved for virtualization or containers (namespaces)

> it's firmware is practically required by regulations to be an opaque blob

That's another problem, but I think it also comes from thinking in a tree-like state system.

Ideally, a device shouldn't be able to take down a well designed network: if you plug a bad appliance in your AC, it will not crash the power grub: it'll just trip a fuse.

I don't disagree with any of that. My point being that the people with the power to make the change have no desire too.

I'm not sure what you're talking about, because the modern flagship phones all have the architecture you're saying they should have but don't because of the "people with the power".

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".

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

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?

the other commenter found the right source. but also, remember all DoS wich corrupt memory ARE complete compromise. the original researcher just gave up before they found how.

baffles me that people here fall for this simplistic excuse of "it just corrupt memory"

or things like "the modem is isolated from the phone". sigh. how do you think they configure your phone via a text message? the protocol is safe but the payload is crazy powerful and trivial to abuse.

no phone expects the modem to be an adversary. and every modem firmware is wide open. everyone just pretend it's not and hope the NDAs will work keeping the modem security holes from falling into the wrong hands. heh.

> 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 30 second DuckDuckGo search to state something definitively.

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?

USB? Not UART serial? It seemed a lot of early smartphones did have the modem over AT commands through serial port, like good old DOS computers.

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.

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

It's usually Linux that gets isolated by classical(not like modern VMM) monitor and kept away from baseband, not the other way around.

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'.

Google still employs a lot of manual page rankings.

Also probably enough Googlers just hanging out on HN.

Yikes. Google put my grug brain [1] synopsis on full display?

Google, please use less grug brained explanation of baseband processors [2]. ty

[1] https://grugbrain.dev/

[2] https://en.wikipedia.org/wiki/Baseband_processor

For me, googles 'featured snippet' for 'What is Android Baseband' is extracted from the almost unreadable https://www.mi.com/global/support/faq/details/KA-11986/

I think the parent comment is almost more informative.

FastGPT from Kagi answers to this question:

"Baseband is the firmware that controls the cellular radio functions of an Android device. It is responsible for things like connecting to mobile networks, making phone calls, and sending/receiving SMS messages. [1][2]

The baseband firmware resides on the same storage (eMMC) as the Android operating system but runs independently on a separate baseband processor. It communicates with the Android OS through shared memory and AT commands. [3][4]

Baseband versions are different from Android build numbers. The baseband version refers specifically to the firmware running the cellular radio hardware. [5]

Baseband firmware has been found to contain vulnerabilities that could allow remote command execution if exploited. However, Android devices from reputable manufacturers like Google/Pixel generally receive frequent baseband updates to address such issues. [6][7][8]"

[1] https://www.quora.com/What-do-baseband-version-and-kernel-ve...

[2] https://www.reddit.com/r/AndroidQuestions/comments/1wzmp7/wh...

[3] https://android.stackexchange.com/questions/219230/where-is-...

[4] https://stackoverflow.com/questions/24569075/how-mobile-os-t...

[5] https://forums.androidcentral.com/threads/difference-between...

[6] https://techcrunch.com/2019/11/08/android-baseband-flaws/

[7] https://www.reddit.com/r/GrapheneOS/comments/11op7yz/remote_...

[8] https://news.ycombinator.com/item?id=38616922

And the last link is this hackernews post!

Is there any way to isolate or sandbox it, so that the rest of the phone/device is not compromised?

Guessing the Tensor G1..3 based Android phones are not affected by 5Ghoul? https://asset-group.github.io/disclosures/5ghoul/

it probably is, but you won't get the usual academic work for free as you get with more common platforms.

The Pixel lineup uses Samsung modems.

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 brush of mere incompetence, mere lack of knowledge how modern tooling works.

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

> Assuming incompetence before malice

You may be on the right track here. It's just one anonymous HN comment [1], but it fits other pieces (e.g. BSP code dump quality).

The sad thing is, there is no competition where one could go to - it's either Mediatek who have serious issues of their own, or Samsung who mostly stick to themselves.

[1] https://news.ycombinator.com/item?id=38607205

> BSP code dump quality

I know they're proprietary, but got any more info on this? Would be super interesting.

Mobile standards themselves are largely driven by groups like 3GPP in order to hopefully skirt around oligopolies like Qualcomm who intentionally patent the entire superset of the Latin alphabet in order to sue anyone with a heartbeat.

So, security itself is driven by third party organization(s) that consists of engineers from mobile technology companies. If Qualcomm wants their cell modems to be 3GPP certified, they _must_ comply to the 5G standard in it's fullest, including all security features (the same will be true for future revisions, 6G, etc)

There's also groups attempting to make mobile protocols and provisioning entirely open source (O-RAN) which, ironically, will likely improve mobile protocol implementation security practices as they can be audited by anyone with an internet connection.

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?

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.

Thank you. I didn't know that.

It seems two essential patents will expire in 2029 and 2030 [1]. So we are basically stuck in this mess till then.

[1] http://www.fosspatents.com/2022/06/lessons-from-rejection-of...

> Apple stopped paying Qualcomm the LTE blood money.

"blood money"? Why so many tears for the most valuable business on Earth? When they picked Qualcomm for their 4G modem, the terms were clear. And then they decided to renegotiate the terms afterwards by telling their manufacturer to withhold the payments to Qualcomm.

> _Qualcomm still sued and made money_.

They negotiated a settlement, Qualcomm got less than they were owed and Apple paid less than the royalties due. Why did Apple settle? Because they had to make design decisions about their new phone - like which modem vendor to use. If you decide not to pay your supplier you could imagine they'd want to work that out before agreeing to give you samples of their new design. If Apple felt that they'd win the case on the merits and that the Qualcomm modem design didn't perform well, they would have just picked a competitor like Samsung. But they didn't do that. They even dual-sourced modems for iphone 7 in order to preserve their negotiating position. But that didn't work because the iphones with Intel modem performed worse than iphones with Qualcomm modems.

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

Google "did" secure a win, didn't they? They took their ball and went home. They decided to take the Samsung Exynos SoC and modem for their flagship phone.

> They're back to buying Qualcomm modems again.

... because they're better than the competition - including their acquisition? Is it your contention that Qualcomm somehow forced Apple to pick them over their own?

> "blood money"?

Software patents are math patents, and math patents are not legal under US law, yet the USPTO continues to issue them. Many standards organizations require you to open the patents to anyone implementing the specifications managed by that organization if you wish to be part of the committee and introduce your technology to it, and the relevant policy here is a joint ITU-T/ITU-R/ISO/IEC governing agreement to do so.

3GPP was developed as a way to sidestep such mandatory agreements, while still being an ITU-managed spec. The company that is gaining the most advantage from this loophole is Qualcomm.

> Google "did" secure a win, didn't they? They took their ball and went home. They decided to take the Samsung Exynos SoC and modem for their flagship phone.

Yes and no. Google and Samsung are jointly putting pressure on Qualcomm that Apple couldn't. Both of them have patents that are part of the LTE patent pool as well, and key ones that would cripple Qualcomm if either of them pulled out.

Apple, through their Intel LTE acquisition, did not have as much leverage, even though Intel was the only other company was ready to compete in the 5G space and had patents relevant to 5G.

I believe Qualcomm, if they wished to push the issue, could also force both companies to settle. They may do so in the future.

> ... because they're better than the competition - including their acquisition? Is it your contention that Qualcomm somehow forced Apple to pick them over their own?

I do not believe so. Most of what was wrong with the first post-acquisition gen modems was Intel mismanagement of the product line (the same way they do to every other product of theirs). LTE benchmarks of the iPhone generation that contained both modems (and it was a random chance on which was in your phone) were mixed. Sometimes the Qualcomm modem was better, sometimes it was Intel.

It would be a shame if Apple abandoned the product entirely, and I don't think they did. I think this is part of the settlement. So, yes, to answer your question, I believe the settlement requires purchase of Qualcomm modems for x generations. The details of the settlement are not entirely public, other than there is a 2 year supply agreement.

You don't drop $1B on an acquisition just to get their patent portfolio and then settle and give up forever. You double down and continue working on polishing up that acquisition while the conditions of the settlement expire. I think in 2-3 generations we will see the return of the Intel modem; if we don't, I think Apple should go find themselves a new CEO.

Isn't all of this obvious for a modern C or C++ codebase? Is the state of Android baseband so bad that these are useful suggestions? Are they at least properly ring-fenced from the host CPU/RAM these days?

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 serial (which leads to poor performance, but a secure phone). Some phones, such as any using a vanilla Qualcomm Snapdragon setup of any generation simply don't care: the baseband firmware has more holes than a slice of swiss, and the IOMMU refuses to allow the OS to restrict the baseband processor's view into system RAM.

This is a known attack vector used by state sponsored actors, including the US breaking into the phones of so-called "drug lords" to ease drop on them live from their own phones , without a call being active.

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.

> 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 there's a big pink elephant in the room you should not look at:

> the IOMMU refuses to allow the OS to restrict the baseband processor's view into system RAM.

And I can't find any valid technical reason for that elephant to be in the room.

There shouldn't be limitations for accepting IOMMUs: "be liberal in what you accept and conservative in what you send"

> Some phones straight up admit the baseband is actively hostile and only communicates with it via serial

That looks like a fair assumption. You wouldn't have daemons listening as UID 0 on all ports, accepting then running the random binaries they get, so why would you magically assume it's ok to do the exact same but with baseband instead of a daemon?

> (which leads to poor performance, but a secure phone)

Can you recommend some phones?

I wanted to get a better understanding of the stack so I bought an original pinephone, with the grand plan of installing arch on it (for fun!)

Could it be made to work like that?

A simple search only found https://www.reddit.com/r/pinephone/comments/har9aj/pine_phon... which concludes with "I don't think the Pinephone can provide any of the security requirements of Graphene OS ( iommu isolation etc )"

What should I buy to explore the concept of IOMMUs on cellphones?

Graphene recommends a modern pixel. If they can properly restrict memory access on those phones and the baseband doesn't have any direct access to the mic via analog signal or similar, then it probably can't listen in on either incoming or outgoing communication, that should all be encrypted before it hits the memory right? You could still be located and identified, but they don't need to compromise your baseband for that.

This could be old info but I believe the Baseband chipset has its own microphone in addition to access to the user mics for the purposes of signal processing.

This was a stink years ago and part of the GSMK product development. AFAIK GSMK is the only commercially available product to have a baseband firewall and their own stuff running to deal with this

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.

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

I feel like this article was surely written by someone who has never actually looked at cellular baseband firmware, listened to researcher’s talks, or even stayed at a Holiday Inn.

Cellular hardware companies have to care first… As in NOT using crappy 32bit processors without virtual memory.

Things like non-executable stacks have merit… ASLR has merit…

Then, we can start yapping about compiler flags…

Or you could just use a USB cellular modem.

Reply on news.ycombinator.com