Re: Google ps over Androidj ib

["Doty, Timothy T." <tdoty () MST EDU>]

While this does make evident the access the provider has to your mobile
device, what bothers me from a technical security standpoint is that this
application had the ability to execute arbitrary code it downloaded from the
Internet. In *principle* this should not be possible on the iPhone due to
the strict limitation on scripting.

The iPhone's security model is one of application review and limited
privileges. The Android security model is one of strict sandboxing and user
awareness of the general capabilities. Put that simply the Android model may
not seem bad, but what it reminds me of was a software application that had
"extensive granularity" -- 99 different items to toggle access on. But for
the software to work you really had only three sets of permissions: full
access to everything, read access to everything or no access at all.

In the case of Android, requiring one privilege for an application
("Internet") is sufficient to cover a Trojan that downloads arbitrary code
at a future date (when a vulnerability is discovered) to allow rooting of
the mobile device. Somehow, it doesn't seem like "Internet" access is a good
description for that capability. So a user installs the Trojan and if it was
a reasonable application at all they would never question its utility. The
researcher in the present case apparently made no serious attempt to create
a cover application, but a bad guy would.

I see this as an inherent flaw in the "caveat emptor" model espoused by
Google. Not only does it put the onus on a user who most likely doesn't
understand the issues, but it isn't accurately representing what potential
threat an application represents. From the "pass the blame" perspective this
isn't an issue and by not reviewing applications Google's process is much
smoother (and presumably much quicker) than Apple's. But I don't see how it
provides any security.

Sure, iPhone applications are updated transparently from a user perspective
with no meaningful insight into what the update actually means -- but the
updated version has to pass the review process. Does Apple's review process
provide any security? I think that is an open question at this time, but at
least it's an open question as opposed to the ability of software to
automatically and silently download arbitrary code to then execute. Does
anyone really think there *won't* be some sort of privilege escalation
vulnerability found in Android at some point? The same applies for the
iPhone (and I'll point out the SMS bug), but the opportunity to exploit a
local vulnerability seems (superficially at least) to be less on the iPhone
than with Android.

To put it another way, any Android application with the Internet privilege
is a potential Trojan downloader. There does not appear to be such a large
window with the iPhone. From this it would appear that this *is* a
differentiating security factor between Android and iOS. (I'm not suggesting
that it is the only or even the most important differentiating factor, but
it does appear to me to be a significant security factor in environments
with naïve users.)

Tim Doty


> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of randy marchany
> Sent: Tuesday, June 29, 2010 9:40 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Google ps over Androidj ib
>
> > The concern raised by this shouldn't stem from the fact that Google
> removed these apps without notice, but rather that your >users may have
> installed them in the first place and never known the implications
> (meaning they could be running rootkits without >your knowledge).  If
> Google uses this power to remove applications that have known rootkit
> behavior, I don't think they'll get much >grief from me.  Like most
> people, I would prefer this power not exist, but I wouldn't consider
> this particular example an abuse.
> >
>
> The concern is that the phone provider has access to ANY file on the
> smart phone. Has this always been the case? Yep. It's just this
> article brings this ugly truth to the forefront. This has serious
> implications in the way we develop mobile/smart phone
> policies/procedures.
>
> If your institution's "sensitive" email/data will be stored on a smart
> phone (let's face it's a likely scenario) in the form of email
> attachments, files with passwords (the electronic equivalent of the
> sticky note), etc. then Google/Apple/Generic has potential access to
> that data. Yes, there might be license agreements about the Google's
> procedure for removing data from a smart phone but that process is not
> clear.
>
> I might have a file called "rootkits" on my smart phone device because
> my job is computer security. I don't want any phone provider to decide
> for me what should or shouldn't be on my phone. The "security because
> I know better"  model that AV and other "preventive" security model is
> a reactive strategy and still results in compromises. Removing a
> suspicious app from their store (Apple store, Google store, etc.) is
> one thing and I'm in favor of that to some degree. Removing a
> "suspicious" app from my phone w/o my knowledge/permission/control is
> a completely different thing.
>
> > And FWIW, Apple has much more draconian control over their apps, so
> if control over your device is something you value, then the Android is
> still a much better choice than an iPhone.  I would say the iPhone is a
> better choice for people who specifically want others to control their
> experience and environment (including which apps you're allowed to run
> on your phone).
> >
>
> This isn't a "android vs. iphone" conflict. It's a phone
> manufacturer/service provider vs. end-user/customer thing. This is
> similar to the "who owns the computer data on your car" conflict where
> car manufacturers say they own it and the car owner says it's mine.
> Who owns the data on a smart phone? Who has access to that data? Is
> end user privacy being "facebooked" by the phone manufacturers?
>
> We need to consider these new threats to our institutional data.
>
> -Randy Marchany
> ISO, VA Tech

Attachment: smime.p7s
Description: