The secret second operating system that could make every mobile phone insecure

When we talk about computers — PCs, smartphones, cars — we generally assume that there’s just one operating system: A single, monolithic piece of software that manages each individual piece of hardware, from the CPU to the USB controller to the wireless connectivity. If your system crashes, we nearly always blame the operating system, or perhaps a software driver that links into the OS. In just about every computer science textbook, a computer consists of just three blocks: the hardware, the operating system, and then all the (user-land) software that runs on the OS. In actual fact, unbeknownst to the user, almost every computer has multiple operating systems running at the same time, managing various different parts of the computer — and worryingly, these OSes are usually proprietary, closed-source, bug-ridden, and have extensive, low-level access to your data.

Take your smartphone, for instance. There’s definitely a primary OS — Android, iOS, Windows Phone — but there’s also at least two other operating systems: The baseband OS and the SIM card OS, both of which run on their own processor that’s separate from the SoC. Whenever your phone is powered up, these operating systems are running, managing their respective domains. When you send a text or receive a call (or do anything wireless), it’s actually passed off to the baseband OS, which handles all of the messy details of dealing with GSM, UMTS, HSPDA, LTE, etc. When you need some secure data from your phone’s SIM, Java Card — which has exclusive access to encrypted data on the SIM — takes over.

A reverse-engineered SIM card. Believe it or not, there’s a small processor in there that runs a small operating system.

At first blush, this seems like quite a sensible way to do things — after all, there are so many different hardware devices in a modern computer that it would be very hard for someone like Google or Apple to create optimal solutions for all of the permutations. It also makes sense from an efficiency perspective, to have multiple computers that are working in parallel — it’s good that the baseband OS and processor can manage the sending and receiving of cellular data, leaving the SoC free to work on more computationally expensive tasks, such as rendering small sprites of candy and playing obnoxiously loud music on the subway. In theory, this kind of encapsulation can also be more secure — there’s no reason that users should have direct access to the baseband or SIM card, and such encapsulation should prevent hackers/malware from gaining access to those secure regions as well.

In practice, though, these operating systems are often implemented in a very messy and insecure fashion. For a start, it’s important to note that almost all of these secondary OSes are proprietary closed-source software, developed in-house by the hardware maker (Qualcomm, Broadcom, Realtek, etc.) Because developers don’t really have a legitimate reason to directly access these devices, there is usually very little public documentation on how these OSes work. Furthermore, according to Thom Holwerda at OS News, these OSes are often outdated and full of insecure, legacy functionality. All of these factors combine to make these secondary OSes very, very insecure.

We’d like to give you an example of a secondary operating system, but the fact that there’s almost no public documentation makes it very hard. The best example we can come up with is Qualcomm’s REX OS, which powered the company’s baseband processors since 1999. There are indications that Qualcomm finally stopped using REX OS in 2012, but it’s hard to come by any definitive data. REX OS is a real-time operating system (RTOS) that runs on the Qualcomm baseband processor (in this case an ARMv5 core). The baseband processor (and thus REX OS) has direct access to the phone’s hardware (speakers, microphones), and also seemingly the ability to write to the same memory as the SoC (or application processor). REX OS is based on a very old and large code base from the ’90s, and implements many standards from the ’80s (including the Hayes dial-up modem command set). We only know this information, incidentally, because a hacker reverse engineered REX OS [PDF].

A Sprint cell site in San Francisco: Backhaul (right), backup power (mid), base station hardware (left). Your phone treats everything that’s sent by the base station as law. God help us if someone works out how to hack a base station, or sets up their own.

As you can probably guess, a large, closed-source codebase that implements old standards is a really bad idea. Holwerda says that REX OS automatically executes any commands that it receives over-the-air from the carrier’s base station — and yes, in case you were wondering, there are commands that perform a variety of heinous acts, such as turning on auto-answer, executing arbitrary code, or simply bricking your device. It goes without saying that, in theory, you could set up your own base station (say, with software-defined radio) and cause a lot of havoc. When you hear that an iPhone has been jailbroken due to a baseband exploit, it means that hackers have found a bug in the baseband OS or processor that gives them elevated access to the rest of the device.

This is just one example of a secondary OS. As I previously mentioned, your SIM also has a small processor that runs a tiny kernel that can execute Java software. (The SIM card and its OS was recently hacked, incidentally.) If your computer has some kind of secure storage area, such as ARM’s TrustZone, there’s probably another separate OS and processor in there, too. The minuscule size of wimpy ARM cores and lack of documentation means that it’s very hard to tell just how many discrete OSes are running on your computer concurrently. In classic pre-internet, security-through-obscurity style, we won’t know how secure these OSes are until they’re (publicly) hacked. If the NSA wanted to deploy a wide-scale hack that gives it access to everyone’s phone calls, the baseband would be the place to do it.

