TY - GEN
T1 - From system services freezing to system server shutdown in android
T2 - 22nd ACM SIGSAC Conference on Computer and Communications Security, CCS 2015
AU - Huang, Heqing
AU - Zhu, Sencun
AU - Chen, Kai
AU - Liu, Peng
N1 - Funding Information:
We greatly appreciate the insightful comments and constructive feedback from the anonymous reviewers. We would like to give special thanks to Dr. William Enck for his detailed instructions for preparing our camera ready version. This work was partially supported by NSF CCF-1320605, AROW911NF-13-1-0421 (MURI), NSF SBE-1422215 and NSFC 61100226 and Beijing Natural Science Foundation 4144089. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation and Army Research Office.
PY - 2015/10/12
Y1 - 2015/10/12
N2 - The Android OS not only dominates 78.6% of the worldwide smartphone market in 2014, but importantly has been widely used for mission critical tasks (e.g., medical devices, auto/aircraft navigators, embedded in satellite project). The core of Android, System Server (SS), is a multi-threaded process that contains most of the system services and provides the essential functionalities to support applications (apps). Considering the complicated design of the SS and its easily-accessible system services (e.g., via Android APIs), we conjecture that the SS may face DoS attacks. As the SS plays the important role in Android, serious DoS attacks could cause single-point-of-failure to the phone system. By studying the source code, we discovered a general design trait in the concurrency control mechanism of the SS that could be vulnerable to DoS attacks. To validate our hypothesis, we design a tool to cost efficiently explore high-risk methods in the SS. After a systematic analysis of 2,154 candidate-risky methods, we found four unknown vulnerabilities in critical services (e.g., the ActivityManager and the WindowManager), which are named the Android Stroke Vulnerabilities (ASVs). Exploiting the ASVs would continuously block all other requests for system services, followed by killing the SS and soft-rebooting the OS. Results of a further threat analysis show that by writing a loop to invoke Android APIs in an app, an attacker can continually freeze (reboot) the device at targeted critical moments (e.g., when patching vulnerable apps). Furthermore, ASVs can be exploited to enhance malware with anti-removal capability or to design the ransomware by putting the devices into continuous DoS loops. After being informed, Google confirmed our findings promptly. We also proposed to their Android framework team several improvements in their concurrency control design and a finegrained failure recovery mechanism for the SS.
AB - The Android OS not only dominates 78.6% of the worldwide smartphone market in 2014, but importantly has been widely used for mission critical tasks (e.g., medical devices, auto/aircraft navigators, embedded in satellite project). The core of Android, System Server (SS), is a multi-threaded process that contains most of the system services and provides the essential functionalities to support applications (apps). Considering the complicated design of the SS and its easily-accessible system services (e.g., via Android APIs), we conjecture that the SS may face DoS attacks. As the SS plays the important role in Android, serious DoS attacks could cause single-point-of-failure to the phone system. By studying the source code, we discovered a general design trait in the concurrency control mechanism of the SS that could be vulnerable to DoS attacks. To validate our hypothesis, we design a tool to cost efficiently explore high-risk methods in the SS. After a systematic analysis of 2,154 candidate-risky methods, we found four unknown vulnerabilities in critical services (e.g., the ActivityManager and the WindowManager), which are named the Android Stroke Vulnerabilities (ASVs). Exploiting the ASVs would continuously block all other requests for system services, followed by killing the SS and soft-rebooting the OS. Results of a further threat analysis show that by writing a loop to invoke Android APIs in an app, an attacker can continually freeze (reboot) the device at targeted critical moments (e.g., when patching vulnerable apps). Furthermore, ASVs can be exploited to enhance malware with anti-removal capability or to design the ransomware by putting the devices into continuous DoS loops. After being informed, Google confirmed our findings promptly. We also proposed to their Android framework team several improvements in their concurrency control design and a finegrained failure recovery mechanism for the SS.
UR - http://www.scopus.com/inward/record.url?scp=84954115060&partnerID=8YFLogxK
UR - http://www.scopus.com/inward/citedby.url?scp=84954115060&partnerID=8YFLogxK
U2 - 10.1145/2810103.2813606
DO - 10.1145/2810103.2813606
M3 - Conference contribution
AN - SCOPUS:84954115060
T3 - Proceedings of the ACM Conference on Computer and Communications Security
SP - 1236
EP - 1247
BT - CCS 2015 - Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security
PB - Association for Computing Machinery
Y2 - 12 October 2015 through 16 October 2015
ER -