Hybrid User-level Sandboxing of Third-party Android Apps

Zhou, Yajin; Patel, Kunal; Wu, Lei; Wang, Zhi; Jiang, Xuxian

doi:10.1145/2714576.2714598

Cited by 24 publications

(9 citation statements)

References 32 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The most notable work in this direction is Native Client [54] and Minibox [36]. There is also ARMLock [57] and AppCage [56], which achieve the same objective using ARM specific techniques. As mentioned in Section IV, these systems can be used to compliment SKEE in confining its environment to guarantee that it will not jump back to the kernel while the SKEE address space is exposed.…”

Section: Performance Enhancementmentioning

confidence: 99%

SKEE: A Lightweight Secure Kernel-level Execution Environment for ARM

Azab¹,

Swidowski²,

Bhutkar³

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Abstract-Previous research on kernel monitoring and protection widely relies on higher privileged system components, such as hardware virtualization extensions, to isolate security tools from potential kernel attacks. These approaches increase both the maintenance effort and the code base size of privileged system components, which consequently increases the risk of having security vulnerabilities. SKEE, which stands for Secure Kernellevel Execution Environment, solves this fundamental problem. SKEE is a novel system that provides an isolated lightweight execution environment at the same privilege level of the kernel. SKEE is designed for commodity ARM platforms. Its main goal is to allow secure monitoring and protection of the kernel without active involvement of higher privileged software.SKEE provides a set of novel techniques to guarantee isolation. It creates a protected address space that is not accessible to the kernel, which is challenging to achieve when both the kernel and the isolated environment share the same privilege level. SKEE solves this challenge by preventing the kernel from managing its own memory translation tables. Hence, the kernel is forced to switch to SKEE to modify the system's memory layout. In turn, SKEE verifies that the requested modification does not compromise the isolation of the protected address space. Switching from the OS kernel to SKEE exclusively passes through a well-controlled switch gate. This switch gate is carefully designed so that its execution sequence is atomic and deterministic. These properties combined guarantee that a potentially compromised kernel cannot exploit the switching sequence to compromise the isolation. If the kernel attempts to violate these properties, it will only cause the system to fail without exposing the protected address space. SKEE exclusively controls access permissions of the entire OS memory. Hence, it prevents attacks that attempt to inject unverified code into the kernel. Moreover, it can be easily extended to intercept other system events in order to support various intrusion detection and integrity verification tools. This paper presents a SKEE prototype that runs on both 32-bit ARMv7 and 64-bit ARMv8 architectures. Performance evaluation results demonstrate that SKEE is a practical solution for real world systems.

show abstract

Section: Performance Enhancementmentioning

confidence: 99%

SKEE: A Lightweight Secure Kernel-level Execution Environment for ARM

Azab¹,

Swidowski²,

Bhutkar³

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…Since an attacker can perform indirect attacks via static or shared libraries used by JNI, SFI also needs to confine memory access by such libraries by masking those two instructions used in such libraries. AppCage [47] applied this design in Android to prevent JNI libraries from accessing restricted APIs.…”

Section: ) Potential Attacksmentioning

confidence: 99%

FLEXDROID: Enforcing In-App Privilege Separation in Android

Seo¹,

Kim²,

Cho³

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Mobile applications are increasingly integrating third-party libraries to provide various features, such as advertising, analytics, social networking, and more. Unfortunately, such integration with third-party libraries comes with the cost of potential privacy violations of users, because Android always grants a full set of permissions to third-party libraries as their host applications. Unintended accesses to users' private data are underestimated threats to users' privacy, as complex and often obfuscated third-party libraries make it hard for application developers to estimate the correct behaviors of thirdparty libraries. More critically, a wide adoption of native code (JNI) and dynamic code executions such as Java reflection or dynamic code reloading, makes it even harder to apply state-ofthe-art security analysis.In this work, we propose FLEXDROID, a new Android security model and isolation mechanism, that provides dynamic, fine-grained access control for third-party libraries. With FLEXDROID, application developers not only can gain a full control of third-party libraries (e.g., which permissions to grant or not), but also can specify how to make them behave after detecting a privacy violation (e.g., providing a mock user's information or kill). To achieve such goals, we define a new notion of principals for third-party libraries, and develop a novel security mechanism, called inter-process stack inspection that is effective to JNI as well as dynamic code execution. Our usability study shows that developers can easily adopt FLEXDROID's policy to their existing applications. Finally, our evaluation shows that FLEXDROID can effectively restrict the permissions of third-party libraries with negligible overheads. versarial third-party libraries can bypass the proposed security mechanism. From our analysis of 100,000 Android apps, 72% of 295 third-party libraries are found to rely on dynamic code execution. Moreover, host apps and third-party libraries involve complex control-and data-flow dependencies through diverse features, such as class inheritance and callback methods. Unlike existing solutions that rely on static analysis [22,32,40] or

show abstract

“…Deepdroid [22] intercepts Binder transactions and traces system calls to provide portability and fine-grained control. The other approaches perform security enforcement at the application layer [8,9,12,17,23,27]. Aurasium [23] uses native library interposing to enforce arbitrary policies at runtime.…”

Section: Compatibilitymentioning

confidence: 99%

NativeProtector: Protecting Android Applications by Isolating and Intercepting Third-Party Native Libraries

Hong¹,

Wang²,

Yin³

2016

ICT Systems Security and Privacy Protection

View full text Add to dashboard Cite

Part 9: Software SecurityInternational audienceAn increasing number of Android developers are incorporating third-party native libraries in their applications for code reuse, CPU-intensive tasks and other purposes. However current Android security mechanism can not regulate the native code in applications well. Many approaches have been proposed to enforce security of Android applications, but few of them involve security of the native libraries in Android applications.In this paper, we propose NativeProtector, a system that regulates the third-party native libraries in Android applications. The standalone Android application is separated into two components: the server app and the client app where server app contains the native libraries for providing services from the native libraries while the client app contains the rest parts of the original app. The client app binds to the server app at the launching time, and all native function calls are replaced with interprocess calls to the server app. NativeProtector also generates the stub libraries intercept system calls in server app and enforce security of the native libraries in server app. We have implemented a prototype of NativeProtector. Our evaluation shows that NativeProtector can successfully detect and block the attempts of performing dangerous operations by the third-party native libraries in Android applications. The performance overhead introduced by NativeProtector is acceptable

show abstract

Hybrid User-level Sandboxing of Third-party Android Apps

Cited by 24 publications

References 32 publications

SKEE: A Lightweight Secure Kernel-level Execution Environment for ARM

SKEE: A Lightweight Secure Kernel-level Execution Environment for ARM

FLEXDROID: Enforcing In-App Privilege Separation in Android

NativeProtector: Protecting Android Applications by Isolating and Intercepting Third-Party Native Libraries

Contact Info

Product

Resources

About