[Dailydave] Android Attacks Slides
James Manico
jim at manico.net
Tue Apr 3 11:26:24 EDT 2012
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.
You must accept them all or bail;
and for this I feel the model is a fail.
--
Jim Manico
VP, Security Architecture
WhiteHat Security
(808) 652-3805
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.
>>
>> Jeff
>> _______________________________________________
>> Dailydave mailing list
>> Dailydave at lists.immunityinc.com
>> https://lists.immunityinc.com/mailman/listinfo/dailydave
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
More information about the Dailydave
mailing list