

What can you do with an Android application with no permissions? - AndrewDucker
http://leviathansecurity.com/blog/archives/17-Zero-Permission-Android-Applications.html

======
bad_user
This goes to show that security and privacy conscious users should always
prefer the web version, if the choice is available, as the browser is a better
sandbox, even in the context of these tightly controlled mobile platforms and
app stores.

However, I feel that these default permissions are really not that awful.
There's always a balance between giving fine-grained control to the user over
permissions and ease of use and these are not orthogonal issues, as the user
suddenly ends up with more choices to make. What the user really wants to know
... is this mallware? Is this going to delete my files? Is this going to
violate my privacy? ... and that's about it.

If Android required separate permissions for absolutely everything you could
do in an app, you know what the average user would do if presented with a list
of 30 permissions requested, amongst which there would be phrases like "
_allow the app to open the web browser_ "?

The average user would just click "Yes, please" without reading it (I'm even
doing that myself from time to time). And that seems better for technical
inclined folks like us, but it really isn't for average users, because it
trains them to blindly accept anything while giving the impression of security
- and I feel that's worse than no security at all.

~~~
ge0rg
_The average user would just click "Yes, please" without reading it (I'm even
doing that myself from time to time)._

This is happening most of the times anyway. There is no way to see from the
installer screen, _why_ an app requests a certain permission. One example:
most launcher replacements require the CALL_PHONE permission, which comes with
a big warning. This is technically required if you want to place a contact
shortcut on your desktop.

A better, security-wise, solution would have been to ask on-demand, when the
app actually performs a permissions-requiring action, like it is done in J2ME.
I suppose this was not done in Android either for software patent or for
convenience reasons. Or maybe it would have gone against the usability of ad
networks if you could deny the virtual Golf app access to GPS and internet...

~~~
fpgeek
Asking on-demand for everything lands you in the usability mess that is
Vista's UAC.

There are plenty of places where permissions should be more fine-grained, but
doing that in a usable way is not easy. Personally, I'd like to see a
distinction between "required" and "optional" permissions (with always deny,
prompt and always grant alternatives for optional ones). Of course, there
would still be a lot of tricky issues to sort out (e.g. how do you encourage
developers to expose some permissions as optional not required?), but I think
that exposing more permissions for direct user management, while trying to
minimize the effort required might might strike a better balance over the long
run.

~~~
ge0rg
_Asking on-demand for everything lands you in the usability mess that is
Vista's UAC._

Please let me clarify: a properly designed system should allow the user to
"always grant" that one permission to that one app, so the total number of
permissions dialog goes from 1 per app to N per app with N=number of required
permissions. The advantage would be, that opposed to Windows (where you only
grant one rather opaque "Administrator" permission) you will see how your
current action caused the permission request.

To come back to my example: you tap on the contact shortcut on your desktop,
and Android asks you:

"Launcher requests the permission to perform a (possibly billed) phone call.
[Grant] [Grant always] [Deny] [Deny always]"

Of course this model does not work for all possible permissions and
applications, but it is still a vast improvement over what we have now.

~~~
fpgeek
Oh, absolutely.

That's pretty much the model I was trying to suggest as well, with the extra
detail that users only get that prompt for "optional" permissions. "required"
permissions (e.g. a browser accessing the Internet) would still be take-it-or-
leave-it at installation.

Though, thinking back to a Google+ post by a member of the Android team that I
don't have at hand right now, there's also a place for self-certifying UI
elements. IIRC, their example was a system-provided Contacts widget (where if
you selected a contact using that widget from within an app, you were clearly
giving the app access to that contact data). My favorite example is the crash
reporter. If click the "Send Crash Report" button, you're clearly giving
permission to share some, potentially private, data about the crash (and
sharing even more if you also check off sending the crash log). When you can
pull off those sorts of UI elements, it is ideal, but they're not general
enough for everything.

------
forgotusername
Big horking one missing from the list: run native code.

From here you can pretty much do anything, since the average handset is
shipped with an ancient buggy kernel.

The short answer remains: treat software on Play with the same distrustful
contempt you would treat random no-name desktop software found in the dark
corners of the Internet.

~~~
huggyface
Can you qualify this? Native code is sandboxed just as managed code is (of
course it is). Ancient buggy kernel? Most handsets have very contemporary
kernels.

But surely you will provide some compelling citations.

~~~
ge0rg
Basically every device for which some kind of rooting tool exists is
vulnerable.

It is not too hard to leverage the same exploit used by rooting tools to
circumvent the UID based sandbox and to access the data of other applications,
including the phone book, security tokens / passwords stored in
SharedPreferences etc.

~~~
saurik
However, with a buggy kernel, you don't necessarily need native code to
perform the exploit: you just need access to whatever part of the kernel that
has the bug (which is often something innocuous). If there is a bug in the
filesystem driver where attempting to open file descriptor to paths larger
than 1024 bytes long will cause a buffer overflow, I can exploit that just as
easily from Java as I could from C.

------
bostonvaulter2
Wow, I did not realize that "no-permission" apps can read any file on the SD
Card, I thought they at least needed the standard SD Card permission which I
now realize is just SD Card write. I think that Android should implement some
path-based security on the SD Card, although I guess that might be hard with
their current model where I don't think any of the permissions have any
arguments.

