Mobile Application Security on Android
Originally presented by Jesse Burns at Black Hat 2009
1
What is Android?
Smart Phone Operating System
 Based on the Linux kernel
 Expanded to support cellular based
communication

 GSM, CMDA

Java like middleware
2
More Android

Open Source
 Mostly Apache v2 license
 Linux kernel is GPLv2
Free
 Open API’s

 If Google uses them, so can developers
3
Applications

Built from for “components”
 Activity
 Service
 Content Provider
 Broadcast Receiver

Run in own VM sandbox using unique
UID
4
More on Apps
Use explicitly defined permissions
 Communicate through Intents
 Intents are Inter-Process
Communications
 Applications register which Intents they
wish to handle

5
Signatures

applications must be signed, but are
usually self-signed
 proves no relationship with Google, but
 creates chain of trust between updates and
among applications
6
Permissions I
>100 defined by the system
 Declared at install time in Manifest.xml
 Disclosed by PackageInstaller, protected by
root ownership

7
Permissions II

applications can define arbitrary new
perms
 normal
 dangerous
 signature
 signatureOrSystem
8
Permission III
Permissions checked at runtime
 SecurityException thrown if permission
denied

9
Intents
Core of Android IPC
 Can cross security boundaries
 Generally defined as a goal action and
some data

10
Intent II

Used to:
 Start an Activity
 Broadcast events or changes
 Start, stop, or communicate with
background Services
 Access data held by ContentProviders
 Call backs to handle events
11
Intent Filters
Used to determine recipient of Intent
 Can be overridden
 Provide no security

 Intents can explicitly define receiver
12
Activities
The user interface consists of a series of Activity
components.
 Each Activity is a “screen”.
 User actions tell an Activity to start another
Activity, possibly with the expectation of a result.

13
Activity II
 The
target Activity is not necessarily in
the same application.
 Directly or via Intent “action strings”.
 Processing stops when another Activity
is “on top”.
Must be able to handle malformed intents
 Don’t start Intents that contain sensitive data

14
Activity III

Starting an Activity from an Intent
15
Activity IV

Forcing an Activity to start
16
Activity V

Protecting Activities
17
Broadcasts
Act as recievers for multiple components
 Provide secure IPC
 Done by specifying permissions on
BroadcastReceiver regarding sender
 Otherwise, behave like activities in
terms of IPC

18
Broadcast II
Still need to validate input just in case
 Sticky Broadcasts

 Persistent
 Apps require special permissions to
create/destroy sticky broadcasts
 No guarantee of persistence
 Can’t define permission
○ Don’t send sensitive data
19
Services
Run in background
 Play music, alarm clock, etc
 Secured using permissions
 Callers may need to verify that Service
is the correct one

20
Services II

Verification:
 Check Service’s permissions
res = getPackageManager().checkPermission(permToCheck,
name.getPackageName());
21
ContentProviders
Generally SQL backend
 Used to share content between apps
 Access controlled through permission
tags

22
ContentProviders II

Apps can be dynamically authorized
access
 Possible security hole

Must protect against SQL injection
 Sanitize input using parameterization
23
Intent Reflection
Intents may be sent when app is called
 App sends Intent as app and not as
caller: reflection

 May exceed caller’s permissions

Use PendingIntent instead, intent
correctly identified as coming from caller
24
File System
Internally standard Linux file systems –
yaffs2, ext*
 Support stand Unix permissions
 Vulnerabilities if permissions not set
correctly

 Sensitive data could be read
 Other programs could write junk/waste
space
25
File System II

Consider what files need what
protections
 Config files: not writeable
 Log files: not world readable

Mass storage formatted as FAT, no Unix
permissions support
 All data world readable
 Consider encryption
26
Binder
Kernel module that provides secure IPC
on top of the standard Linux shared
memory architecture
 Includes interface to Parceable

 Parceable objects are passed by Binder

Can also move file descriptors, and
other Binders
27
Binder II

Efficient, secure IPC
 Check caller’s permissions / identity
 Only selectively give out interface
○ Once given out, interface can be disseminated
freely

All Binders are globally unique
28