The Peril of Fragmentation: Security Hazards in Android Device Driver CustomizationsXiaoyong 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)

2

Outline• Introduction• Vendor Customizations on Android• Findings and Attacks• A Large-scale Measurement Study• Discussion and Conclusion

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

13

Findings.2014/5/19

14

Findings.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

16

ADDICTED• Android Device Customization Error Detector

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

18

The Design2014/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

20

The Approach2014/5/19

21

Test Cases2014/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 well-formatted.

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

32

Findings• Device files:

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

35

Attack: Hidden Camera2014/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

38

A Large-Scale Measurement Study• Gathered images

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

41

Distribution of The Flaws2014/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

43

Distribution of The Flaws2014/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

45

Popular Open Device Files2014/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.

2014/5/19