there's a 3rd OS running in your smartphones (besides the Java card in your SIM): http://armdevices.net/2012/05/04/samsung-galaxy-s3-may-be-the-first-smartphone-with-full-arm-trustzone-support-for-enabling-100-security-in-everything-online/ All new Samsung phones have it... and it is proprietary too. This one's built with security in mind and certainly is perfect for spying/backdoor purposes :) ...
On Wed, Nov 13, 2013 at 8:54 AM, Eugen Leitl <[email protected]> wrote: > > > http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone > > The second operating system hiding in every mobile phone > > posted by Thom Holwerda on Tue 12th Nov 2013 23:06 UTC > > I've always known this, and I'm sure most of you do too, but we never > really > talk about it. Every smartphone or other device with mobile communications > capability (e.g. 3G or LTE) actually runs not one, but two operating > systems. > Aside from the operating system that we as end-users see (Android, iOS, > PalmOS), it also runs a small operating system that manages everything > related to radio. Since this functionality is highly timing-dependent, a > real-time operating system is required. > > This operating system is stored in firmware, and runs on the baseband > processor. As far as I know, this baseband RTOS is always entirely > proprietary. For instance, the RTOS inside Qualcomm baseband processors (in > this specific case, the MSM6280) is called AMSS, built upon their own > proprietary REX kernel, and is made up of 69 concurrent tasks, handling > everything from USB to GPS. It runs on an ARMv5 processor. > > The problem here is clear: these baseband processors and the proprietary, > closed software they run are poorly understood, as there's no proper peer > review. This is actually kind of weird, considering just how important > these > little bits of software are to the functioning of a modern communication > device. You may think these baseband RTOS' are safe and secure, but that's > not exactly the case. You may have the most secure mobile operating system > in > the world, but you're still running a second operating system that is > poorly > understood, poorly documented, proprietary, and all you have to go on are > Qualcomm's Infineon's, and others' blue eyes. > > The insecurity of baseband software is not by error; it's by design. The > standards that govern how these baseband processors and radios work were > designed in the '80s, ending up with a complicated codebase written in the > '90s - complete with a '90s attitude towards security. For instance, there > is > barely any exploit mitigation, so exploits are free to run amok. What makes > it even worse, is that every baseband processor inherently trusts whatever > data it receives from a base station (e.g. in a cell tower). Nothing is > checked, everything is automatically trusted. Lastly, the baseband > processor > is usually the master processor, whereas the application processor (which > runs the mobile operating system) is the slave. > > So, we have a complete operating system, running on an ARM processor, > without > any exploit mitigation (or only very little of it), which automatically > trusts every instruction, piece of code, or data it receives from the base > station you're connected to. What could possibly go wrong? > > With this in mind, security researcher Ralf-Philipp Weinmann of the > University of Luxembourg set out to reverse engineer the baseband processor > software of both Qualcomm and Infineon, and he easily spotted loads and > loads > of bugs, scattered all over the place, each and every one of which could > lead > to exploits - crashing the device, and even allowing the attacker to > remotely > execute code. Remember: all over the air. One of the exploits he found > required nothing more but a 73 byte message to get remote code execution. > Over the air. > > You can do some crazy things with these exploits. For instance, you can > turn > on auto-answer, using the Hayes command set. This is a command language for > modems designed in 1981, and it still works on modern baseband processors > found in smartphones today (!). The auto-answer can be made silent and > invisible, too. > > While we can sort-of assume that the base stations in cell towers operated > by > large carriers are "safe", the fact of the matter is that base stations are > becoming a lot cheaper, and are being sold on eBay - and there are even > open > source base station software packages. Such base stations can be used to > target phones. Put a compromised base station in a crowded area - or even a > financial district or some other sensitive area - and you can remotely turn > on microphones, cameras, place rootkits, place calls/send SMS messages to > expensive numbers, and so on. Yes, you can even brick phones permanently. > > This is a pretty serious issue, but one that you rarely hear about. This is > such low-level, complex software that I would guess very few people in the > world actually understand everything that's going on here. > > That complexity is exactly one of the reasons why it's not easy to write > your > own baseband implementation. The list of standards that describe just GSM > is > unimaginably long - and that's only GSM. Now you need to add UMTS, HSDPA, > and > so on, and so forth. And, of course, everything is covered by a > ridiculously > complex set of patents. To top it all off, communication authorities > require > baseband software to be certified. > > Add all this up, and it's easy to see why every cellphone manufacturer just > opts for an off-the-shelf baseband processor and associated software. This > does mean that each and every feature and smartphone has a piece of > software > that always runs (when the device is on), but that is essentially a black > box. Whenever someone does dive into baseband software, many bugs and > issues > are found, which raises the question just how long this rather dubious > situation can continue. > > It's kind of a sobering thought that mobile communications, the cornerstone > of the modern world in both developed and developing regions, pivots around > software that is of dubious quality, poorly understood, entirely > proprietary, > and wholly insecure by design. > -- > Liberationtech is public & archives are searchable on Google. Violations > of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > [email protected]. >
-- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at [email protected].
