10-09-2016, 11:40 AM
1454390568-Rootguard.pdf (Size: 1.06 MB / Downloads: 6)
Though popular for achieving full operation
functionality, rooting Android phones
opens these devices to significant security
threats. RootGuard offers protection from
malware with root privileges while providing
user flexibility and control.
V
alued for its openness and wide application array,
Android is the world’s most popular smartphone
operating system, accounting for 78 percent of
global market share in 2013 (http://phys
news/2014-02-android-gains-apple-windows.html). Still,
its security model prevents users and apps from exploiting
full system functionality. In particular, root privilege
is strictly limited: by default, Android Open Source Project
(AOSP) releases and stock Android phones allow only the
kernel and a small subset of core services to run with
root permissions. This root inaccessibility constrains how
people can use their devices and how apps realize Android
phones’ potential. For example, users cannot remove preinstalled
but rarely used bloatware, and security software
products do not have privileges to monitor and defeat
malware in real time. To overcome such limitations, users
must gain root access, or “root” their phones.
Interest in rooting Androids extends well beyond technology
enthusiasts. According to Google, users install
non-malicious apps for rooting by a ratio of 494 per million total installs (https://docs.googlepresentation/d/1Y
DYUrD22Xq12nKkhBfwoJBfw2Q-OReMr0BrDfHyfyPw).
Of Google Play’s 10 best-selling paid apps, two require
root privilege—Titanium Backup at number 5 and Root
Explorer at number 8 (https://play.googlestore/apps/
collection/topselling_paid). In addition, big IT companies
like Tencent have invested millions of dollars to develop
robust tools for rooting Android phones (http://technews.
cn/2014/02/15/tencent-invest-mgyun), while community-built
ROMs that provide root access have enjoyed
large-scale adoption: CyanogenMod has over 10 million
installs (http://stats.cyanogenmod.com), and in China 80
percent of Android phones retailing for less than US$660
include customized ROMs with root access (http://it.21cn.
com/focus/a/2013/0803/09/23210909.shtml).
While attractive, rooting involves significant security
threats. After gaining root privilege, an app has access to
the entire system and to low-level hardware. Benign apps
exploit such access to provide desirable features for users,
but malicious apps could abuse it to make themselves irremovable,
bypass Android’s security measures,1,2 and infect
phones systemwide.
Independent developers have created apps to manage
root privilege, but the root-management model underlying
these apps remains vulnerable. Security Enhanced Android3
and its extensions4 might offer some protection, but
they do not give users root access and complicated policies
make them difficult to manage.
To address these issues, we propose RootGuard, a lightweight,
practical tool designed to protect rooted Android phones. Providing fine-grain
control, RootGuard lets users
grant an app the required operational
privileges according
to its invoked system calls and
parameters, while maintaining
default policies to guard itself
and the Android system against
malware attacks. In designing
RootGuard, we addressed
various challenges—determining
which functions it should
monitor, placing appropriate
function hooks, using kernel
memory to store policies and
exposing them through a virtual
device driver, among
others. Still, performance
evaluations including both
real-world and proof-of-concept
malware and employing
the benchmark app AnTuTu
show that RootGuard can successfully
mitigate attacks by
malware having root access,
and impose low overhead.
ROOTING ANDROID
AND MANAGING ROOT PRIVILEGE
In Linux, the su command—referring alternately to
“substitute user,” “super user,” or “switch user”—allows
a device operator to switch from current user to root
(functionally the administrator). In Android, the su command
enables only processes belonging to root or shell
to become root. The goal of rooting Android is to install
a customized and unrestricted su that allows any app
process to become root. While the mechanics vary depending
on device model, existing rooting methods fall
into two categories:
• Exploiting system vulnerabilities. Using this approach,
a potentially exploiting program is deployed on an Android
device and then executed to perform privilege
escalation. When successful, the procedure opens a
root shell, and the system partition (that is, /system)
can then be remounted as readable/writable, allowing
the customized su to be copied there. Most Android
devices can be rooted in this way.
• Flashing fastboot image. Fastboot allows users to
flash a complete file set or, alternately, a file system
bundled into a single file known as an “image” to
different locations of the file system, such as /boot
or /system. In fastboot mode, users can flash a
customized su into the system partition using the command fastboot flash. Relatively few devices
support this rooting method.
For inexperienced users, many automated tools are available
that make both types of rooting easier.
Once the customized su has been created, the next step
is installing an app to manage root privilege—that is, to
grant or deny other apps’ requests for root access. Such
apps, often designated Superuser, can be downloaded
from various sites (http://androidsusuperuser; www.
clockworkmod.com; www.chainfire.eu). Although some
differences exist among these apps, they all operate under
the basic root-privilege management model illustrated in
Figure 1. The original model, as shown on the left, changed
very little until Android 4.3 was introduced; more recently,
that model has required some modification to accommodate
later Android versions’ added security features, as
shown on the right.
An app requesting root privilege first invokes su. Then,
su sends a privilege-elevation request—or, more simply,
a root request—via an Intent messaging object to Superuser.
Next, Superuser consults its policy database to decide
whether to grant the request. If no corresponding policy
exists in its database, Superuser pops up a window asking
the user to make this decision. Superuser then sends the
decision either granting or denying the initial request for
root privilege back to su through a local socket, and su
grants the requesting app root privilege or denies it based
on the Superuser message.