4 ms·
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?
- pabs3 4y agoNot 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/ 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 https://media.ccc.de/search/?q=baseband
- dontbenebby 4y agoWhy 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.)
- pabs3 4y agoAn 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.
- dontbenebby 4y ago>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_European_data_privacy_law https://en.wikipedia.org/wiki/Ubuntu#Conformity_with_Europea... [2] https://en.wikipedia.org/wiki/Ubuntu#System_terminal_advertising_controversies https://en.wikipedia.org/wiki/Ubuntu#System_terminal_adverti...
- mikewarot 4y agoClearly, 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.
- pyinstallwoes 4y agoIf we memoized every computed function and distributed it as a dht, why not? Sounds good and secure.
- pyinstallwoes 4y agoYes all computation is an attack vector, it's exploits all the way down. The riddle is, what is the solution?
- rl3 4y agoProbably more computation, much in the same way technology is sometimes used to solve problems it creates.
- topor 4y agoThey'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.
- T3OU-736 4y agoWhat 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?
- Avamander 4y agoLast I saw, QualComm's firmware was very tedious to even view, not to mention analyze. Being downloadable doesn't make them significantly more transparent.
- Am4TIfIsER0ppos 4y agoA 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.
- Kiboneu 4y agoA 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.
- qball 4y ago>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...