Download Android Applications

Mobile phone
security
Many slides from Internet Mobile Operating System
A mobile operating system (OS) is a software that allows smart
phones, tablet PCs and other devices to run applications and programs.
Examples
Symbian OS
BlackBerry OS
Apple’s iOS
Windows Phone OS
Android OS
2
History
The Android™ was built upon the open Linux kernel, and developed by
Android, Inc., which is owned by Google.
Open Handset Alliance - to develop open standards for mobile devices
3
The ANDROID™ OS
• History
• Google acquires mobile software startup Android™
in 2005
• Open Handset Alliance officially starts on
November 5th, 2007
• Android™ 1.0 source and SDK released in Fall 2008
(http://www.android.com/timeline.html)
The ANDROID™ OS
John Mitchell
The ANDROID™ OS
• System Architecture
• Linux Version 2.6 or 3.0.1
• Davlik Virtual Machine (VM)
• Application Framework
John Mitchell
Phone
HTC G1,
Droid,
Tattoo
Suno S880
Motorola Droid (X)
Samsung Galaxy
Sony Ericsson
7
Tablets
Velocity Micro Cruz
Dawa D7
Gome FlyTouch
Toshiba Android
SmartBook
Acer beTouch
Cisco Android Tablet
8
Architecture
9
Applications
• Android provides a set of core applications:
✓
✓
✓
✓
✓
✓
✓
Email
SMS Program
Calendar
Maps
Browser
Contacts
Etc
• All applications are written using the Java language.
10
Common file structure for Apps
code
files
Autogenerated
resource list
images
UI layouts
constants
11
GUI
12
Application Framework
• Enabling and simplifying the reuse of components
✓ Developers have full access to the same framework APIs used by
the core applications.
✓ Users are allowed to replace components.
✓ Each application can publish its capabilities which other apps
can use
13
Libraries
• Including a set of C/C++ libraries used by components of the Android
system
• Exposed to developers through the Android application framework
14
Runtime
•
Core Libraries
✓ Providing most of the functionality available in the core libraries of the Java
language
✓ APIs
➢Data Structures
➢Utilities
➢File Access
➢Network Access
➢Graphics etc.
15
Runtime
•
Software Development kit (Dalvik Virtual Machine )
✓ Providing environment on which every Android application runs
➢Each Android application runs in its own
process, with its own instance of the
Dalvik VM.
➢Dalvik has been written such that a
device can run multiple VMs efficiently.
.dex format is optimized for minimal memory footprint.
16
Linux Kernel
●
●
Relying on Linux Kernel for core system services
✓
Memory and Process Management
✓
Network Stack
✓
Driver Model
✓
Security
Providing an abstraction layer between the H/W and the rest of the
S/W stack
17
Challenges
✓
✓
✓
✓
✓
✓
CPU typically runs 500-600 Mhz
RAM available to an App may only be a few megabytes
Disk (flash) access is very slow
Lifecycle - apps must pause/quit often, and restore to give the illusion that they
are always running
UI design
✓ typical screen may be HVGA (320x480)
✓ may be in portrait or landscape
✓ very high DPI - small text may not be readable
✓ touch resolution is very low (~25 pixel)
Network access may be slow and (very) intermittent
@2011 Mihail L. Sichitiu
18
Merits
Highly customizable
Services can run in the background
Notifications let you know of background events
Multitasking
Widget
Can install a modified ROM
Easy access to thousands of applications via the Google
Android Android App Market
✓ Google Maniac
✓
✓
✓
✓
✓
✓
✓
Demerits
✓ Advertising
✓ Continuous Internet connection
19
MarketShare
Feb’10
May’10
Apr’11
RIM
42.1%
41.7%
29%
Apple
25.4%
24.4%
25%
Google
9%
13%
33%
Microsoft
15.1%
13.2%
7.7%
Palm
5.4%
4.8%
2.9%
20
Understanding Android
Security
William Enck, Machigar Ongtang, and PatrickMcDaniel
Pennsylvania State University
IEEE S &P 2009
Outline
I.
II.
III.
IV.
V.
Introduction
Android Applications
Security Enforcement
Security Refinements
Lessons in Defining Policy
Introduction
➢ Next generation open operation system will be developed on
small mobile devices.
➢ Android (Google)
-a widely anticipated open source operating system for mobile
devices
-it provide base operation system, application middleware layer,
Java software development kit and a collection of system
applications.
Introduction (cont.)
Feature of Android
1. Doesn’t support applications developed for other platforms
2. Restricts application interaction to its special APIs by running
each application as its own user identity
3. Uses a simple permission label assignment model to restrict
access to resources and other applications
Declaring and Using Permissions
•
•
At install time, the APK installer either grants or denies the requested
permissions based on the signature of the .apk file and/or feedback from
the user .
Application developers can request permissions by adding entries to the
AndroidManifest.xml file.
– <manifest … >
–
<application>
–
…
–
</application>
–
<uses-permission android:name="android.permission.CAMERA" />
–
<uses-permission android:name="android.permission.READ_CONTACTS"/>
–
<uses-permission android:name="android.permission.READ_CALENDAR" />
– </manifest>
25
Declaring and Using Permissions
• You can either hard-code permissions in the
AndroidManifest.xml file or use the manifest editor
26
Custom Permissions
• Android allows you to define custom permissions with
your application.
• To use custom permissions, you first declare them in
your AndroidManifest.xml file.
• Once you’ve defined a permission, you can then refer to
it as part of your component definition.
27
Strategy
• Create an application containing an activity that not
everyone is allowed to start.
• To start the activity, a user must have a specific
permission.
• Once you have the application with a privileged
activity, you can write a client that knows how to call
the activity.
28
The PrivActivity Class
package com.cust.perm;
public class PrivActivity extends Activity
{
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
LinearLayout view = new LinearLayout(this);
view.setLayoutParams(new LayoutParams(
LayoutParams.FILL_PARENT, LayoutParams.WRAP_CONTEN
view.setOrientation(LinearLayout.HORIZONTAL);
T));
TextView nameLbl = new TextView(this);
nameLbl.setText("Hello from PrivActivity");
view.addView(nameLbl);
}
}
setContentView(view);
29
Create a custom permission
• To create a custom permission using the manifest editor
30
Who defines permissions?
•
•
Apps define permissions themselves (just free-form strings).
– Android system defines perms for built-in resources (camera,
network, etc).
–
Can list with 'adb shell pm list permissions -g'.
– Built-in applications define permissions for services they
provide.
–
E.g., read/write contacts, send SMS message, etc.
Defining a permission means specifying:
- User-visible name of the permission.
- Description of the permission for the user.
- Grouping permission into some categories (costs money,
private data, etc).
- Type of permission: "normal", "dangerous", and "signature"
Attributes of a Permission
32
Attributes of a Permission
33
What do the three types of permission mean?
•
•
•
Normal:
–
Benign permissions that could let an app annoy the user, but not
drastic.
•
E.g., SET_WALLPAPER.
–
System doesn't bother asking the user about "normal" permissions.
–
Why bother having them at all?
•
Can review if really interested.
•
Least-privilege, if application is compromised later.
Dangerous:
–
Could allow an app to do something dangerous.
–
E.g., internet access, access to contact information, etc.
Signature:
–
Can only be granted to apps signed by the same developer.
–
Think ForceHTTPS: want to prevent user from accidentally giving it
away.
The AndroidManifest.xml File
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://
schemas.android.com/apk/res/android"
package="com.cust.perm"
android:versionCode="1"
android:versionName="1.0.0">
<application android:icon="@drawable/icon"
android:label="@string/app_name">
<activity android:name=".CustPermMainActivity"
android:label="@string/app_name">
<intent-filter>
<action
android:name="android.intent.action.MAIN" />
<category
android:name="android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
<activity android:name="PrivActivity"
android:permission="dcm.permission.STARTMYACTIVI
TY">
<intent-filter>
<action
android:name="android.intent.action.MAIN" />
</intent-filter>
</activity>
</application>
<permission
android:protectionLevel="normal"
android:label="Start My Activity"
android:description="@string/
startMyActivityDesc"
android:name="dcm.permission.STARTMYACTIVITY" /
>
<uses-sdk android:minSdkVersion="4" />
</manifest>
35
Create the client project
• Main.xml File for the Client Project
– <?xml version="1.0" encoding="utf-8"?>
– <LinearLayout xmlns:android="http://schemas.android.com/apk/res/
android"
–
android:orientation="vertical"
–
android:layout_width="fill_parent"
–
android:layout_height="fill_parent" >
–
–
<Button android:id="@+id/btn" android:text="Launch PrivActivity"
–
android:layout_width="wrap_content"
–
android:layout_height="wrap_content"
–
android:onClick=”doClick” />
– </LinearLayout>
36
ClientCustPermMainActivity
package com.client.cust.perm;
// This file is ClientCustPermMainActivity.java
import
import
import
import
android.app.Activity;
android.content.Intent;
android.os.Bundle;
android.view.View;
public class ClientCustPermMainActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}
public void doClick(View view) {
Intent intent = new Intent();
intent.setClassName("com.cust.perm","com.cust.perm.PrivActivity");
startActivity(intent);
}
37
The Client Manifest File
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.client.cust.perm"
android:versionCode="1"
android:versionName="1.0.0">
<application android:icon="@drawable/icon"
android:label="@string/app_name">
<activity android:name=".ClientCustPermMainActivity"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
<uses-permission android:name="dcm.permission.STARTMYACTIVITY" />
<uses-sdk android:minSdkVersion="4" />
</manifest>
38
Confused Deputy Attack
Do not have a right permission? Ask your neighbor!
Collusion Attack
Android Applications --- Example
Example of location-sensitive social networking application for
mobile phones in which users can discover their friends’ locations.
Activities provide a user interface, Services execute background
processing, Content providers are data storage facilities, and
Broadcast receivers act as mailboxes for messages from other
applications.
Android Applications --- Example Application(cont.)
Take FriendTracker application for example,
FriendTracker (Service) polls an external service to discover friends’
locations
FriendProvider (Content provider) maintains the most recent
geographic coordinates for friends
FriendTrackerControl (Activity) defines a user interface for starting
and stopping the tracking functionality
BootReceiver (Broadcast receiver) gets a notification from the system
once it boots (the application uses this to automatically start the
FriendTracker service).
Android Applications--- Component Interaction
• Intent - is the primary mechanism for
component interaction, which is simply a
message object containing a destination
component address and data
• Action - the process of inter-components
communication
Intent fields:
Component: name of component to route the request to (just a
string).
E.g., com.google.someapp/ComponentName
Action: the opcode for this message (just a string).
E.g., android.intent.action.MAIN, android.intent.action.DIAL, ..
Data: URI of data for the action (just a string).
E.g., tel:16172536005, content://contacts/people/1 (for DIAL).
Category: a filtering mechanism for finding where to send intent.
E.g., android.intent.category.BROWSABLE means safe to invoke
from browser, for action android.intent.action.VIEW, which views
the URI in data.
Who can register to receive intents?
• Any app can specify it wants to receive intents with arbitrary
parameters.
• E.g., can create activity with an intent filter (in manifest):
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category
android:name="android.intent.category.DEFAULT"/>
<category
android:name="android.intent.category.BROWSABLE"/>
<data android:scheme="http"
android:host="web.mit.edu" />
</intent-filter>
Controlling the distribution of broadcast intents.
• In paper's example, want FRIEND_NEAR intents to not be
disclosed to everyone.
– Solution: sender can specify extra permission label
when sending bcast intent.
– Reference monitor only sends this intent to
recipients that have that label.
How to authenticate the source of intents?
• Generally using a permission label on the receiving component.
–
Don't necessarily care who sender is, as long as it had the right
perms.
•
Turns out apps often forgot to put perm restrictions on broadcast
receivers.
–
Paper at usenix security 2011: "permission re-delegation
attacks".
–
E.g., can create an alarm that beeps and vibrates forever.
–
E.g., can send messages to the settings bcast receiver to
toggle wifi, etc.
•
One solution in android: "protected broadcasts" (not complete,
but..)
–
Reference monitor special-cases some intent actions (e.g.,
system bootup).
–
Only system processes can send those broadcast intents.
What happens if two apps define the same permission
name?
•
•
First one wins.
– Malicious app could register some important perm name as
"normal".
– Any app (including malicious app) can get this permission now.
– Other apps that rely on this perm will be vulnerable to
malicious app.
–
Even if victim app defines its own perms and is the only one
that uses it.
•
(E.g., signature perms.)
Possibly better: reject installing an app if perm is already defined.
–
Allows an app to assume its own perms are correctly defined.
–
Still does not allow an app to assume anything about other
app/perm names.
why do applications need signatures?
•
•
•
Representing a developer.
No real requirement for a CA.
Helps Android answer three questions:
– Did this new version of an app come from the same
developer as the old one?
•
(if so, can upgrade.)
– Did these two apps come from the same developer?
•
(if so, can request same UID.)
– Did the app come from same developer as the one that
defined a permission?
•
(if so, can get access to signature-level perms.)
Android Applications--- Component Interaction (cont.)
Example: Interaction between components in applications and with
components in system applications. Interactions occur primarily at the
component level.
Android Applications--- Component Interaction (cont.)
Each component type supports interaction specific to its type. For
example, Service components support start , stop, and bind actions,
so the FriendTrackerControl (Activity) can start and stop the
FriendTracker (Service) that runs in the background.
Security Enforcement
• Android protect application at system level and at the Intercomponent communication (ICC) level. This article focus on the
ICC level enforcement.
• Each application runs as a unique user
identity, which lets Android limit the potential damage of
programming flaws.
• Entire application is signed by the developer.
Security Enforcement (cont.)
Example: Protection. Security enforcement in Android occurs in two places: each
application executes as its own user identity, allowing the underlying Linux
system to provide system-level isolation; and the Android middleware contains a
reference monitor that mediates the establishment of inter-component
communication (ICC).
Security Enforcement (cont.)
• Core idea of Android security enforcement - labels
assignment to applications and components
• A reference monitor provides mandatory access control
(MAC) enforcement of how applications access components.
• Access to each component is restricted by assigning it an
access permission label; applications are assigned
collections of permission labels.
• When a component initiates ICC, the reference monitor
looks at the permission labels assigned to its containing
application and— if the target component’s access
permission label is in that collection— allows ICC
establishment to proceed.
Security Enforcement (cont.)
Example: Access permission logic. The Android middleware implements a
reference monitor providing mandatory access control (MAC) enforcement
about how applications access components. The basic enforcement model
is the same for all component types. Component A’s ability to access
components B and C is determined by comparing the access permission
labels on B and C to the collection of labels assigned to application 1.
Why do this checking in the reference monitor
• Intent might be routed to different components based on
permissions.
–
Don't want to send an intent to component A that will
reject it, if another component B is willing to accept it.
• Mandatory access control (MAC): permissions specified
separately from code.
–
Aside: annoyance, MAC is an overloaded acronym.
–
Media Access Control -- MAC address.
–
Message Authentication Code -- the thing that
Kerberos v4 lacked.
•
Want to understand security properties of system without
looking at code.
Why do this checking in the reference monitor
•
•
Contrast: discretionary access control (DAC) in Unix.
–
Each app sets its own permissions on files.
–
Permissions can be changed by the app over time.
–
Hard to tell what will happen just by looking at current file
perms.
Apps can also perform their own checks. [ref:
checkCallingPermission()]
–
Breaks the MAC model a bit: can't just look at manifest.
–
Necessary because one service may export different RPC
functions,
–
want different level of protection for each.
–
Reference monitor just checks if client can access the entire
service.
Security Enforcement - Conclusion
•
Assigning permission labels to an application specifies its protection
domain. Assigning permissions to the components in an application
specifies an access policy to protect its resources.
•
Android’s policy enforcement is mandatory, all permission labels
are set at install time and can’t change until the application is
reinstalled.
•
Android’s permission label model only restricts access to
components and doesn’t currently provide information flow
guarantees.
How does the reference monitor decide whether to
allow an intent?
• "Labels" assigned to applications and components.
Each label is a free-form string.
–
–
Commonly written as Java-style package names, for
uniqueness.
–
E.g., com.android.phone.DIALPERM.
• Each component has a single label that protects it.
Any intents to that component must be sent by app that
–
has that label.
–
E.g., phone dialer service is labeled with ...DIALPERM.
–
For content providers, two labels: one for read, one for
write.
Intents
An application has a list of labels it is authorized to
use.
–
E.g., if app can dial the phone, ...DIALPERM is in
its label set.
• Other permissions (network, devices, SD card) map to
special label strings.
–
E.g., android.permission.INTERNET translates to
app running w/ GID 3003.
•
Security Refinements --- Public vs. Private
Components
• Applications often contain components
that another application should never access. For example,
component related to password storing. The solution is to
define private component.
• This significantly reduces the attack surface for many
applications.
Security Refinements --- Implicitly Open Components
• At development time, if the decision of access permission is
unclear, The developer can permit the functionality by not
assigning an access permission to it.
• If a public component doesn’t explicitly have an access
permission listed in its manifest definition, Android permits any
application to access it.
Security Refinements --- Broadcast Intent Permissions
• Sending the unprotected intent is a privacy risk.
• Android API for broadcasting intents optionally allows
the developer to specify a permission label to restrict
access to the intent object.
Security Refinements --- Content Provider Permissions
• If the developer want his application to be the only one
to update the contents but for other applications to be
able to read them.
• Android allows such a security policy assigning read or
write permissions.
Security Refinements --- Protected APIs
• Not all system resources(for example, network) are
accessed through components—instead, Android
provides direct API access.
• Android protects these sensitive APIs with additional
permission label checks: an application must declare a
corresponding
permission label in its manifest file to use them.
Security Refinements --- Permission
Protection Levels
• The permission protection levels provide a means of
controlling how developers assign permission labels.
• Signature permissions ensure that only the framework
developer can use the specific functionality (only
Google applications can directly interface the telephony
API, for
example).
Security Refinements --- Pending Intents
• Pending intent - a developer defines an intent object to
perform an action. However, instead of performing the
action, the developer passes the intent to a special method
that creates a PendingIntent object corresponding to the
desired action. The PendingIntent object is simply a
reference pointer that can pass to another application.
• Pending intents allow applications included with the
framework to integrate better with third-party applications.
Lessons in Defining Policy
• Android security policy begins with a relatively easy-tounderstand MAC enforcement model, but the number
and subtlety of refinements make it difficult to discover
an application’s policy.
• The label itself is merely a text string, but its
assignment to an application provides access to
potentially limitless resources.
Introduction to Android
• Security Features
– Process Isolation
– Linux user/group permission
– App requests permission to OS functionalities
• Most checked in remote end i.e. system services
• A few (Internet, Camera) checked in Kernel, as
special user group
How does Android's application model handle app
isolation?
• Each application's processes run under a separate UID in
Linux.
–
Exception: one developer can stick multiple
applications into one UID.
• Each application gets its own Java runtime (but that's
mostly by convention).
• Java interpreter not trusted or even required; kernel
enforces isolation.
What are per-app UIDs good for?
One app cannot directly manipulate another app's
processes, files.
• Each app has private directory (/data/data/appname).
•
Stores preferences, sqlite DBs for content providers,
cached files, etc.
•
What's missing from UID isolation
• Access control to shared resources.
– Network access.
– Removable sd card.
– Devices (camera, compass, etc).
– Intents: who can send, what intents, to whom?
• And we also need to somehow determine the policy for
all of this.
1. Network access: GIDs.
• Special group IDs define what apps can talk to the network.
GID AID_NET_BT_ADMIN (3001): can create low-level
–
bluetooth sockets
–
GID AID_NET_BT
(3002): can create bluetooth
socket
–
GID AID_INET
(3003): can create IP socket
GID AID_NET_RAW
(3004): can create raw socket
–
GID AID_NET_ADMIN (3005): can change network
–
config (ifconfig, ..)
• Requires kernel changes to do this.
• No finer-grained control of network communication.
–
E.g., could have imagined per-IP-addr or per-originlike policies.
2.Access to removable sd card.
• Why not use file system permissions?
–
Want to use FAT file system on SD card, to allow
access on other devices.
–
FAT file system has no notion of file ownership,
permissions, etc.
–
Kernel treats all SD card files as owned by special
group sdcard_rw (1015).
–
Apps that should have access to SD card have this
GID in their group list.
•
No finer-grained isolation within the entire SD card.
3. Devices.
• Device files (/dev/camera, /dev/compass, etc) owned
by special groups.
• Apps run with appropriate groups in their group list.
4. Intents
• All intents are routed via a single trusted "reference monitor".
Runs in the system_server process.
–
–
Reference monitor performs intent resolution (where to
send intent?),
•
for implicit intents. [ref:
ActivityStack.startActivityMayWait]
Reference monitor checks permissions, based on intent
–
and who sent it.
[ref: ActivityStack.startActivityLocked]
•
•
Routes intent to the appropriate application process, or starts
a new one.
Why not just use intents for everything
• Efficiency: want direct access to camera, network, SD
card files.
• Sending everything via intents could impose significant
overhead.
Introduction to Android
• Security Features
com.android.demo.
app
Android Runtime
(Dalvik VM)
Process Boundary
System Services
Application Code
-----------------------Activity
Service
Broadcast Receiver
Content Provider
Telephony Manger
Location Manger
Activity Manager
Package Manager
……
Framework Code
Framework Code
Kernel Boundary
Permission
Check
Socket
Camera
Binder (IPC)
Permission
Check
RPC and network
Initial communication to a service happens by sending
an intent.
– Service can also define an RPC protocol for clients
to use.
–
More efficient than sending intents each time.
–
Client "binds" a connection to a service
• Networking -- accessing the Internet.
– Work just as in any other Linux system.
– Application can use sockets directly, or via Java's
networking libraries.
•
Where are apps stored?
Two options: internal phone memory or SD card.
– Internal memory is always controlled by Android, so can
assume it's safe.
– Installing apps on SD card is more complicated, but
desirable due to space.
•
Threat models:
Worried about malicious app modifying SD card data.
–
Worried about malicious user making copies of a paid
–
app.
–
SD card uses FAT file system, no file permissions.
•
Approach: encrypt/authenticate app code with a per-phone
random key.
–
Key stored in phone's internal flash, unique to phone.
•
Inter Application Communication
Malicious Android Apps
• Abuse permissions:
– Permissions are granted for as long as an
App is installed on a device
– No restrictions on how often resources and
data are accessed
• Access and transmit private data
• Access to malicious remote servers
• application-level privilege escalation
– Confused deputy attacks
• Gain root privilege
Overall results from RiskRanker[NDSS 2012]
Alternative Approaches
• App vetting: Google’s Bouncer
– 40% decrease in malware
– Ineffective once App installed on the device
• AV products:
– Scanning
– Have no visibility into the runtime of an App
• Fine grain permissions checking
– Require modifications to the OS
• Virtualization
– Require modification to the OS
Related work
• Existing Work
– TaintDroid (OSDI 10)
– CRePE (ISC 10)
– AppFence (CCS 11)
– Quire (USENIX Security 2011)
– SELinux on Android
– Taming Privilege-Escalation (NDSS 2012)
• Limitations
– Modify OS – requires rooting and
flashing firmware.
Related Work
XManDroid
XManDroid Architecture
BizzTrust
Android Permissions Demystified
Adrienne Porter Felt, Erika Chin,
Steve Hanna, Dawn Song, David Wagner
University of California
ACM CCS 2011
90
Android Permission System
• API calls：be handled in three steps
1
2
3
91
How permission checks are distributed throughout the API
• Number of Permissions Checks:
• 1244 API calls with permission checks, which is 6.45% of
all API methods.
• 816 are methods of normal API classes, and 428 are
methods of RPC stubs that are used to communicate
with system services.
• Extra 15 API calls with permission checks were
indentified in a supplementary part of the API added by
a manufacturer.
92
• Signature/System Permissions:12% of the normal API
calls are protected with Signature/System permissions,
and 35% of the RPC stubs are protected with Signature/
System permissions.
• Unused Permissions: some permissions are defined by
the platform but never used within the API.
• Hierarchical Permissions: The names of many
permissions imply that there are hierarchical
relationships between them.
Ex: ACCESS_COARSE_LOCATION and
ACCESS_FINE_LOCATION.
93
• Permission Granularity: If a single permission is applied
to a diverse set of functionality, applications that
request the permission for a subset of the functionality
will have unnecessary access to the rest.
Android aims to prevent this by splitting functionality
into multiple permissions when possible, and their
approach has been shown to benefit platform security
• Permissions for Content Providers : Out of 62, 18
Content Providers do not have permissions for any of
the methods that were tested.
94
How secure is the Android "platform"?
TCB: kernel + anything running as root.
Better than desktop applications:
Most applications are not part of the TCB.
Many fewer things running as root.
Some vulnerabilities show up in practice.
Bugs in the Linux kernel or in setuid-root binaries allow
apps to get root.
How to do better?
Syscall filtering / seccomp to make it harder to exploit
kernel bugs?
Not clear.
Dangerous permissions.
• How to fix?
–
Find ways to allow more permissions "non-dangerous" without
asking user.
–
Allow user to selectively disable certain permissions.
(Some research work on this, see refs below.)
•
•
Static/runtime analysis and auditing -- implemented by
Google now.
Looks for near-identical clones of existing popular apps.
•
•
Runs apps for a little bit to determine what they do.
•
Security researchers got a (non-root) shell on Google's
app scanner.
–
Reasonably expected in retrospect: app scanner just runs the
app..
–
Android's app market (Google Play) allows Google to remotely
kill an app.
Reference
http://developer.android.com/guide/topics/security/
security.html
http://research.microsoft.com/pubs/149596/AppFence.pdf
http://cjix.info/blog/misc/internal-input-event-handling-inthe- linux-kernel-and-the-android-userspace/
http://css.csail.mit.edu/6.858/2012/readings/ios-securitymay12.pdf
http://reverse.put.as/wp-content/uploads/2011/09/AppleSandbox-Guide-v1.0.pdf
End