l20-android.html

<h1>Android security</h1>

<p><strong>Note:</strong> These lecture notes were slightly modified from the ones posted on the 6.858 <a href="http://css.csail.mit.edu/6.858/2014/schedule.html">course website</a> from 2014.</p>

<h2>Why <a href="http://css.csail.mit.edu/6.858/2014/readings/android.pdf">this</a> paper?</h2>

<ul>
<li>Real system, widely used.</li>
<li>Careful security design (more so than for web or desktop applications).
<ul>
<li>Principals = Applications (not users)</li>
<li>Policy separate from code (manifests)</li>
</ul></li>
<li>Some problems inevitable, and instructive to see where problems come up.</li>
<li>But also interesting to see how to design a reasonable security plan.</li>
</ul>

<h2>Threat model</h2>

<ul>
<li><strong>Goal:</strong> Anyone can write an app that anyone can install</li>
<li><strong>Threats:</strong>
<ul>
<li>Apps may have bugs</li>
<li>Apps may be malicious</li>
</ul></li>
</ul>

<p>CVE database</p>

<ul>
<li><a href="http://css.csail.mit.edu/6.858/2014/readings/android.pdf">http://www.cvedetails.com/vulnerability-list/vendor<em>id-1224/product</em>id-19997/Google-Android.html</a></li>
<li>Some bugs but not overwhelming---is the security plan working?
<ul>
<li>Buffer overrun (still happens ....)</li>
</ul></li>
<li>Of course, Android runs on Linux, and this includes Linux kernel problems</li>
</ul>

<p>Overall plan</p>

<ul>
<li>First understand how Android applications look like and work.</li>
<li>Then discuss security mechanisms and policies.</li>
</ul>

<h2>What does an Android application look like?</h2>

<ul>
<li>Four types of components:
<ul>
<li><strong>Activity:</strong> UI component of app, typically one activity per "screen".</li>
<li><strong>Service:</strong> background processing, can be invoked by other components.</li>
<li><strong>Content provider:</strong> a SQL database that can be accessed by other components.</li>
<li><strong>Broadcast receiver:</strong> gets broadcast announcements from other components.</li>
</ul></li>
<li>Each application also has private file storage.</li>
<li>Application typically written in Java.</li>
<li>Runs on a Linux kernel + Android "platform" (will get to it shortly).</li>
<li>Application also has a manifest declaring its permissions (later).</li>
<li>Entire application is signed by the developer.</li>
</ul>

<h3>Activity: can draw on the screen, get user input, etc.</h3>

<ul>
<li>Only one activity is running at a time.</li>
<li>Helps users reason about security of inputs.</li>
<li>If user is running bank app (activity), no other activity gets user's input.</li>
</ul>

<h3>Intent: basic messaging primitive in Android.</h3>

<ul>
<li>Represents app's intent to do something / interact with another component.</li>
</ul>

<h4>Intent fields:</h4>

<ul>
<li>Component: name of component to route the request to (just a string).
<ul>
<li>E.g., <code>com.google.someapp/ComponentName</code></li>
</ul></li>
<li>Action: the opcode for this message (just a string).
<ul>
<li>E.g., <code>android.intent.action.MAIN</code>, <code>android.intent.action.DIAL</code>, ...</li>
</ul></li>
<li>Data: URI of data for the action (just a string).
<ul>
<li>E.g., <code>tel:16172536005</code>, <code>content://contacts/people/1</code> (for DIAL).</li>
<li>Also includes the MIME type of the data.</li>
</ul></li>
<li>Category: a filtering mechanism for finding where to send intent.
<ul>
<li>E.g., <code>android.intent.category.BROWSABLE</code> means safe to invoke from browser,
for action <code>android.intent.action.VIEW</code>, which views the URI in data.</li>
</ul></li>
<li>Explicit intents: component name specified.</li>
<li>Implicit intents: no component name, so the system must figure it out.
<ul>
<li>Looks at action, data, category.</li>
<li>Could also ask the user what app to use, if multiple components match.</li>
<li>E.g., user clicks on an address -- what map application to open?</li>
</ul></li>
</ul>

