This section takes a closer look at the most security-relevant pieces of the Android software stack, including applications, the Android framework, the DalvikVM, supporting user-space native code and associated services, and the Linux kernel.
This will help set the stage for later chapters, which will go into greater detail about these components. This will then provide the knowledge necessary to attack those components.
Android Applications
In order to understand how to evaluate and attack the security of Android applications, you fi rst need to understand what they’re made of. This section discusses the security-pertinent pieces of Android applications, the application runtime, and supporting IPC mechanisms. This also helps lay the groundwork for Chapter 4.
Applications are typically broken into two categories: pre-installed and user-installed. Pre-installed applications include Google, original equipment manu-facturer (OEM), and/or mobile carrier-provided applications, such as calendar, e-mail, browser, and contact managers. The packages for these apps reside in the /system/app directory. Some of these may have elevated privileges or capabili-ties, and therefore may be of particular interest. User-installed applications are those that the user has installed themselves, either via an app market such as Google Play, direct download, or manually with pm install or adb install. These apps, as well as updates to pre-installed apps, reside in the /data/app directory.
Android uses public-key cryptography for several purposes related to applica-tions. First, Android uses a special platform key to sign pre-installed app packages.
Applications signed with this key are special in that they can have system user privileges. Next, third-party applications are signed with keys generated by individual developers. For both pre-installed and user-installed apps, Android uses the signature to prevent unauthorized app updates.
Major Application Components
Although Android applications consist of numerous pieces, this section highlights those that are notable across most applications, regardless of the targeted version of Android. These include the AndroidManifest, Intents, Activities, BroadcastReceivers, Services, and Content Providers. The latter four of these components represent IPC endpoints, which have particularly interesting security properties.
AndroidManifest.xml
All Android application packages (APKs) must include the AndroidManifest .xml fi le. This XML fi le contains a smorgasbord of information about the appli-cation, including the following:
■ Unique package name (e.g., com.wiley.SomeApp) and version information
■ Activities, Services, BroadcastReceivers, and Instrumentation defi nitions
■ Permission defi nitions (both those the application requests, and custom permissions it defi nes)
■ Information on external libraries packaged with and used by the application
■ Additional supporting directives, such as shared UID information, pre-ferred installation location, and UI info (such as the launcher icon for the application)
One particularly interesting part of the manifest is the sharedUserId attri-bute. Simply put, when two applications are signed by the same key, they can specify an identical user identifi er in their respective manifests. In this case, both applications execute under the same UID. This subsequently allows these apps access to the same fi le system data store, and potentially other resources.
The manifest fi le is often automatically generated by the development envi-ronment, such as Eclipse or Android Studio, and is converted from plaintext XML to binary XML during the build process.
Intents
A key part of inter-app communication is Intents. These are message objects that contain information about an operation to be performed, the optional target component on which to act, and additional fl ags or other supporting information (which may be signifi cant to the recipient). Nearly all common actions—such as
tapping a link in a mail message to launch the browser, notifying the messaging app that an SMS has arrived, and installing and removing applications—involve Intents being passed around the system.
This is akin to an IPC or remote procedure call (RPC) facility where applica-tions’ components can interact programmatically with one another, invoking functionality and sharing data. Given the enforcement of the sandbox at a lower level (fi le system, AIDs, and so on), applications typically interact via this API.
The Android runtime acts as a reference monitor, enforcing permissions checks for Intents, if the caller and/or the callee specify permission requirements for sending or receipt of messages.
When declaring specifi c components in a manifest, it is possible to specify an intent fi lter, which declares the criteria to which the endpoint handles. Intent fi lters are especially used when dealing with intents that do not have a specifi c destination, called implicit intents.
For example, suppose an application’s manifest contains a custom permission com.wiley.permission.INSTALL_WIDGET, and an activity, com.wiley.MyApp .InstallWidgetActivity, which uses this permission to restrict launching of the InstallWidgetActivity:
<manifest android:versionCode="1" android:versionName="1.0"
package="com.wiley.MyApp"
...
<permission android:name="com.wiley.permission.INSTALL_WIDGET"
android:protectionLevel="signature" />
...
<activity android:name=".InstallWidgetActivity"
android:permission="com.wiley.permission.INSTALL_WIDGET"/>
Here we see the permission declaration and the activity declaration. Note, too, that the permission has a protectionLevel attribute of signature. This limits which other applications can request this permission to just those signed by the same key as the app that initially defi ned this permission.
Activities
Simply put, an Activity is a user-facing application component, or UI. Built on the base Activity class, activities consist of a window, along with pertinent UI elements. Lower-level management of Activities is handled by the appropriately named Activity Manager service, which also processes Intents that are sent to invoke Activities between or even within applications. These Activities are defi ned within the application’s manifest, thusly:
...
<activity android:theme="@style/Theme_NoTitle_FullScreen"
android:name="com.yougetitback.androidapplication.ReportSplashScreen"
android:screenOrientation="portrait" />
<activity android:theme="@style/Theme_NoTitle_FullScreen"
android:name="com.yougetitback.androidapplication.SecurityQuestionScreen"
android:screenOrientation="portrait" />
<activity android:label="@string/app_name"
android:name="com.yougetitback.androidapplication.SplashScreen"
android:clearTaskOnLaunch="false" android:launchMode="singleTask"
android:screenOrientation="portrait">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
</intent-filter>
...
Here we see activities, along with specifi ers for style/UI information, screen orientation, and so on. The launchMode attribute is notable, as it affects how the Activity is launched. In this case, the singleTask value indicates that only one instance of this particular activity can exist at a time; as opposed to launching a separate instance for each invocation. The current instance (if there is one) of the application will receive and process the Intent which invoked the activity.
Broadcast Receivers
Another type of IPC endpoint is the Broadcast Receiver. These are commonly found where applications want to receive an implicit Intent matching certain other criteria. For example, an application that wants to receive the Intent asso-ciated with an SMS message would register a receiver in its manifest with an intent fi lter matching the android.provider.Telephony.SMS_RECEIVED action:
<receiver android:name=".MySMSReceiver">
<intent-filter android:priority:"999">
<action android:name="android.provider.Telephony.SMS_RECEIVED" />
</intent-filter>
</receiver>
N O T E Broadcast Receivers may also be registered programmatically at runtime by using the registerReceiver method. This method can also be overloaded to set permission restrictions on the receiver.
Setting permission requirements on Broadcast Receivers can limit which applications can send Intents to that endpoint.
Services
Services are application components without a UI that run in the background, even if the user is not interacting directly with the Service’s application. Some examples of common services on Android include the SmsReceiverService and the BluetoothOppService. Although each of these services runs outside of the user’s direct view, like other Android app components they can take advantage of IPC facilities by sending and receiving Intents.
Services must also be declared in the application’s manifest. For example, here is a simple defi nition for a service also featuring an intent fi lter:
<service
android:name="com.yougetitback.androidapplication.FindLocationService">
<intent-filter>
<action
android:name="com.yougetitback.androidapplication.FindLocationService" />
</intent-filter>
</service>
Services can typically be stopped, started, or bound, all by way of Intents. In the lattermost case, binding to a service, an additional set of IPC or RPC proce-dures may be available to the caller. These proceproce-dures are specifi c to a service’s implementation, and take deeper advantage of the Binder service, discussed later in the “Kernel” section of the chapter.
Content Providers
Content Providers act as a structured interface to common, shared data stores.
For example, the Contacts provider and Calendar provider manage centralized repositories of contact entries and calendar entries, respectively, which can be accessed by other applications (with appropriate permissions). Applications may also create their own Content Providers, and may optionally expose them to other applications. The data exposed by these providers is typically backed by an SQLite database or a direct fi le system path (for example, a media player indexing and sharing paths to MP3 fi les).
Much like other app components, the ability to read and write Content Providers can be restricted with permissions. Consider the following snippet from an example AndroidManifest.xml fi le:
<provider android:name="com.wiley.example.MyProvider"
android:writePermission="com.wiley.example.permission.WRITE"
android:authorities="com.wiley.example.data" />
The application declares a provider, named MyProvider, which corre-sponds to the class implementing the provider functionality. Then it declares a writePermission of com.wiley.example.permission.WRITE, indicating that only apps bearing this custom permission can write to this provider. Finally,
it specifi es the authorities or content uniform resource identifi er (URI) that this provider will act for. Content URIs take the form of content://[authori-tyname]/ and may include additional path/argument information, possibly signifi cant to the underlying provider implementation (for example, content://
com.wiley.example.data/foo).
In Chapter 4, we demonstrate a means of discovering and attacking some of these IPC endpoints.