~~~
TazeTSchnitzel
Problem with the SD Card is, AFAIK (might be wrong here) it's FAT formatted,
so unless Android adds a security layer on top, there's no file permissions
system.

------
omgtehlion
What can you read on a page with a tiny grey font?

~~~
bostonvaulter2
You should try out Readability: <http://www.readability.com/bookmarklets>

~~~
omgtehlion
Thank you. But original question still stands...

~~~
silon3
This is why Firefox with Zoom Text Only is the best browser.

~~~
mverwijs
You, madam/sir, are awesome. Thank you for this.

------
biafra
There is another way to transfer the data off the device. You can make another
app, that has the same sharedUserId and that app has the internet permission.
That app can see the data of the non-permission app and send the collected
data via its internet permission anywhere. Apps with a sharedUserId have the
super set of permissions of all apps they share the user id with. The user
does not see that when installing either app.

------
gwern
> What can be done with the data once it’s collected? Without the INTERNET
> permission, how can it be sent anywhere? While it's true that most network
> access is restricted, there is one network call that can be made without any
> permissions: the URI ACTION_VIEW Intent opens a browser. By passing data via
> GET parameters in a URI, the browser will exfiltrate any collected data. In
> my tests, I found that the app is able to launch the browser even after it
> has lost focus, allowing for transmission of large amounts of data by
> creating successive browser calls.

Reminds me of ping tunnels: <http://en.wikipedia.org/wiki/ICMP_tunnel>

------
Tichy
I suppose not using any apps at all is the only option at this point :-(

~~~
saurik
Your desktop/laptop has survived without anally granular sandboxing since the
day you started using computers, and you've been using apps from all sorts of
places (web browsers, plugins, text editors, games) without serious concern.
Yes: you shouldn't install apps from people whom you don't feel some reason to
trust, but that's always been the case (and seemingly always will, as no one
has so far managed to build a sandbox that a teenager hasn't been able to
break out of in a few days; Chrome's sandbox, for example, had two unrelated
escapes come to light during the recent Pwnium contest).

~~~
Tichy
Well I had serious concern for my desktop. Games are on an extra computer, and
the OS tends to be Linux (preferred) or OS X (grudgingly). Most people's
desktops are in fact completely overrun by malware, too. Just look at your
relatives computers the next holiday.

~~~
saurik
Those people also tend to get phished, or open email attachments with .exe
extensions. If you buy a game from Best Buy and there is malware in it,
someone will have some hell to pay. Lumping together "software I buy from
people I've heard of" into the same category as "people get lots of malware"
is just fear mongering.

------
lini
The browser hack is not something new. I remember an article from last year,
which showed how to get remote shell with a no-permissions app -
[https://viaforensics.com/security/nopermission-android-
app-r...](https://viaforensics.com/security/nopermission-android-app-remote-
shell.html)

~~~
dfc
Did you bother to read the article before commenting? Sentences six and seven:

 _"Some previous work had been demonstrated by Thomas Cannon of viaForensics.
I wanted to develop that work further through a discussion backed by source
code."_

------
gcardone
Accessing the accelerometer requires no permissions but can be used in a
twisted way: by training machine learning algorithm, accelerometer data can be
used to infer keystrokes. The state of the art of this attack is this:
[http://www.research.att.com/~miluzzo/pubs/sys015fp-
miluzzo-A...](http://www.research.att.com/~miluzzo/pubs/sys015fp-miluzzo-
ABSTRACT.pdf) (to appear in MobiSys '12, full paper available to general
public in June). A simpler attack can be found here:
<http://www.hotmobile.org/2012/papers/HotMobile12-final42.pdf> .

------
lucian1900
And desktop apps can do much more without requiring any permissions at all.

While it would be great to have more secure apps everywhere, panicking about
it, as has been so common in the media lately, is pointless.

~~~
icebraining
There's a point to be made about expectations, though. On a desktop by default
you know that apps can do whatever they want, but on an OS with a built-in
sandbox and permissions like "internet", you expect it to not be able to
access the internet. That may lead to changes in your behavior, like
installing any random app with no permissions instead of carefully evaluating
them beforehand.

------
readme
The web browser hack for uploads has been known for over two years and was
made public at DEFCON

[http://www.defcon.org/images/defcon-18/dc-18-presentations/L...](http://www.defcon.org/images/defcon-18/dc-18-presentations/Lineberry/DEFCON-18-Lineberry-
Not-The-Permissions-You-Are-Looking-For.pdf)

See page 32

Also, I'd like to add that saying the ability to list packages on the device
is a security risk is just silly. That's like saying a Linux box is vulnerable
because I can list /usr.

------
woodall
Reminds me of directory traversal on regular systems[1]. Zip up what ever you
find, base64 encode it and send it to some shady server for later harvesting.

[1] <http://news.ycombinator.com/item?id=2691088>

------
drucken
_While it's true that most network access is restricted, there is one network
call that can be made without any permissions: the URI ACTION_VIEW Intent
opens a browser._

Android has no "Trust Links" permission?

