Are opaque basebands a national security risk? | Hacker News Reader

Are opaque basebands a national security risk?

56 pointsjavajosh17 comments

I have this vague unease about computing, that there's far too much mutable state between 'power on' and 'seeing my application window'. This is particularly true with smartphones, where in addition to the mysteries of where and how BIOS, UART, boot loaders, TPM, CPU microcode state was obtained (and how it can be updated), you also have the extra-mysterious baseband. Which, as I understand it, is your carrier's trump card on your device - a whole computer-within-a-computer, controllable directly from the radio, can access all devices, all storage and even read/write the working memory of your operating system. (It may seem like a neat superpower to have, but it's a superpower built on artificially weakening the population.

Putting spyware on people's second-brains feels wrong. But it also seems like a critical vulnerability in the event of war. Consider the prize of gaining access to a privileged baseband distribution channel! Wouldn't it be better, from a national security perspective, to disallow the practice of proprietary, privileged channels entirely? Or do the benefits of having that channel outweigh the risks?

Not all basebands have that much control. For example in the PinePhone, the ARM processor in baseband runs a proprietary Linux distro, but folks have replaced that with a fully free Linux distro. Unfortunately the proprietary software running on the Hexagon DSP hasn't been replaced. I believe the interface between the two is fairly restricted though.

https://github.com/the-modem-distro/pinephone_modem_sdk/

BTW, there are a number of videos at the CCC media archive about concrete vulnerabilities in baseband software:

https://media.ccc.de/search/?q=baseband

Why is freedom so important? I've noticed many projects still give MD5 checksums, if any. That's a form of freedom, I guess, since the code is open source, but if no one has the time to secure things the open code just makes it easier to find 0 days... and then you don't need a 0 day if you can just hack the site to alter the binary and serve up a matching hash :/

The above is why for a long time I supported Apple -- I viewed it as paying for a team of folks to audit code etc, but they've made so many terrible decisions such as literally removing the function keys for a touchbar that my next laptop will probably be something that can run Debian well (then whatever else I need in a VM, since this device has a tiny hard drive and not a ton of ram nor a decent GPU since I got it back when I had a university affiliation and could SSH into all sorts of things rather than keep everything here or on a literal USB hard drive in a safe.)

You should publish a paper about md5 preimage attacks if you know how to do what you just described. Im not aware of any existing ones. Are you maybe confusing collision attacks with preimage attacks?

Maybe. I probably misspoke.

Why would I publish though? In the past it hasn’t lead to income, paired with snarky replies about known bad practices.

Seems like it’s better to think and act like a magician - hoard esoteric knowledge and wield it as needed.

(Though I’m mostly annoyed you seem to only be paid for RCE not “just” denial of service vulnerabilities.)

An example of why software freedom is important in basebands; the proprietary PinePhone baseband software contains a vulnerability (IIRC RCE) and the vendor never fixed that issue, but the libre PinePhone baseband fixed that vulnerability.

It is only through software freedom that people can control their devices and independently find and fix problems with them, including security issues. Since not everyone has the skills for that, those that do can band together forming open communities around projects and improving code quality collectively.

I note that Asahi Linux now runs on Apple M1/M2 products, so you could continue to buy Apple hardware (since it is better than other hardware) but use Linux so you control your experience more.

>An example of why software freedom is important in basebands; the proprietary PinePhone baseband software contains a vulnerability (IIRC RCE) and the vendor never fixed that issue, but the libre PinePhone baseband fixed that vulnerability.

I agree that's a great part of open source -- you can write a patch.

My concern is that without some kind of security person on the project, what happens is often people notice a flaw and hoard it... or they inform a tiny project, ride out whatever window the jerks at CERT or whatever set, then start going buck wild with it.

On my end, my big concern was privacy. You can't obtain privacy until you have security -- until you lock down your projects. And every time a project gets good enough to trust someone seems to come and fuck it up[1].

The classic example being Ubuntu -- just as I was ready to possibly switch to them from OSX, they added privacy invading features that made me think it was better to stick with Apple and start using VMs for the important stuff.

(If you or others have thoughts on distros, I'm leaning towards Debian but I worry that if I switch to that some asshole will come make that one shit the bed in the MOTD[2] like happened with Ubuntu -- I used to have one that popped up an ASCII dinosaur and said "This is a Unix system, I know this" -- but no one except me and the folks at the Apple Store should know that.)

[1] https://en.wikipedia.org/wiki/Ubuntu#Conformity_with_Europea...

[2] https://en.wikipedia.org/wiki/Ubuntu#System_terminal_adverti...

There are tons of people hoarding flaws and exploits for ever piece of software imaginable (Apple included), often these people only work at the binary level and consequently having source code isn't that useful to them. The source code however is useful to users of and contributors to the projects, and to some types of security researchers that focus on open source.

Using software means you will always be subject to security issues and privacy invasions, because programmers are human. Sticking with Apple just means you're still subject to privacy invasions and cannot fix them if you are allowed to find them, but going to Ubuntu means you can at least discover them or hear about them from other folks and patch them out.

Debian definitely has myriad privacy issues (link below), mostly inherited from all the open source software out there. It also has a strong culture of fixing those issues, including basic things like locally installed documentation loading images or JavaScript from the web. More help fixing them is needed though. The only official telemetry we (I'm a member) have is popularity-contest, which is opt-in and that will never change. There is also the hw-probe tool, for optionally submitting to the external Linux Hardware database site. The hw-probe tool isn't well integrated into the Debian installer/etc but if it were, it would be optional.

https://wiki.debian.org/PrivacyIssues https://popcon.debian.org/ https://qa.debian.org/popcon.php https://wiki.debian.org/Hardware/Database

If you're really worried about this stuff, I strongly suggest you look at QubesOS, it uses Xen VMs for compartmentalisation, both for security and privacy. It splits up your digital life into one VM per area, with temporary VMs for dealing with unsafe documents and stuff. The split is up to you and you can run whatever you want inside each VM, including Debian.

https://www.qubes-os.org/

Clearly, you're right. The question is true over almost all computing equipment more advanced than an IBM PC with Floppy Diskette drives.

These days even our CPUs are like the VAX 11/780, which had a boot processor of it's own, to load microcode.

The only way I can think of being secure is reduce computing to a cartesian grid of 4x4 bit Look Up Tables (LUTS), clocked A/B like a checkerboard. This "bitgrid" as I call it can be worked out by hand on graph paper if necessary, and can make strong security guarantees. It would be slow...but since we're concerned with starting everything else up, that's not a huge deal.

You'd have a clock generator, and external serial EPROM, a hardware address counter in charge of loading the loading the initial state of the LUTS... all single step-able for testing and validation. You could then use that hardware to fire everything else up.

Of course, if the LUTS were low enough power, you could just compute with the bit-grid.

If we memoized every computed function and distributed it as a dht, why not? Sounds good and secure.

A very high likelihood that there are parsing vulnerabilities in common basebands that allows a malformed message to change the firmware. These messages can be radio link layer messages or handshakes before encryption is applied. Even without DMA access, a baseband can deliver a malformed message to the baseband’s kernel driver on the android side and use that as a means to get full system access.

The lack of scrutiny in baseband source code review, encryption in relevant messages, and the opaqueness makes it a great target.

>The lack of scrutiny in baseband source code review, encryption in relevant messages, and the opaqueness makes it a great target.

Sure, but why hasn't anyone actually used it in this way yet (that we know of; I'm sure relevant government actors already have at least a proof of concept given they can just request/steal the code and signing keys wholesale)?

Phones have operated this way for the last 15 years and yet not one significant baseband exploit has been used- and maybe that's just for fear that as soon as someone does do this it won't ever be possible again- but that doesn't stop Intel from including their Management Engine, so...

They're a security risk, like any software that forms an attack surface. But they're not that opaque, for most devices. The firmware binaries are typically freely downloadable, or can be copied from the device with a little effort, and then loaded into Ghidra, IDA, etc. for static analysis. For some platforms, there are even baseband emulation frameworks (e.g. FirmWire) available for dynamic analysis.

What isn't obvious, but feels like it should be, is the rationale behind these Phenomenal Cosmic Powers of the baseband (with the attendant itty bitty living space).

As an example, why does baseband need be able to modify OS RAM (assuming that it can do that). Is that a consequence of some sort of DMA for speed, or something else?

Last I saw, QualComm's firmware was very tedious to even view, not to mention analyze. Being downloadable doesn't make them significantly more transparent.

Yes all computation is an attack vector, it's exploits all the way down. The riddle is, what is the solution?

Probably more computation, much in the same way technology is sometimes used to solve problems it creates.

A security risk yes but not a "national security" risk because they are the govt keys to your "kingdom". The govt wants them there so they can spy on you better.

Reply on news.ycombinator.com