[liberationtech] The second operating system hiding in every mobile phone
wasa bee
wasabee18 at gmail.com
Wed Nov 13 01:25:41 PST 2013
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 <eugen at leitl.org> 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
> companys at stanford.edu.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20131113/d51d5235/attachment.html>
More information about the liberationtech
mailing list