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

91–100 of 109 posts

Re: Hardening cellular basebands in Android

#91

Post by ksjskskskkk »

gavinsyancey wrote: post #45
gruez wrote: post #32

Earlier quoted context omitted.

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

Re: Hardening cellular basebands in Android

#92

Post by ksjskskskkk »

gruez wrote: post #32
ksjskskskkk wrote: post #20

Earlier quoted context omitted.

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

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.

Re: Hardening cellular basebands in Android

#93

Post by yxhuvud »

dwbehappy wrote: post #33
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 h…

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

Re: Hardening cellular basebands in Android

#94

Post by thaumasiotes »

alufers wrote: post #43
dwbehappy wrote: post #33

Earlier quoted context omitted.

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

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…

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

Re: Hardening cellular basebands in Android

#95

Post by eptcyka »

atoav wrote: post #89
LoganDark wrote: post #84

Earlier quoted context omitted.

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

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.

Re: Hardening cellular basebands in Android

#96

Post by bdd8f1df777b »

atoav wrote: post #89
LoganDark wrote: post #84

Earlier quoted context omitted.

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

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

Re: Hardening cellular basebands in Android

#97

Post by phh »

numpad0 wrote: post #50
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…

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…

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

Re: Hardening cellular basebands in Android

#98

Post by upofadown »

wtallis wrote: post #41
dwbehappy wrote: post #33

Earlier quoted context omitted.

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

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.

Re: Hardening cellular basebands in Android

#99

Post by the8472 »

numpad0 wrote: post #50
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…

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…

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

Re: Hardening cellular basebands in Android

#100

Post by tptacek »

MadnessASAP wrote: post #86
csdvrx wrote: post #79

Earlier quoted context omitted.

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

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