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

11–20 of 109 posts

Re: Hardening cellular basebands in Android

#11

Post by xiipie »

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…

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

Re: Hardening cellular basebands in Android

#12

Post by devit »

csdvrx wrote: post #3

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

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

Re: Hardening cellular basebands in Android

#13

Post by csdvrx »

DiabloD3 wrote: post #7
pedrocr wrote: post #2

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

Re: Hardening cellular basebands in Android

#14

Post by csdvrx »

devit wrote: post #12
csdvrx wrote: post #3

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

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!

Re: Hardening cellular basebands in Android

#15

Post by [deleted] »

DiabloD3 wrote: post #7
pedrocr wrote: post #2

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

[deleted]

Re: Hardening cellular basebands in Android

#16

Post by acaloiar »

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.

Re: Hardening cellular basebands in Android

#17

Post by avidiax »

xiipie wrote: post #11
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…

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

Re: Hardening cellular basebands in Android

#18

Post by tptacek »

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

Re: Hardening cellular basebands in Android

#19

Post by galangalalgol »

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…

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.

Re: Hardening cellular basebands in Android

#20

Post by ksjskskskkk »

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.

Post reply on HN