Are opaque basebands a national security risk?
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?
17 comments
[ 2.8 ms ] story [ 56.7 ms ] threadhttps://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
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.)
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.)
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.
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...
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/
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.
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?
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...