[HN Gopher] Hardening cellular basebands in Android
___________________________________________________________________
Hardening cellular basebands in Android
Author : el_duderino
Score : 84 points
Date : 2023-12-12 19:16 UTC (3 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| pedrocr wrote:
| 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?
| DiabloD3 wrote:
| 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.
| csdvrx wrote:
| > 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?
| galangalalgol wrote:
| 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.
| csdvrx wrote:
| 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?
| jtriangle wrote:
| 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.
| devit wrote:
| At least modern Google Pixel phones have an IOMMU
| (https://grapheneos.org/faq#baseband-isolation)
| csdvrx wrote:
| > 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!
| twothreeone wrote:
| 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.
| JoshTriplett wrote:
| 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.
| xiipie wrote:
| 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.
| DiabloD3 wrote:
| 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.
| xiipie wrote:
| > 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?
| avidiax wrote:
| 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.
| therealmarv wrote:
| Guessing the Tensor G1..3 based Android phones are not affected
| by 5Ghoul? https://asset-group.github.io/disclosures/5ghoul/
| ksjskskskkk wrote:
| it probably is, but you won't get the usual academic work for
| free as you get with more common platforms.
| acaloiar wrote:
| 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.
| tptacek wrote:
| 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.
| csdvrx wrote:
| it can't and it shouldn't _IF_ IOMMUs were properly used
| ksjskskskkk wrote:
| > , 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.
| vlovich123 wrote:
| > 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.
| phh wrote:
| 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 to mention doing 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.
___________________________________________________________________
(page generated 2023-12-12 23:00 UTC)