1 / 47

AirBag : Boosting Smartphone Resistance to Malware Infection

AirBag : Boosting Smartphone Resistance to Malware Infection. Chiachih Wu†, Yajin Zhou†, Kunal Patel†, Zhenkai Liang∗, Xuxian Jiang † † Department of Computer Science, North Carolina State University {cwu10, yajin zhou , kmpatel4, xjiang4}@ ncsu.edu

jaquelyn-albert
Download Presentation

AirBag : Boosting Smartphone Resistance to Malware Infection

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. AirBag: Boosting Smartphone Resistance to Malware Infection Chiachih Wu†, Yajin Zhou†, Kunal Patel†, Zhenkai Liang∗, Xuxian Jiang† † Department of Computer Science, North Carolina State University{cwu10, yajinzhou, kmpatel4, xjiang4}@ncsu.edu ∗ School of Computing, National University of Singapore liangzk@comp.nus.edu.sg NDSS Security 2014

  2. Outline • Introduction • System Design • Implementation • Evaluation • Discussion • Related Work

  3. Introduction • Recent years have experienced explosive growth of smartphone sales. Inevitably, the rise in the popularity of smartphones also makes them an attractive target for attacks. • To make matters worse, the presence of alternative mobile marketplaces also opens up new attack vectors, which necessitate client-side to run on mobile devices.

  4. Introduction • Aurasiumis proposed to enforce certain access control policies on untrusted apps. However, it requires apps to be repackaged. • L4Android and Cells take a virtualization-based approach, however, the offered isolation is too coarse-grained. • Unlike previous studies, AirBag mainly focuses on utilizing already built-in Linux kernel features: cgroup and namespaces.

  5. AirBag • Assuming a trusted smartphone OS kernel and the fact that untrusted apps will be eventually installed onto users’ phones, AirBag is designed to isolate and prevent them from infecting our normal systems or stealthily leaking private information.

  6. Linux cgroup • Control Groups provide a mechanism for aggregating/partitioning sets of tasks, and all their future children, into hierarchical groups with specialized behavior.-- kernel.org https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt

  7. Linux cgroup • cgroups (control groups) is a Linux kernel feature to limit, account and isolate resource usage (CPU, memory, disk I/O, etc.) of process groups. • Stored in `css_set` structure. • Start by Google, merged in kernel version 2.6.24. • cgroup can: • Resource limiting • Prioritization • Accounting • Control

  8. Linux cgroup http://www.oracle.com/technetwork/articles/servers-storage-admin/resource-controllers-linux-1506602.html

  9. Linux cgroup https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-Relationships_Between_Subsystems_Hierarchies_Control_Groups_and_Tasks.html

  10. Linux namespaces • PID namespace isolation • Sees different PIDs (starting from 1(init.d)) • Network namespace isloation • connect to other namespaces via veth virtual interfaces • UTS namespace isolation • different hostname, domain name • Mount namespace isolation • IPC namespace isolation • Used by many OS-level virtualization, like OpenVZ, LXC,

  11. System Design • Design Goal: • First, AirBag should reliably confine untrusted apps such that any damage they may incur would be isolated without affecting the native phone environment. • Second, AirBagshould achieve safe and seamless user experience throughout the lifespan of untrusted apps. • Third, because AirBag is deployed in resource-constrained mobile devices, it should remain lightweight and introduce minimal performance overhead.

  12. System Design • Incognito mode:Designed to completely remove personally-identifying information about the phone or the user's information.(returning fake information) • Profiling mode:Log detailed execution traces for analyzing. • Normal mode:Execute the app without isolation.

  13. System Design Challenges: mobile device doesn't have enough hardware power of support (VT-x) to support hardware-level virtualization. Also, CPU power, battery, memory are limited. Under the above reasons, AirBag chose to adopt the OS-level virtualization mechanism.

  14. System Design

  15. Threat Model and System Assumption • Users will download and install third-party untrusted apps. These apps may attempt to exploit vulnerabilities, especially those in privileged system daemons such as Zygote. • Meanwhile, we assume a trusted smartphone OS kernel, including our lightweight OS extension to support isolated namespace and virtualized system resources.

  16. Enabling Techniques Decoupled App Isolation Runtime (AIR): • A separate app isolation runtime that allows apps to run on it and has (almost) no interaction with the original Android runtime. • AIR does not need to be trusted as it might be potentially compromised by untrusted apps

  17. Enabling Techniques Namespace/Filesystem Isolation: • AirBag also provides a different namespace and filesystem to further restrict and isolate the capabilities of processes running inside. • All processes running inside have their own view of running PIDs, which is completely different from external processes.(Utilizing Linux cgroup)

  18. Enabling Techniques Context-Aware Device Virtualization • Virtualize hardware devices in a context-aware manner. • Specifically, our lightweight OS extension adds necessary multiplexing and demultiplexing mechanisms in place when the hardware devices are being accessed. (always allowing the active runtime to access the hardware resources.)

  19. Implementation We have implemented a proof-of-concept AirBagprototype on three different mobile devices • Google Nexus One, kernel 2.6.35.7 • Nexus 7, kernel 3.1.10 • Samsung Galaxy S III, kernel 3.0.8

  20. Namespace/Filesystem isolation • First, create a new namespace and then starts the very first process (i.e., airbag_init) inside AirBag. • The airbag_init process will then bootstrap the entire AIR.(the new namespace is created by cloning a new process with a few specific flags: CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWIPC, CLONE_NEWUTS, and CLONE_NEWNET.)

  21. Namespace/Filesystem Isolation • Then, before switching the control to the airbag_init program, we initialize a separate root filesystem for the newly clone’d process which contains essential AIR files. • Also prepares sysfs, procfs file systems. • After that, we yield the control by actually executing the airbag_init program that then kicks off the entire AIR, including various services.

  22. Namespace/Filesystem Isolation • However, some features may require inter-namespace communication. • Virtualizing a network device inside AirBag and connect it to a pre-allocated bridge interface on the native Android system.(veth – virtual ethernet device)

  23. Namespace/Filesystem Isolation • When a process is clone’d with the CLONE_NEWNS flag, an instance of structnsproxywould be allocated in Linux kernel to store the information of the new namespace. • When a process accesses system resources (e.g., via ioctl), we consult the nsproxy pointer of its task_struct via the current pointer and use it to guide proper access to virtualized system resources.

  24. Context-Aware Device Virtualization • Framebuffer/GPU In Android, all the visual content to be shown by running apps are synthesized by the screen updater (SurfaceFlinger) to the framebuffermemory Solution: allocates a second framebuffer.

  25. Context-Aware Device Virtualization On Nexus One there is a device /dev/pmem used by userspace screen updater. Solution: creating a separate /dev/pmem (/dev/pmem-airbag) device for each namespace

  26. Input Devices • Linux kernel has a generic layer, i.e., evdev (event device), which connects various input device drivers to upper-layered software components. • Android runtime will register itself as a client represented as evdev_client in OS kernel. • Upon the input event registration, AirBagwill record its namespace into the evdev_client data structure. When an input event occurs, the kernel deliver it only to the registered clients from the active namespace.

  27. IPC • Android uses binder and servicemanager to fulfill IPC requests. • AirBag creates a separate context manager for AIR, so that all inter-app communications (e.g., intents) are fully supported within AirBag.

  28. Telephony • A service daemon, rild, loads vendor-proprietary. • AirBag multiplex the hardware access at the user level rild by creating a TCP socket, allowing outgoing calls

  29. Audio • Nexus One uses a device /dev/q6dsp for audio accesses. • Nexus 7 and Galaxy S III uses ALSA, only allowing one active audio stream concurrently. • Solution: create a separated device node.

  30. Power Management • AirBag disables any power-related operations inside the isolated runtime, allowing only the native runtime to perform actions like suspending the phone. • When the isolated runtime is active, AirBag will acquire a wakelock, preventing the phone from going into suspend mode.

  31. Decoupled App Isolation Runtime • The whole AIR is build on AOSP 4.1.1, using unionfsas the filesystem, then copy-on-write all changes into a ext4-based disk image, and a squashfs image for read-only operations. • In addition, AIR is designed to prevent untrusted apps from performing stealthy actions (e.g., sending SMSes). • A whitelist is supported. • When user is attempting to install an app, a customized PackageInstaller is called, then the user can decide whether to put the app into isolation or not.

  32. Evaluation

  33. Evaluation • AirBag is able to successfully isolate these malicious apps and prevent them from performing the malicious operations in either Android framework level or OS kernel level • GoldDream: spies on SMS, monitors incoming/outgoing phone calls, and then stealthily uploads them as well as device information to a remote server. • DFKBootkit: infects Android boot sequences, replacing various system utilities (rm, ifconfig, etc) • HippoSMS: sends SMS to a premium rate number

  34. Evaluation: HippoSMS

  35. Performance Impact • Evaluation: • Baseline: no AirBag, device /w stock kernel • Busy-NA: with AirBag kernel extension but not activated • Busy-Idle: runs benchmark app in native runtime, while AirBag in the background • Idle-Busy: runs benchmark app in AirBag runtime, while native runtime in the background

  36. Performance Impact

  37. Performance Impact

  38. Performance Impact

  39. Performance Impact • Overall, in Incognito mode, AirBagshows around 2.5%in both GPU-intensive workloads (Neocore and NenaMark2) and CPU/IO-intensive workloads (SunSpider and BrowserMark). • On AnTuTu, the performance overhead is around 2%. • Additional 10% overhead for profiling mode.

  40. Power Consumption and Memory Usage • A fully-charged Nexus 7 device, wait for 24 hours without running any workload. The stock system reports 91%, while AirBag-enhanced system shows 89%. • When playing an audio file, stock system reports 66%, while AirBag-enhanced system shows 63%. • Memory usage in 4 hours, the stock system shows 59.31%, compared to AirBag, 60.87%,

  41. Discussion In order to move the app from native runtime to the isolated runtime, the app has to be uninstalled first, then installed again. A better solution might lively migrate it from one to another. Also, apps in the isolated runtime are not able to communicate with those in the native runtime, this affects certain app behaviors in the isolated runtime. (workaround: whitelists.)

  42. Discussion Third, without hardware support, the number of isolated runtimes are limited by CPU power and memory capacity. Malicious apps may be able to detect whom it is put in the isolated runtime or not.

  43. Related Work • Server-side protection • Google introduces the bouncer service in February, 2012, while enforcing scans on its Google Play market. • Client-side protection • MoCFIprovides a CFI enforcement framework to prohibit runtime and control-flow attacks for Apple iOS. • TaintDroidextends the Android framework to monitor the information flow of privacy-sensitive data. • Aurasiumrepackagsuntrusted apps and then enforcing certain access control policies at runtime. • Cells introduces a foreground /background virtual phones usage model and proposes a lightweight OS-level virtualization.

  44. Conclusion By instantiating a separate app isolation runtime that is decoupled from native runtime and enforced through lightweight OS-level virtualization, AirBag not only allows for transparent execution of untrusted apps, but also effectively prevents them from leaking personal information or damaging the native system. The evaluation results with 20 representative Android malware successfully demonstrate its practicality and effectiveness, with minimal performance impacts.

More Related