[Dailydave] Android Attacks Slides

[Jeffrey Walton]

Hey Jim -

Good to see you out and about.

On Tue, Apr 3, 2012 at 11:26 AM, James Manico <jim at manico.net> wrote:
> Even though the Android permission model may be granular, given your
> perspective, Android users do not have the option of •accepting•
> permissions on a granular basis.
Take a look at PHONE_READ_STATE and see the the bug report "Android
Permission: 'Phone Calls' Permission is Overly Permissive,"
http://code.google.com/p/android/issues/detail?id=24104.

The folks at the NSA also pointed out coarse grained permissions in
their slides introducing SE Android
(http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf).
Its too bad the remediation was not incorporated in the project (I
just about begged for it)
(http://www.mail-archive.com/funsec@linuxbox.org/msg17266.html).

Even marketing and media managers know there is a problem with
permission granularity: "Company at centre of Android apps scare
responds," http://www.cbronline.com/blogs/cbr-rolling-blog/company-at-centre-of-android-apps-scare-responds-080312.

At least Android fixed the description (???). It used to include "and
the like" (http://code.google.com/p/android/issues/detail?id=24103):

    Allows the application to access the phone features of the device. An
    application with this permission can determine the phone number and
    serial number of this phone, whether a call is active, the number that
    call is connected to and the like.

> You must accept them all or bail;
> and for this I feel the model is a fail.
Yes, most definitely. And there is nothing to revoke a permission
after installation. But that's a different complaint (err, story).

Jeff

> On Apr 3, 2012, at 11:17 AM, Tim <tvidas at gmail.com> wrote:
>
>> The "fine" vs "coarse" grained is somewhat subjective given the
>> various resources available on a device, but level of granularity
>> certainly varies across the permissions.  One that is often cited as
>> too coarse is "INTERNET" where many suggest limiting apps more finely
>> to particularly domains or hierarchical models.  Text messaging has
>> several, more granular permissions dividing access among sending,
>> receiving, reading, and writing for each of SMS and MMS (which some
>> will argue could be even more granular limiting access to certain
>> contacts, country codes, non-premium numbers, etc).
>>
>> The "borking" you refer to at the end is an interesting problem.
>> Originally there were many fewer permissions than there are now, so
>> what should happen when a new permission is specified by an app and
>> that app is installed on an old device?  The older OS doesn't know
>> anything about the new permission nor how to enforce it, so a design
>> decision was made to silently ignore the permission request.  There
>> are also odd situations with the UI.  For example, when you install
>> the app, it will list the permissions that the OS supports, but
>> post-install if you inspect the app via the Applications menu in
>> Settings it will list the permissions found in the app manifest.  So
>> in the stackoverflow example you linked, at install time you would not
>> see the WRITE_EXTERNAL_STORAGE permission but when inspecting the app
>> via Settings on the same device you would (this behavior may vary
>> based on API version - I have not checked them all).
>>
>> Alternate design decisions could have been made, for example the
>> installer could refuse to install apps that specify unknown
>> permissions in the manifest.  In this case developers would have to
>> support an app for old devices that are unaware of
>> WRITE_EXTERNAL_STORAGE (a request for this permission is not needed
>> anyway because the OS cannot enforce it), and also a nearly identical
>> app that does specify the permission for newer devices.  For about 1
>> year now, the Android Market (now Google Play) has supported this
>> split-distribution model where the appropriate variant of the app is
>> delivered to a device - but it is still fairly annoying for the
>> developer.  Many apps are poorly written with manifests that specify
>> the same permission multiple times, misspell permissions or even
>> specify permissions that have never existed.  An installer that
>> doesn't install apps with unknown permissions would at least force
>> some of these practices to clean up.
>>
>> The situation is, of course, worsened by the lagging / nonexistent
>> Android OS updates, the relatively short supported lifespan of
>> devices, and alternative app sources.
>>
>> -tim
>>
>> On Fri, Mar 30, 2012 at 5:50 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>>> Hi Guys,
>>>
>>> Android Attacks (Bas Alberts/Massimiliano Oldani),
>>> http://www.immunityinc.com/infiltrate/2011/presentations/Android_Attacks.pdf.
>>>
>>> Perhaps I'm reading Slide 15 wrong:
>>>
>>>    Fine grained Permission/Capability model
>>>        ● Per installed Application (Manifest)
>>>        ● Per URI (Intent permission flags)
>>>
>>> I believe Android lacks Fine Grained permissions:
>>>
>>> Felt, Adrienne Porte; Chin, Erika; Hanna, Steve; Song, Dawn; Wagner,
>>> David. "Android Permissions Demystified,"
>>> http://www.cs.berkeley.edu/~afelt/android_permissions.pdf.
>>> Jeon, Jinseong; Micinski, Kristopher K.; Vaughan, Jeffrey A.; Reddy,
>>> Nikhilesh; Zhu, Yixin; Foster, Jeffrey S.; Millstein, Todd." Dr.
>>> Android and Mr. Hide: Fine-grained security policies on unmodified
>>> Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf.
>>>
>>> In fact, the permissions are so coarse grained and borked that Google
>>> was giving everone READ_PHONE_STATE whether they wanted it or not (the
>>> practice has been changed). And READ_PHONE_STATE  includes call
>>> status, incoming number, identity iformation such as IMSI, etc. See
>>> "Android permissions: Phone Calls: read phone state and identity,"
>>> http://stackoverflow.com/questions/1747178/android-permissions-phone-calls-read-phone-state-and-identity.