<h3>RPC to services</h3>

<ul>
<li>Initial communication to a service happens by sending an intent.</li>
<li>Service can also define an RPC protocol for clients to use.
<ul>
<li>More efficient than sending intents each time.</li>
<li>Client "binds" a connection to a service.</li>
</ul></li>
</ul>

<h3>Networking -- accessing the Internet.</h3>

<ul>
<li>Work just as in any other Linux system.</li>
<li>Application can use sockets directly, or via Java's networking libraries.</li>
</ul>

<h2>Why do we need a new app model?  (Or, what's wrong with existing models?)</h2>

<ul>
<li>Desktop applications:
<ul>
<li><strong>--</strong> Not much isolation between applications.</li>
<li><strong>--</strong> Every app has full privileges, any one malicious app can take over.</li>
<li><strong>++</strong> Applications can easily interact with one another, share files.</li>
<li><strong>++</strong> User can choose app for each task (email app, image viewer, etc).</li>
</ul></li>
<li>Web/browser-based applications:
<ul>
<li><strong>++</strong> No need to install applications or worry about local state.</li>
<li><strong>--</strong> Requires a server in the typical model (hard to use offline).</li>
<li><strong>--</strong> Limited interactions between applications.</li>
<li><strong>--</strong> Interactions that do exist are typically hard-wired to particular URLs.
<ul>
<li>E.g., links to a contact manager app's URL: user cannot choose new one.</li>
<li>Getting better: "Web intents" are trying to solve this problem.</li>
</ul></li>
<li><strong>--</strong> Somewhat limited functionality for purely client-side applications.
<ul>
<li>Getting better: camera, location info, local storage, worker threads, ..</li>
</ul></li>
</ul></li>
</ul>

<h2>Android access control</h2>

<h3>How does Android's application model handle app interaction, user choosing app?</h3>

<ul>
<li>Mostly based on intents.</li>
<li>If multiple apps could perform an operation, send implicit intent.</li>
<li>Android framework decides which app gets the intent; could ask user.</li>
</ul>

<h3>How does Android's application model handle app isolation?</h3>

<ul>
<li>Each application's processes run under a separate UID in Linux.
<ul>
<li>Exception: one developer can stick multiple applications into one UID.</li>
</ul></li>
<li>Each application gets its own Java runtime (but that's mostly by convention).</li>
<li>Java interpreter not trusted or even required; kernel enforces isolation.</li>
</ul>

<h3>What are per-app UIDs good for?</h3>

<ul>
<li>One app cannot directly manipulate another app's processes, files.</li>
<li>Each app has private directory (<code>/data/data/appname</code>).
<ul>
<li>Stores preferences, sqlite DBs for content providers, cached files, etc.</li>
</ul></li>
</ul>

<h3>What's missing from UID isolation: access control to shared resources.</h3>

<ul>
<li>Network access.</li>
<li>Removable sd card.</li>
<li>Devices (camera, compass, etc).</li>
<li>Intents: who can send, what intents, to whom?</li>
<li>And we also need to somehow determine the policy for all of this.</li>
</ul>

<h3>First, mechanism: how does Android control access to all of the above?</h3>

<ul>
<li>Network access: GIDs.
<ul>
<li>Special group IDs define what apps can talk to the network.
<ul>
<li>GID <code>AID_NET_BT_ADMIN (3001)</code>: can create low-level bluetooth sockets</li>
<li>GID <code>AID_NET_BT       (3002)</code>: can create bluetooth socket</li>
<li>GID <code>AID_INET         (3003)</code>: can create IP socket</li>
<li>GID <code>AID_NET_RAW      (3004)</code>: can create raw socket</li>
<li>GID <code>AID_NET_ADMIN    (3005)</code>: can change network config (ifconfig, ..)</li>
</ul></li>
<li>Requires kernel changes to do this.</li>
<li>Each app gets a subset of these group IDs, depending on its privileges.</li>
<li>No finer-grained control of network communication.
<ul>
<li>E.g., could have imagined per-IP-addr or per-origin-like policies.</li>
</ul></li>
</ul></li>
<li>Access to removable sd card.
<ul>
<li>Why not use file system permissions?
<ul>
<li>Want to use FAT file system on SD card, to allow access on other devices.</li>
<li>FAT file system has no notion of file ownership, permissions, etc.</li>
</ul></li>
<li>Kernel treats all SD card files as owned by special group sdcard_rw (1015).</li>
<li>Apps that should have access to SD card have this GID in their group list.</li>
<li>No finer-grained isolation within the entire SD card.</li>
</ul></li>
<li>Devices.
<ul>
<li>Device files (<code>/dev/camera</code>, <code>/dev/compass</code>, etc) owned by special groups.</li>
<li>Apps run with appropriate groups in their group list.</li>
</ul></li>
<li>Intents.
<ul>
<li>All intents are routed via a single trusted "reference monitor".</li>
<li>Runs in the system_server process.</li>
<li>Reference monitor performs intent resolution (where to send intent?),
<ul>
<li>for implicit intents.  <code>[ref: ActivityStack.startActivityMayWait]</code></li>
</ul></li>
<li>Reference monitor checks permissions, based on intent and who sent it.
<code>[ref: ActivityStack.startActivityLocked]</code></li>
<li>Routes intent to the appropriate application process, or starts a new one.</li>
</ul></li>
<li>Why not just use intents for everything, instead of special groups?
<ul>
<li>Efficiency: want direct access to camera, network, SD card files.</li>
<li>Sending everything via intents could impose significant overhead.</li>
</ul></li>
</ul>

<h3>How does the reference monitor decide whether to allow an intent?</h3>

<ul>
<li>"Labels" assigned to applications and components.
<ul>
<li>Each label is a free-form string.</li>
<li>Commonly written as Java-style package names, for uniqueness.</li>
<li>E.g., <code>com.android.phone.DIALPERM</code>.</li>
</ul></li>
<li>Each component has a single label that protects it.
<ul>
<li>Any intents to that component must be sent by app that has that label.</li>
<li>E.g., phone dialer service is labeled with <code>...DIALPERM</code>.</li>
<li>For content providers, two labels: one for read, one for write.</li>
</ul></li>
<li>An application has a list of labels it is authorized to use.
<ul>
<li>E.g., if app can dial the phone, <code>...DIALPERM</code> is in its label set.</li>
</ul></li>
<li>Other permissions (network, devices, SD card) map to special label strings.
<ul>
<li>E.g., android.permission.INTERNET translates to app running w/ GID 3003.</li>
</ul></li>
</ul>

<h3>How does an application get permissions for a certain set of labels?</h3>

<ul>
<li>Each app comes with a manifest declaring permissions (labels) the app needs.</li>
<li>Also declares the labels that should protect each of its components.</li>
<li>When app is installed, Android system asks user if it's ok to install app.</li>
<li>Provides list of permissions that the application is requesting.</li>
</ul>

<h3>At one point, Android allowed users to set fine-grained permission choices.</h3>

<ul>
<li>Android 4.3 introduced the "permission manager".</li>
<li>Apparently this was removed in Android 4.4.</li>
<li>Possible reason: developers want predictable access to things.</li>
</ul>

<h3>Who defines permissions?</h3>

<ul>
<li>Apps define permissions themselves (recall: just free-form strings).</li>
<li>Android system defines perms for built-in resources (camera, network, etc).
<ul>
<li>Can list with 'adb shell pm list permissions -g'.</li>
</ul></li>
<li>Built-in applications define permissions for services they provide.
<ul>
<li>E.g., read/write contacts, send SMS message, etc.</li>
</ul></li>
<li>Defining a permission means specifying:
<ul>
<li>User-visible name of the permission.</li>
<li>Description of the permission for the user.</li>
<li>Grouping permission into some categories (costs money, private data, etc).</li>
<li>Type of permission: "normal", "dangerous", and "signature".</li>
</ul></li>
</ul>

<h3>What do the three types of permission mean?</h3>

<ul>
<li>Normal:
<ul>
<li>Benign permissions that could let an app annoy the user, but not drastic.
<ul>
<li>E.g., <code>SET_WALLPAPER</code>.</li>
<li>diff $(pm list permissions -g -d) and $(pm list permissions -g)</li>
</ul></li>
<li>System doesn't bother asking the user about "normal" permissions.</li>
<li>Why bother having them at all?
<ul>
<li>Can review if really interested.</li>
<li>Least-privilege, if application is compromised later.</li>
</ul></li>
</ul></li>
<li>Dangerous:
<ul>
<li>Could allow an app to do something dangerous.</li>
<li>E.g., internet access, access to contact information, etc.</li>
</ul></li>
<li>Signature:
<ul>
<li>Can only be granted to apps signed by the same developer.</li>
<li>Think ForceHTTPS: want to prevent user from accidentally giving it away.</li>
</ul></li>
</ul>

<h3>Why do this checking in the reference monitor, rather than in each app?</h3>

<ul>
<li>Convenience, so programmers don't forget.
<ul>
<li>Could do it in a library on the application side.</li>
</ul></li>
<li>Intent might be routed to different components based on permissions.
<ul>
<li>Don't want to send an intent to component A that will reject it,
if another component B is willing to accept it.</li>
</ul></li>
<li>Mandatory access control (MAC): permissions specified separately from code.
<ul>
<li>Aside: annoyance, MAC is an overloaded acronym.
<ul>
<li>Media Access Control -- MAC address in Ethernet.</li>
<li>Message Authentication Code -- the thing that Kerberos v4 lacked.</li>
</ul></li>
<li>Want to understand security properties of system without looking at code.</li>
</ul></li>
<li>Contrast: discretionary access control (DAC) in Unix.
<ul>
<li>Each app sets its own permissions on files.</li>
<li>Permissions can be changed by the app over time.</li>
<li>Hard to tell what will happen just by looking at current file perms.</li>
</ul></li>
<li>Apps can also perform their own checks.  <code>[ref: checkCallingPermission()]</code>
<ul>
<li>Breaks the MAC model a bit: can't just look at manifest.</li>
<li>Necessary because one service may export different RPC functions,
<ul>
<li>want different level of protection for each.</li>
</ul></li>
<li>Reference monitor just checks if client can access the entire service.</li>
</ul></li>
</ul>

<h3>Who can register to receive intents?</h3>

<ul>
<li>Any app can specify it wants to receive intents with arbitrary parameters.</li>
<li>E.g., can create activity with an intent filter (in manifest):</li>
</ul>

<p><em>Example:</em></p>

<pre><code>  &lt;intent-filter&gt;
        &lt;action android:name="android.intent.action.VIEW" /&gt;
        &lt;category android:name="android.intent.category.DEFAULT"/&gt;
        &lt;category android:name="android.intent.category.BROWSABLE"/&gt;
        &lt;data android:scheme="http" android:host="web.mit.edu" /&gt;
  &lt;/intent-filter&gt;
</code></pre>

<ul>
<li>Is this a problem? 
<ul>
<li>Why or why not?</li>
</ul></li>
<li>System will prompt user whenever they click on a link to http://web.mit.edu/.
<ul>
<li>Only "top-level" user clicks translate to intents, not web page components.</li>
</ul></li>
<li>Might be OK if user is prompted.
<ul>
<li>Even then, what if your only map app is "bad": steals addresses sent to it?</li>
</ul></li>
<li>Not so great for broadcast intents, which go to all possible recipients.</li>
</ul>

<h3>Controlling the distribution of broadcast intents.</h3>

<ul>
<li>In paper's example, want <code>FRIEND_NEAR</code> intents to not be disclosed to everyone.</li>
<li>Solution: sender can specify extra permission label when sending bcast intent.</li>
<li>Reference monitor only sends this intent to recipients that have that label.</li>
</ul>

<h3>How to authenticate the source of intents?</h3>

<ul>
<li>Generally using a permission label on the receiving component.
<ul>
<li>Don't necessarily care who sender is, as long as it had the right perms.</li>
</ul></li>
<li>Turns out apps often forgot to put perm restrictions on broadcast receivers.
<ul>
<li>Paper at Usenix Security 2011: "permission re-delegation attacks".</li>
<li>E.g., can create an alarm that beeps and vibrates forever.</li>
<li>E.g., can send messages to the settings bcast receiver to toggle wifi, etc.</li>
</ul></li>
<li>One solution in android: "protected broadcasts" (not complete, but..)
<ul>
<li>Reference monitor special-cases some intent actions (e.g., system bootup).</li>
<li>Only system processes can send those broadcast intents.</li>
</ul></li>
</ul>

<h3>Can a sender rely on names to route intents to a specific component?</h3>

<ul>
<li>More broadly, how does android authenticate names? (App names, perm names.)</li>
<li>No general plan, just first-come-first-served.</li>
<li>System names (apps, permissions, etc) win in this model.</li>
<li>Other apps could be preempted by a malicious app that comes first.</li>
<li>Could send sensitive data to malicious app, by using app's name.</li>
<li>Could trust intent from malicious app, by looking at its sender name.</li>
<li>Could set lax permissions by using a malicious app's perm by name.</li>
</ul>

<h3>What happens if two apps define the same permission name?</h3>

<ul>
<li>First one wins.</li>
<li>Malicious app could register some important perm name as "normal".</li>
<li>Any app (including malicious app) can get this permission now.</li>
<li>Other apps that rely on this perm will be vulnerable to malicious app.
<ul>
<li>Even if victim app defines its own perms and is the only one that uses it.
(E.g., signature perms.)</li>
</ul></li>
<li>Possibly better: reject installing an app if perm is already defined.
<ul>
<li>Allows an app to assume its own perms are correctly defined.</li>
<li>Still does not allow an app to assume anything about other app/perm names.</li>
</ul></li>
</ul>

<h3>If app names are not authenticated, why do applications need signatures?</h3>

<ul>
<li>Representing a developer.</li>
<li>No real requirement for a CA.</li>
<li>Helps Android answer three questions:
<ul>
<li>Did this new version of an app come from the same developer as the old one?
(if so, can upgrade.)</li>
<li>Did these two apps come from the same developer?
(if so, can request same UID.)</li>
<li>Did the app come from same developer as the one that defined a permission?
(if so, can get access to signature-level perms.)</li>
</ul></li>
</ul>

<h3>How to give another app temporary permissions?</h3>

<ul>
<li>URI delegation.
<ul>
<li>Capability-style delegation of URI read/write access.</li>
<li>System keeps track of delegated access by literal string URI.
<ul>
<li>E.g., <code>content://gmail/attachment/7</code></li>
</ul></li>
<li>Must remember to revoke delegated access!
<ul>
<li>E.g., URI may mean another record at a later time..
<code>[ref: grantUriPermission(), revokeUriPermission()]</code></li>
</ul></li>
<li>Reference monitor keeps granted URIs in memory.
<code>[ref: ActivityManagerService.mGrantedUriPermissions]</code></li>
<li>Grants are ephemeral, only last until a reboot.</li>
</ul></li>
<li>Pending intents.
<ul>
<li>Use case: callbacks into your application (e.g., from alarm/time service).</li>
<li>system_server keeps track of pending intents in memory; ephemeral.
<code>[ref: PendingIntentRecord.java]</code></li>
<li>Revocation problem, as with URI delegation.
"Breaks" the MAC model: can't quite reason about all security from manifest.</li>
</ul></li>
</ul>

<h3>Where are apps stored?</h3>

<ul>
<li>Two options: internal phone memory or SD card.</li>
<li>Internal memory is always controlled by Android, so can assume it's safe.</li>
<li>Installing apps on SD card is more complicated, but desirable due to space.
<ul>
<li>Threat models:
<ul>
<li>Worried about malicious app modifying SD card data.</li>
<li>Worried about malicious user making copies of a paid app.</li>
</ul></li>
<li>SD card uses FAT file system, no file permissions.</li>
<li>Approach: encrypt/authenticate app code with a per-phone random key.</li>
<li>Key stored in phone's internal flash, unique to phone.</li>
</ul></li>
</ul>

<h3>How secure is the Android "platform"?</h3>

<ul>
<li>TCB: kernel + anything running as root.</li>
<li>Better than desktop applications:
<ul>
<li>Most applications are not part of the TCB.</li>
<li>Many fewer things running as root.</li>
</ul></li>
<li>Some vulnerabilities show up in practice.</li>
<li>Bugs in the Linux kernel or in setuid-root binaries allow apps to get root.
<ul>
<li>How to do better?</li>
<li>Syscall filtering / seccomp to make it harder to exploit kernel bugs?</li>
<li>Not clear.</li>
</ul></li>
<li>Users inadvertently install malware applications with dangerous permissions.
<ul>
<li>Actual common malware: send SMS messages to premium numbers.</li>
<li>Attackers directly get money by deploying such malware.</li>
<li>Why do users make such mistakes?
<ul>
<li>One cause: some permissions necessary for both mundane + sensitive tasks.</li>
<li>E.g., accessing phone state / identity required to get a unique device ID.</li>
<li>Causes unnecessary requests for dangerous permissions, de-sensitizes user.</li>
<li>Another cause: apps ask for permissions upfront "just in case".</li>
<li>E.g., might need them later, but changing perms requires manual update.</li>
<li>Another cause: cannot say "no" to certain permissions.</li>
<li>Another cause: copies of existing Android apps containing malware.</li>
</ul></li>
<li>How to fix?
<ul>
<li>Find ways to allow more permissions "non-dangerous" without asking user.</li>
<li>Allow user to selectively disable certain permissions.
(Some research work on this, see refs below.)</li>
<li>Static/runtime analysis and auditing -- implemented by Google now.
<ul>
<li>Looks for near-identical clones of existing popular apps.</li>
<li>Runs apps for a little bit to determine what they do.</li>
<li>Security researchers got a (non-root) shell on Google's app scanner.</li>
<li>Reasonably expected in retrospect: app scanner just runs the app..</li>
</ul></li>
<li>Android's app market (Google Play) allows Google to remotely kill an app.</li>
</ul></li>
</ul></li>
</ul>

<h3>Other model for security in mobile phone apps: iOS/iPhone.</h3>

<ul>
<li>Security mechanism: all apps run two possible UIDs.
<ul>
<li>One UID for Apple apps, another for all other apps.</li>
<li>Historically made sense: only one app was active at a time.</li>
<li>With switch to multi-tasking apps, didn't change the UID model.</li>
<li>Instead, isolate apps using Apple's sandbox ("Seatbelt"?).</li>
<li>Apple applications not isolated from each other originally (unclear now?).</li>
<li>Thus, exploit of vulnerability in browser left all Apple apps "exposed".</li>
</ul></li>
<li>Prompt for permissions at time of use.
<ul>
<li>Users can run app and not give it permissions (unlike Android).</li>
<li>"Normal" permissions not very meaningful in this model.</li>
</ul></li>
<li>Apple approves apps in its app store, in part based on security eval.
<ul>
<li>"Reputation-based" system: hard to exploit many phones and avoid detection.</li>
</ul></li>
</ul>

<h2>References</h2>

<ul>
<li><a href="http://developer.android.com/guide/topics/security/security.html">Android security</a></li>
<li><a href="http://research.microsoft.com/pubs/149596/AppFence.pdf">AppFence</a></li>
<li><a href="http://cjix.info/blog/misc/internal-input-event-handling-in-the-linux-kernel-and-the-android-userspace/">Internal input event handling in the Linux kernel and in the Android userspace</a></li>
<li><a href="http://css.csail.mit.edu/6.858/2012/readings/ios-security-may12.pdf">iOS security</a></li>
<li><a href="http://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf">Apple Sandbox Guide</a></li>
</ul>