The Peril of Fragmentation:
Security Hazards in
Android Device Driver Customizations
Xiaoyong Zhou*, Yeonjoon Lee*, Nan Zhang*,
Muhammad Naveed† and XiaoFeng Wang*
* School of Informatics and Computing, Indiana University, Bloomington
† Department of Computer Science, University of Illinois at Urbana-Champaign
35th IEEE Symposium on Security and Privacy (Oakland '14)
2014/5/19
Outline
• Introduction
• Vendor Customizations on Android
• Findings and Attacks
• A Large-scale Measurement Study
• Discussion and Conclusion
2
2014/5/19
3
Introduction
• Up to August 2013, Android has dominated global smartphone
shipments with nearly 80% market share.
• Android Open Source Project
• Since 2009, 19 official Android versions have been released.
2014/5/19
4
Security Risks in Customizations
• For each new Android version, Google first releases it to
mobile phone vendors, allowing them to add their apps,
device drivers and other new features to their corresponding
Android branches.
• Recent studies show that many pre-loaded apps on those
images are vulnerable, leaking system capabilities or sensitive
user information to unauthorized parties.
2014/5/19
5
Security Risks in Customizations
• The security risks here, however, go much deeper than those
on the app layer.
• Particularly, they almost always need to modify a few device
drivers (e.g., for camera, audio, etc.) and related system
settings to support their hardware.
2014/5/19
6
Security Risks in Customizations
• Device drivers work on the Linux layer and communicate with
Android users through framework services.
• Therefore, any customization on an Android device needs to
make sure that it remains well protected at both the Linux and
framework layers.
• However, vendors usually doesn't have the time to properly
address such problems.
2014/5/19
7
Vendor Customizations On Android
• The Android security model is built upon Linux user and
process protection. (UID/GID)
• Decisions on granting those permissions are made either by
the system through checking the app’s signatures or by the
user.
2014/5/19
8
Vendor Customization
• On a vendor-customized phone, only about 18% come from
AOSP, 65% from the vendors, 17% from third parties.
• Manufactures have only about 6 months to customize the
official version.
• it has been reported that over 60% of the app vulnerabilities
found in a study come from vendor customizations.
2014/5/19
9
Android Linux Devices
• Block devices (e.g., flash drives) and stream devices (e.g.,
virtual terminals) are placed under /dev.
• Other devices like network devices are placed under other
directories (e.g., /sys).
2014/5/19
10
Android Linux Devices
• However, there are no standards regarding hardware nodes.
• As an example, the near field communication (NFC) device
node is /dev/bcm2097x-12c on the Nexus 4 Android 4.2,
while on Samsung SII, it becomes /dev/pn544.
2014/5/19
11
Adversary Model
• To evaluate such risks, we assume the presence of malicious
apps on the phone running a customized Android OS.
• These apps do not have root privileges, nor do they have the
permissions to use the devices under investigation, such as
camera, audio, GPS, etc.
2014/5/19
12
Methodology
• Compare the source code of two popular vendor customized
phones – Samsung Galaxy SII and Samsung Galaxy Ace 3 with
corresponding AOSP references.
• For each pair, a diff-tool (DeltaWalker) is used to measure file
changes.
2014/5/19
Findings.
13
2014/5/19
Findings.
14
2014/5/19
15
Findings
• Changes made on the Linux layer mainly happen to the driver
source-code directory.
• On the framework layer, most of the customizations are either
related to device (/device/samsung/bcm_common) or new
apps (/vendor/samsung/common/packages)
2014/5/19
ADDICTED
• Android Device Customization Error Detector
16
2014/5/19
17
The Design
• To identify these files, ADDICTED runs a suite of test cases
that serve as an input to the dynamic analyzer.
• The analyzer traces the execution of the Android system when
it is processing these cases and operating on their related
devices.
• Then, compared with them in terms of individual files’ Linux
permission settings.
2014/5/19
The Design
18
2014/5/19
19
The Approach
• Device Miner is a dynamic analyzer that works on the system-
call level.
• Device Miner utilizes a suite of test cases to trigger device
operations such as taking pictures, requesting geo-locations,
etc., and attaches strace to the app that runs those cases.
• Also, an instrumented binder is made to follow the IPC call
and identify the system process that serves the app’s request.
2014/5/19
The Approach
20
2014/5/19
Test Cases
21
2014/5/19
22
Dynamic Analysis
• As soon as Device Miner starts the Test Runner, it attaches a
tracer (a wrapper of strace) to the app's process.
• API calls goes through the binder driver in the kernel, which
passes the request to a system service.
• Our approach instruments binder.c with the code for
inspecting individual transactions.
2014/5/19
23
Dynamic Analysis
• During its runtime, this modified binder checks the
transaction parameters of an IPC call to extract the source
Process Identifier (PID) of the transaction and its target PID,
along with the data (parameter).
• The source PID is directly retrieved from binder_proc.pid and the
target one is obtained from target_node, which is referred by
target_handler.
• If either party in the IPC is found to be the test app, Device
Miner attaches a tracer to the one that has not been
monitored yet.
2014/5/19
24
Dynamic Analysis
• Manufactures rarely modify the framework layer services
• Also, they tend to leave the package names of the services
intact.
• Assuming that the names of the services working on a device-
related request stay unchanged across different Android OSes.
2014/5/19
25
Differential Analysis
• To achieve portability, Device Miner tracks device operations
at the system-call level.
• To remove random noise, Device Miner performs a differential
analysis on the outcomes of an analysis, comparing them with
those produced by other independent tests.
2014/5/19
26
Risk Identifier
• we need to find out whether their security protection levels are
properly set.
• we simply take the way those device-related files are
configured on AOSP OSes as references.
2014/5/19
27
Device File Correlations
• the camera device node on Nexus 4 (with an Android 4.2) is
video0 or video1 under the group camera
• On Galaxy GRAND, it becomes vc-cam and affiliated with the
Linux group system.
2014/5/19
28
Device File Correlations
• Specifically, for each file, Device Miner look at the set of
system calls that touch the file, and the content and other
features of those calls’ arguments.
• Customized devices (camera, video, Bluetooth, etc.) tend to
follow their industry standards (e.g. camera devices designed
according to the V4L2 driver framework)
• They all share some arguments for the ioctl call that operates on them,
such as 0x560f (parsed into VIDIOC_QBUF).
2014/5/19
29
Device File Correlations
• An example is NFC, whose call sequence is always (select, read,
write) with the 2nd arguments of read and write being wellformatted.
2014/5/19
30
LCF Detection
• After pairing individual device files on a customized phone
with those in a reference, an analysis tool starts checking their
Linux file permissions.
(e.g. file permission and group owners)
2014/5/19
31
Finding And Attacks
• These phones includes:
• Google Nexus 4 with an Android 4.2
• Samsung Galaxy SII with a customized 4.0.3
• Galaxy ACE 3 with a 4.2.2
• Galaxy GRAND with a 4.1.2
• This study discovered 4 LCFs and all of them were confirmed
to be indeed problematic.
2014/5/19
Findings
• Device files:
32
2014/5/19
33
Attack: Touchscreen Keylogger
• On Galaxy SII, /dev/input/event2 were made public.
• The Android input system includes three components,
EventHub, EventReader and EventDispatcher.
• Attack: one can implemented its own reader, extracting X and
Y coordinates. Therefore, it is ableable to log the text user
inputs, without ANY permission required.
• Demo video:
https://www.youtube.com/watch?v=9-wAXRBd_uw
2014/5/19
34
Attack: Hidden Camera
• On Galaxy SII, the camera file /dev/video0 (both front and
back camera) is made public.
• Attack: construct an HAL, issuing custom ioctl commands
• Varies between chip/devices, may lead to device reboot -> DoS attack
• Have to select camera by issuing VIDEO_S_INPUT.
• Demo video:
https://www.youtube.com/watch?v=crYC2do37y4
2014/5/19
Attack: Hidden Camera
35
2014/5/19
36
Attack: Screen Capture
• On Galaxy ACE 3 GT-7270L (4.2.2), frame buffer
/dev/graphics/fb0 is publicly readable and writable.
• For Samsung Notes app maybe?
• Attack: malicious app can take screenshots without ANY
permission by reading directly to the frame buffer.
• Demo video:
https://www.youtube.com/watch?v=rIk6dXNUo5Q
2014/5/19
37
A Large-Scale Measurement Study
• Device nodes are typically located under /dev and /sys,
which are dynamic generated when kernel boots up.
• init calls ueventd, which loads ueventd.rc and
ueventd.$HARDWARE.rc
• Gathered 2423 images covering 417 phone models ranging
from android 4.0 to 4.3. (2.5TB disk size) by using a crawler.
• Unpack zImage, boot.img
• Parse the .rc files, than analyze the permissions
2014/5/19
A Large-Scale Measurement Study
• Gathered images
38
2014/5/19
39
Pervasiveness of LCFs
• 1290 (53.24%) images we studied contain LCFs.
• At least one device file permission is set to publicly readable/writable
• Such LCFs affect 75.65% of the distinct phone models and
86.65% of the carriers we studied.
2014/5/19
40
Distribution of The Flaws
• Developing countries (e.g., China, Brazil) host more vulnerable phone
models.
2014/5/19
Distribution of The Flaws
41
2014/5/19
42
Distribution of The Flaws
• When phones are upgraded from 4.0.3 to 4.1, the percentage
of vulnerable models drops to 18%.
• However, it goes up to round 30% for 4.1.2 and 4.3.
2014/5/19
Distribution of The Flaws
43
2014/5/19
44
Distribution of The Flaws
• 92 phone models have at least one of the LCFs, including the 3
confirmed vulnerabilities
• Only on 6 phone models, the vendors have completely
addressed all their LCFs through updates.
2014/5/19
Popular Open Device Files
45
2014/5/19
46
More Attacks
• vc-lmk (low memory killer)
• Malicious apps could kill any desired app without any permission by
issuing special crafted ioctl commands
• SurfaceFlinger
• Malicious could alter on-screen objects
• UMP (Unified Memory Provider)
• UMP_IOC_ALLOCATE for allocating memory and copying user data to
kernel, and UMP_IOC_MSYNC for cache maintenance.
2014/5/19
47
Discussion
• Under /dev, still dozens of files are there which we cannot
interpret.
• Confirmation of security flaws still needs a manual analysis.
• Also, ADDICTED is not designed to identify the device file
configuration problems on the official Android OSes.
2014/5/19
48
Conclusion
• The openness of Android has brought in a fragmented
ecosystem with significant security implications
• We found the presence of customization errors in the security
con- figurations of device-related files on a large number of
Android phones, across multiple OS versions, different
vendors, carriers and regions, leading to complete exposure of
critical system resources and capabilities.