24-12-2012, 06:10 PM
Systematic Detection of Capability Leaks in Stock Android Smartphones
[attachment=45195]
Abstract
Recent years have witnessed a meteoric increase in the
adoption of smartphones. To manage information and features
on such phones, Android provides a permission-based
security model that requires each application to explicitly
request permissions before it can be installed to run. In
this paper, we analyze eight popular Android smartphones
and discover that the stock phone images do not properly
enforce the permission model. Several privileged permissions
are unsafely exposed to other applications which do
not need to request them for the actual use. To identify
these leaked permissions or capabilities, we have developed
a tool called Woodpecker. Our results with eight phone images
show that among 13 privileged permissions examined
so far, 11 were leaked, with individual phones leaking up
to eight permissions. By exploiting them, an untrusted application
can manage to wipe out the user data, send out
SMS messages, or record user conversation on the affected
phones – all without asking for any permission.
Introduction
Recent years have witnessed a meteoric increase in the
adoption of smartphones. According to data from IDC [24],
smartphone manufacturers shipped 100.9 million units in
the fourth quarter of 2010, compared to 92.1 million units
of PCs shipped worldwide. For the first time in history,
smartphones are outselling personal computers. Their popularity
can be partially attributed to the incredible functionality
and convenience smartphones offered to end users. In
fact, existing mobile phones are not simply devices for making
phone calls and receiving SMS messages, but powerful
communication and entertainment platforms for web surfing,
social networking, GPS navigation, and online banking.
The popularity of smartphones is also spurred by the
proliferation of feature-rich devices as well as compelling
mobile applications (or simply apps).
System Design
We aim to identify capability leaks, i.e., situations where
an app can gain access to a permission without actually requesting
it. Each such situation essentially sidesteps Android’s
permission-based security model. In this work, we
choose to focus on those permissions used by the pre-loaded
apps as a part of an Android phone’s firmware, since the
firmware has access to some permissions that are too privileged
to be granted to third-party apps. For simplicity, we
use the terms “permissions” and “capabilities” interchangeably.
Explicit Capability Leak Detection
Explicit capability leaks may occur in any pre-loaded
app that has requested a capability of interest in its manifest
file. To detect these leaks, our system analyzes each such
app in two steps. The first step, possible-path identification
builds a control-flow graph to identify possible paths from a
well-defined entry point (in the manifest file) to some use of
the capability. After that, the second step, feasible path refinement
employs field- and path-sensitive inter-procedural
data flow analysis to determine which of these paths are feasible.
Implicit Capability Leak Detection
When detecting explicit capability leaks, we focus on
those apps that request permissions of interest in their manifest
files. If an app has a sharedUserId in its manifest
but does not request a certain (dangerous) permission, we
also need to investigate the possibility of an implicit capability
leak.
To detect implicit capability leaks, we employ a similar
algorithm as for explicit leaks with necessary changes
to reflect a fundamental difference in focus. Specifically,
explicit capability leak detection assumes the caller of an
app’s exposed API is malicious, while implicit capability
leak detection assumes the app itself might be malicious.
Accordingly, instead of only starting from the well-defined
entry points in the explicit leak detection, there is a need to
broaden our search to include the app’s initialization.
[attachment=45195]
Abstract
Recent years have witnessed a meteoric increase in the
adoption of smartphones. To manage information and features
on such phones, Android provides a permission-based
security model that requires each application to explicitly
request permissions before it can be installed to run. In
this paper, we analyze eight popular Android smartphones
and discover that the stock phone images do not properly
enforce the permission model. Several privileged permissions
are unsafely exposed to other applications which do
not need to request them for the actual use. To identify
these leaked permissions or capabilities, we have developed
a tool called Woodpecker. Our results with eight phone images
show that among 13 privileged permissions examined
so far, 11 were leaked, with individual phones leaking up
to eight permissions. By exploiting them, an untrusted application
can manage to wipe out the user data, send out
SMS messages, or record user conversation on the affected
phones – all without asking for any permission.
Introduction
Recent years have witnessed a meteoric increase in the
adoption of smartphones. According to data from IDC [24],
smartphone manufacturers shipped 100.9 million units in
the fourth quarter of 2010, compared to 92.1 million units
of PCs shipped worldwide. For the first time in history,
smartphones are outselling personal computers. Their popularity
can be partially attributed to the incredible functionality
and convenience smartphones offered to end users. In
fact, existing mobile phones are not simply devices for making
phone calls and receiving SMS messages, but powerful
communication and entertainment platforms for web surfing,
social networking, GPS navigation, and online banking.
The popularity of smartphones is also spurred by the
proliferation of feature-rich devices as well as compelling
mobile applications (or simply apps).
System Design
We aim to identify capability leaks, i.e., situations where
an app can gain access to a permission without actually requesting
it. Each such situation essentially sidesteps Android’s
permission-based security model. In this work, we
choose to focus on those permissions used by the pre-loaded
apps as a part of an Android phone’s firmware, since the
firmware has access to some permissions that are too privileged
to be granted to third-party apps. For simplicity, we
use the terms “permissions” and “capabilities” interchangeably.
Explicit Capability Leak Detection
Explicit capability leaks may occur in any pre-loaded
app that has requested a capability of interest in its manifest
file. To detect these leaks, our system analyzes each such
app in two steps. The first step, possible-path identification
builds a control-flow graph to identify possible paths from a
well-defined entry point (in the manifest file) to some use of
the capability. After that, the second step, feasible path refinement
employs field- and path-sensitive inter-procedural
data flow analysis to determine which of these paths are feasible.
Implicit Capability Leak Detection
When detecting explicit capability leaks, we focus on
those apps that request permissions of interest in their manifest
files. If an app has a sharedUserId in its manifest
but does not request a certain (dangerous) permission, we
also need to investigate the possibility of an implicit capability
leak.
To detect implicit capability leaks, we employ a similar
algorithm as for explicit leaks with necessary changes
to reflect a fundamental difference in focus. Specifically,
explicit capability leak detection assumes the caller of an
app’s exposed API is malicious, while implicit capability
leak detection assumes the app itself might be malicious.
Accordingly, instead of only starting from the well-defined
entry points in the explicit leak detection, there is a need to
broaden our search to include the app’s initialization.