Biblio

The increasing vulnerabilities in Android kernel make it an attractive target to the attackers. Most kernel-targeted attacks are initiated through system calls. For security purpose, Google has introduced a Linux kernel security mechanism named “seccomp” since Android O to constrain the system calls accessible to the Android apps. Unfortunately, existing Android seccomp mechanism provides a fairly coarse-grained restriction by enforcing a unified seccomp policy containing more than 250 system calls for Android apps, which greatly reduces the effectiveness of seccomp. Also, it lacks an approach to profile the unnecessary system calls for a given Android app. In this paper we present a two-level control scheme named SASAK, which can shrink the attack surface of Android kernel by strictly constraining the system calls available to the Android apps with seccomp mechanism. First, instead of leveraging a unified seccomp policy for all Android apps, SASAK introduces an architecture- dedicated system call constraining by enforcing two separate and refined seccomp policies for the 32-bit Android apps and 64-bit Android apps, respectively. Second, we provide a tool to profile the necessary system calls for a given Android app and enforce an app-dedicated seccomp policy to further reduce the allowed system calls for the apps selected by the users. The app-dedicated control could dynamically change the seccomp policy for an app according to its actual needs. We implement a prototype of SASAK and the experiment results show that the architecture-dedicated constraining reduces 39.6% system calls for the 64-bit apps and 42.5% system calls for the 32-bit apps. 33% of the removed system calls for the 64-bit apps are vulnerable, and the number for the 32-bit apps is 18.8%. The app-dedicated restriction reduces about 66.9% and 62.5% system calls on average for the 64-bit apps and 32-bit apps, respectively. In addition, SASAK introduces negligible performance overhead.

TEE(Trusted Execution Environment) has became one of the most popular security features for mobile platforms. Current TEE solutions usually implement secure functions in Trusted applications (TA) running over a trusted OS in the secure world. Host App may access these secure functions through the TEE driver. Unfortunately, such architecture is not very secure. A trusted OS has to be loaded in secure world to support TA running. Thus, the code size in secure world became large. As more and more TA is installed, the secure code size will be further larger and larger. Lots of real attack case have been reported [1]. In this paper, we present a novel TEE constructing method named ALTEE. Different from existing TEE solutions, ALTEE includes secure code in host app, and constructs a trustworthy execution environment for it dynamically whenever the code needs to be run.

Linux container mechanism has attracted a lot of attention and is increasingly utilized to deploy industry applications. Though it is a consensus that the container mechanism is not secure due to the kernel-sharing property, it lacks a concrete and systematical evaluation on its security using real world exploits. In this paper, we collect an attack dataset including 223 exploits that are effective on the container platform, and classify them into different categories using a two-dimensional attack taxonomy. Then we evaluate the security of existing Linux container mechanism using 88 typical exploits filtered out from the dataset. We find 50 (56.82%) exploits can successfully launch attacks from inside the container with the default configuration. Since the privilege escalation exploits can completely disable the container protection mechanism, we conduct an in-depth analysis on these exploits. We find the kernel security mechanisms such as Capability, Seccomp, and MAC play a more important role in preventing privilege escalation than the container isolation mechanisms (i.e., Namespace and Cgroup). However, the interdependence and mutual-influence relationship among these kernel security mechanisms may make them fall into the "short board effect" and impair their protection capability. By studying the 11 exploits that still can successfully break the isolation provided by container and achieve privilege escalation, we identify a common 4-step attack model followed by all 11 exploits. Finally, we propose a defense mechanism to effectively defeat those identified privilege escalation attacks.