Achieving Android Permissions Security Enlightenment

Tyrone Erasmus, Managing Consultant
August, 2013
10 mins read

Permissions are the basis of application security on Android and come with their own complexities.

Permissions are the basis of all application security on an Android device and can come with their own set of complexities to be aware of. Developers for Play Store and OEM applications very seldom make full use of the application security features available on the Android platform.


The majority of security-related Android media articles talk about malware that has been discovered or offer statistics relating to malware on the platform. A large percentage of these malware cases are simply requesting the appropriate permission to perform their misdeed. Whether it is requesting the READ_SMS permission in order to suck out all of your juicy SMSmessages or the SEND_SMS permission in order to send SMS messages to premium rate services, the word “permission” appears often when reading about Android security. This piece will discuss the more technical details of permissions security and describe how to secure your application’s endpoints with strong security configuration.


Interacting with Permissions

Users typically only interact with permissions, or are made aware of them, when installing new applications on their device. On these occasions, an activity is presented to the user that displays the permissions that the application is requesting. The permissions screen for the Twitter application looks like this:

The developer or security tester who had to look at the AndroidManifest.xml file associated with this application would see the XML describing the defined and requested permissions for the application. The way that a tester could map permissions names to more detailed descriptions of what they are for is by implementing the following code in Mercury (or slightly modified in a standalone application):


packageManager = self.getContext().getPackageManager()

info = packageManager.getPermissionInfo("android.permission.ACCESS_FINE_LOCATION", 0)

print self.getContext().getResources().getString(info.descriptionRes)


This reads the description attribute of the permission and effectively maps the permission named android.permission.ACCESS_FINE_LOCATION to its description: “Access precise location sources such as the Global Positioning System on the phone. When location services are available and turned on, this permission allows the app to determine your precise location.”


The risk to the user associated with each of these requested permissions, and the ability of other applications to request this permission, is defined by an attribute of the permission called its protectionLevel. These attributes can be seen in the above image at the top of the snippet of the Twitter application’s manifest. Each defined permission has an associated protectionLevel. This attribute can only be set by the application that originally created the permission, in its AndroidManifest.xml file.


Based on the protection level of a permission, it may be displayed in the installation review screen as part of the hidden dropdown menu or more prominently displayed if it could pose a threat to privacy. It should be noted that this “risk rating” assignment is at the discretion of the application that defined the permission.

Protection Levels can be one of four following values:

  • normal (0×0) – the default value for a permission
  • dangerous (0×1) – indicates that this permission has the ability to access some potentially sensitive information or perform actions on the device
  • signature (0×2) – indicates that this permission can only be granted to another application that was signed with the same certificate as the application that defined the permission
  • signatureOrSystem (0×3) – this is the same as the signature protection level, except that the permission can also be requested by an application that came with the Android system image


Play Store applications that do not have any intention of sharing their data or functionality with applications from other developers should always define permissions with the signature protection level. This ensures that a malicious application cannot request this permission. This does not affect the application’s ability to integrate or communicate with other applications created by the same developer, as these applications would be signed with the same certificate.


An examination of the Twitter application’s manifest reveals that all except one permission defined by the application make use of the signature protection level. The permission named makes use of the dangerous protection level. This means that another application could successfully request this permission and access functionality on the Twitter application that requires it. This in itself does not constitute a risk: the functionality exposed to other applications that could attain this permission would have to be examined for its implications to be known.


Requesting Permissions

A developer should always think about the permissions they are requesting and whether they are absolutely necessary. To illustrate the differences between a normal approach and a conservative security-driven approach to requesting permissions, consider a telephone directory application.


This application allows a user to search for telephone numbers of local businesses and then save these numbers to the user’s contact list. The normal approach to this would be to request the WRITE_CONTACTS permission and simply add the contact directly to the user’s contacts database. A more conservative approach would be to start the ContactEditorActivity with the information pre-populated. This is possible because of the flexible and modular IPC framework provided by Android. To test this approach to the problem, issue the following command indrozer which will start ContactEditorActivity without requiring any application permissions:


