12 February 2009
There are stories going around the 'net
of a "Dangerous" security flaw in Google's Android Operating System
(OS). Some are saying that this bug is so dangerous that you
should not even use the Web from your
T-Mobile/HTC/Google/G1/Dream/gPhone/Whatever you call it phone.
It is true that there is a bug. It's also true that it is
fixed in Google's software repositories
It's true that Google has not pushed the fix out to customers, or even
made it available for download (other than in source form).
true that Google did push out an update since this bug was exposed and
corrected, but that update ignored the flaw. Lastly
true that early in Android's life cycle, it did have a really, really,
simple, dumb, and serious flaw. But what I do not believe is
rumored seriousness of this new bug, or the implications that Google is
being slow, or negligent in their response.
If this bug were viewed with a Microsoft Windows mentality, it would be
serious. It is exactly
the sort of bug that can turn Windows PCs into spam zombies or
keystroke loggers just by visiting a website. But Android isn't
Windows. It isn't even “just” Linux. It's Linux
phobic security features layered on top. The creators of
at Google probably had exactly this sort of error in mind when they
developed Android. Let's get a little technical, and we will
why it is much less of an issue on Android. Then we can
why some may be saying it is so serious.
OK, So Android
runs on top of a pretty much standard Linux kernel. I do not
on explaining Linux security here, but suffice it to say that Linux
prevents rouge, or exploited programs from being able to affect the
system the way such programs can in Windows. If a web browser
run as root (I.e. as a super user, or super administrator) on Linux
such a flaw would
entire system to be taken over. If anything, it would be
to do pretty much anything on the Linux system, since Linux lacks the
concept of “zones” to restrict the browser's behavior. Linux
also more likely to have mail servers, compilers, and file transfer
services all built-in and at the attackers disposal once he/she finds
an exploitable flaw. In fact some mobile products do run
everything as root. Even the iPhone (which is based on BSD –
Linux's “older cousin”) ran every program, including the browser, as
root in its first incarnation. Apple changed this in one of the first
iPhone software updates. Most Linux-based
have learned from the past, and now run most functions as another,
imaginary user that does not have administrator privileges.
user may be named “mobile”, or just “user”. This means that
a successfully exploited flaw in the browser cannot make fundamental
changes to the OS, or install new software.
Google has taken it
a step farther. Each individual application in Android runs
not only a separate Linux process, but it is running as a different
fake user. In other words, when you are using your G1, there
actually several, or perhaps dozens of “virtual users” logged into its
underlying Linux foundation. Each user is doing 1 separate
What one “user” does cannot affect the others, just like you can't read
my email, and I can't read yours. Programs pass data back and
forth to each other by tightly controlled conduits that restrict
exactly what can be sent back and forth. Further more, each
program is running inside a separate incarnation of a virtual
machine. The virtual machine isolates the running application
from even affecting it's
Linux process. The analogy here is running Windows XP on a
virtual machine on a Mac. Even if the virtualized Windows XP
session is successfully attacked, simply quit the Virtual Machine and
the Mac OS machine is not in any way comprised or affected.
look at this particular bug. The flaw is in OpenCore, which
open source media server, not in the browser. It would have
exploited with a bogus MP3 sound file. So if a user surfs to
site attempting to exploit the flaw, the browser calls
to play the sound. The browser and the player are running as
only separate Linux processes, but are run by separate users, in
separate incarnations of a virtual machine. Note that the advisory
says it is potential
, in other
words NOT demonstrated
arbitrary code execution, and it does not take into account the concept
of OpenCore running in a separate Virtual Machine. It is very
unlikely that it could corrupt anything outside the media playback
mechanism, even the browser session that launched it. It's a
little like saying if you play an infected MP3 on your PC, my PC is
going to get a virus.
If the allegations are true, just provide
a proof of concept web page that harmlessly demonstrates it.
Craft a page/file that reboots the phone. If you claim it can
steal passwords or cached data from the browser, prove it.
out the last 3 sights a user visited, or with their permission, snarf a
password. Harmless demonstrations like this have been setup
times in the past for exactly such issues. But we don't see
a demonstration for this issue. What does that tell you?
why would someone bring up this already patched issue, and why right
now (Feb 12) ? Guess what happens on Monday, February 16th?
-- Mobile World Congress (MWC)
Spain 2009 – The mobile phone industry's biggest annual
It's kinda like Macworld or CES for mobile devices. It's the
first such event since Android products have been released, and Android
will likely be getting lots of attention. Want some quick headlines,
talk, and web hits? Yup -- perfect timing.
Note also that one of the contributors to the article offers for sale
Anti-virus products for Android devices.
also that Android is, for the most part, truly open source.
one can see the code, including bug fixes, open issues, and code commit
dates. The openness and visibility, again makes it an easy
for attacks -- not from hackers, but from the media. If we
peer into Apple's iPhone master software source trees, or Windows
Vista's what would we see?
The fix for this bug is out there,
and is being vetted through the normal processes of testing and peer
review. Google, T-Mobile, and other active members of the
Handset Alliance will roll out updates to users on their schedules just
like Apple, Microsoft or any other vendor would. Looking at
publicly available code on a public website, and then writing
sensationalized “news” articles on already disclosed, and patched
issues does not gain you much respect from the
It does however lend an opportunity to explain some of Linux and
Androids inner workings, and I thank you for that.
Note: The article at ReadWriteWeb
has been updated. The update points out some of exactly what
I described above.
I am a registered Google Android Developer. I do
for Google, or any Hardware or Software vendor.