The only real solution to this problem is to move away from closed-source hardware and software. There is some indication that some baseband processors are moving to open solutions, such as OKL4, but again it’s very hard to come by any definitive data, because commercial companies like Qualcomm aren’t in the habit of broadcasting the internal workings of their chips. For the time being, then, just be aware that most of your devices are running multiple operating systems — some of which are probably very insecure, and there isn’t anything you can do about it.

Tagged In

Alright everyone, grab your pitchforks and and tin foil hats and meet me by the interwebz factory. This is srs bsns.

Heath Parsons

With the money Qualcomm makes from their chips in mobile devices, they are well off. They have more than enough money to develop closed-source software if they so please, and being outside of the US, probably have very secure, fully tested software developed by really intelligent people. Seeing as how not many have been “(publicly) hacked”, something must be said about their security measures, which are strong based on observation.

I might add that any decent, well developed software has a life of around 10 years (every other version of MS Windows for instance, fighting and preconceived notions aside, is well developed.) My money is on a very secure system now for Qualcomm since they’ve stepped up their game. Just because something is legacy, doesn’t mean it’s not quality. Newtons laws are still functional to some extent, the Pythagorean theorem still applies, 1+1 still equals 2 unless you’re pregnant, and fax machines still work.

I agree, open source is the way to go though. That will last until Apple decides to patent something already made by someone else 10 years prior, so they can get more money from frivolous suits because of iPhone manufacturing shortages.

Dozerman

That’s it! Today, I am announcing my latest Kickstarter project titled FOSSNET! It will be an entirely Free internet built from custom build off the shelf routers running freeBSD plugged into the outlets of over 9000 buildings in las vegas. We will run around eighty thousand miles of ethernet cables between bulding for high speed communication and all servers will be run by an array of 8086s to ensure no hidden OSes can be hardwired iinto the microcode. ARM powered phones are not allowed, only MIPS. The only allowed OSes allowed for connected computers will be FreeBSD, Gentoo, and Haiku. Starting goal in 15 billion by the end of the month.

Rodger that. I’ll get started learning Verilog. We’ll need FPGAs, too. Forgot about that in the product details…

Tim Tian

I’ll get started on a basic standardized low level language.

Gerald Dichiara Jr

What Nobody is Asking is;
Are these Secondary and so on OS’s how the NSA is able to Access Everything that We Do Electronically by taking advantage of their Flaws and whatever else that they do with their Direct Interaction with Everything Electronic whether it be Our PC’s or our Tablets or our Phones.

TheOtherTurnipTaliban

Qualcomm etc have probably been ‘requested’ to share data on their OS’s, the NSA aggressively pursue companies that are in key positions like this i.e they have low level access to people’s phones.

Ioannis Doukakis

And as American companies rushed to fulfill the NSA’s requests…

TheOtherTurnipTaliban

then what happens?

jburt56

You don’t say? Who’d have thunk it?

http://petegrif.tumblr.com/ Pete Griffiths

I don’t think the article is saying that this ‘could’ make very phone insecure. I think they are saying that every phone IS insecure.

Ioannis Doukakis

You do not count also the os/firmware that the GPS unit contains (possibly harmless), plus the new Motion processor in the iPhones, which I do not know what rights it has in the machine but as Apple says never sleeps…

Mark Giblin

It all comes down to money, screw quality and security, they are non-contenders in the production of any software no matter where programming and hardware come together to form a product like a mobile phone, mp3 player, video camera, cable decoder, TV, remote control, ECU/EMU in a car, etc.

I have also seen myself how developers wanting to rush an idea out the doors will often use boiler plate code without regard to how old the technology is, if it is properly debugged and optimized and that was just on *nix systems, I suspect that windows is as bad or twice as bad with its code through out its product.

Sure, it may be written in C language which is all powerful and fast but that doesn’t count for taters if you’re running buggy code which itself can lead to a security breach.

Proprietary code needs to be made a thing of the past and people use open sourced systems to complement the hardware.

True that open source is buggy, so what… thats the main reason why, so that the “community” can point this stuff out and some kindhearted person(s) provides an immediate fix and not one that arrives sometime the following year…

ExtremeTech Newsletter

Subscribe Today to get the latest ExtremeTech news delivered right to your inbox.

Use of this site is governed by our Terms of Use and Privacy Policy. Copyright 1996-2016 Ziff Davis, LLC.PCMag Digital Group All Rights Reserved. ExtremeTech is a registered trademark of Ziff Davis, LLC. Reproduction in whole or in part in any form or medium without express written permission of Ziff Davis, LLC. is prohibited.