dz> run app.activity.start --action android.intent.action.INSERT --mimetype --extra string name "MWR InfoSecurity" --extra string phone +123456789


This simple example demonstrates that there is often more than one way of performing a task, in order to give the user of the application a greater degree of control over what is happening on their device. This also reduces the required permissions and therefore reduces the impact of exploiting this application. A general rule of thumb is that the more permissions that an application holds, the higher the impact of exploiting it becomes. If an application makes use of more permissions with a protection level of dangerous, then an application could access user data or perform actions on the device. This behaviour may catch the attention of attackers or could scare away potential users.


Some permissions held by an application have greater implications than others. Naturally, a permission that allows an application to read sensitive data, such as SMS messages and emails, has a greater impact on privacy than a permission that allows an application to collect battery statistics. In the same way, some permissions could help an attacker to compromise all of the data on the phone. One such permission is the INSTALL_PACKAGES permission.


The INSTALL_PACKAGES permission allows an application to install another Android package. Therefore, if an application holding this permission is exploited by a malicious entity, they could use it to install a Trojan application on the device with almost any permissions. It should be noted that only applications that come as part of the Android system image or signed by the same certificate as the “android” package can request this permission.


In many cases, phone vendors do not thoroughly vet which applications hold this permission on their devices and in the past MWR has found applications like document readers and web browsers holding this permission. This is a very dangerous practice that should be avoided. In general, an application that makes use of native code should not hold the INSTALL_PACKAGES permission. When using native code, there is significant potential for bugs which can allow the control of execution, and, combining this with the INSTALL_PACKAGES permission, can result in the installation of attacker-defined packages.


Reviewing Application Permissions

If insufficient security configuration is placed on applications that hold sensitive data, then a malicious or compromised application could gain access to this data. A security tester could look for the following, in terms of security on IPC endpoints (activities, broadcast receivers, services and content providers):

  • Endpoints that are not protected by permissions.
    In the past, MWR discovered many Play Store and OEM applications that made no use use of permissions on exported endpoints whatsoever. We have started to see developers adequately protecting their content providers with permissions. However, often services and broadcast receivers are insufficiently protected
  • Endpoints that make use of custom-defined permissions, but the protectionLevel is set to normal or dangerous.
    This means that another application could successfully request this permission and have access to the data or functionality exposed by the endpoint. Developers making use of URIpermissions on content providers should also keep in mind that an appropriate protection level on the specified permission is important. There is more information about URI permissions in the references section


When reviewing a device, a security tester should bear in mind that there are some permissions that they would not have dealt with before, when assessing Play Store applications. Some permissions are unattainable for normal applications that do not come pre-installed on devices or are not signed by the same certificate as the “android” package (usually signed by Google but sometimes also modified by OEMs). Examples of some of these powerful permissions that use the signatureOrSystem protection level are:

  • INSTALL_PACKAGES – allows the app to install new or updated Android packages. Malicious apps may use this to add new apps with arbitrarily powerful permissions
  • INJECT_EVENTS – allows the app to deliver its own input events (key presses, etc.) to other apps
  • READ_FRAME_BUFFER – allows the app to read the content of the frame buffer (i.e. take a screenshot of the device)


Exploiting an application that holds one of these permissions could allow an attacker a great degree of control over the device and therefore over its data.



  • Protect all exported IPC endpoints (activities, broadcast receivers, services and content providers) with well-configured custom permissions
    OEM developers should never make use of native code inside their application, if it holds the INSTALL_PACKAGES permission. This is because, if the application is exploitable, it could result in the installation of arbitrary packages on the user’s device
  • When defining custom permissions, use a protectionLevel of signature wherever possible. The proper use of protection levels can provide an extra layer of security for the application
  • Applications should ask for the absolute minimum required permissions. This reduces the impact of exploiting the application and could help ease the concerns of security-conscious users
Accreditations & Certificates

F-Secure Consulting (F-Secure Cyber Security (Pty) Ltd) is a level 4 contributor to B-BBEE with a procurement recognition level of 100%. Learn more and download our B-BBEE certificate. Click here to read the press release.

Follow us
@fsecure_consult F-Secure-Consulting f-secure-foundry fsecurelabs