Hacker News Reader

Comment by acaloiar | Hacker News Reader

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.

View on HN

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!

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.

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

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

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

Reply on news.ycombinator.com