1 / 48

The Peril of Fragmentation: Security Hazards in Android Device Driver Customizations

The Peril of Fragmentation: Security Hazards in Android Device Driver Customizations. Xiaoyong Zhou *, Yeonjoon Lee*, Nan Zhang *, Muhammad Naveed † and XiaoFeng Wang *.

veata
Download Presentation

The Peril of Fragmentation: Security Hazards in Android Device Driver Customizations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Peril of Fragmentation: Security Hazards in Android Device Driver Customizations XiaoyongZhou*, YeonjoonLee*, NanZhang*, Muhammad Naveed† and XiaoFengWang* * School of Informatics and Computing, Indiana University, Bloomington† Department of Computer Science, University of Illinois at Urbana-Champaign35th 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

  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.

  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.

  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.

  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 frameworklayers. • However, vendors usually doesn't have the time to properly address such problems.

  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.

  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.

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

  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.

  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.

  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.

  13. Findings.

  14. Findings.

  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)

  16. ADDICTED • Android Device Customization Error Detector

  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.

  18. The Design

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

  20. The Approach

  21. Test Cases

  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.cwith the code for inspecting individual transactions.

  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.

  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.

  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.

  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.

  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.

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

  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.

  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)

  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.

  32. Findings • Device files:

  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

  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

  35. Attack: Hidden Camera

  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

  37. A Large-Scale Measurement Study • Device nodes are typically located under /devand /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 .rcfiles, than analyze the permissions

  38. A Large-Scale Measurement Study • Gathered images

  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.

  40. Distribution of The Flaws • Developing countries (e.g., China, Brazil) host more vulnerable phone models.

  41. Distribution of The Flaws

  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.

  43. Distribution of The Flaws

  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.

  45. Popular Open Device Files

  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.

  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.

  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.

More Related