Dailydave mailing list archives
Re: Android Attacks Slides
From: r3dRAND <r3drand () gmail com>
Date: Thu, 5 Apr 2012 18:06:30 -0400
Does that imply that if an app requests a non-existent permission, say, "TELEPATHY_SEND_RCV", then it will be silently accepted. Then, if Android 6 supports that permission and the user upgrades the OS, the app would execute with that permission w/o any confirmation? On Apr 2, 2012, at 4:46 PM, Tim <tvidas () 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 () 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 () lists immunityinc com https://lists.immunityinc.com/mailman/listinfo/dailydave_______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com https://lists.immunityinc.com/mailman/listinfo/dailydave
_______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com https://lists.immunityinc.com/mailman/listinfo/dailydave
Current thread:
- Android Attacks Slides Jeffrey Walton (Apr 02)
- Re: Android Attacks Slides Bas Alberts (Apr 03)
- Re: Android Attacks Slides Tim (Apr 03)
- Re: Android Attacks Slides James Manico (Apr 03)
- Re: Android Attacks Slides Jeffrey Walton (Apr 05)
- Re: Android Attacks Slides Dean Pierce (Apr 05)
- Re: Android Attacks Slides James Manico (Apr 03)
- Re: Android Attacks Slides r3dRAND (Apr 05)
- Re: Android Attacks Slides Moxie Marlinspike (Apr 05)