Affiliations: [a] School of Information Systems, Singapore Management University, Singapore | [b] Institute of Software, Chinese Academy of Sciences, Beijing, P.R. China | [c] University of Chinese Academy of Sciences, Beijing, P.R. China | [d] Singapore Institute of Manufacturing Technology, Singapore, Singapore
Abstract: Root is the administrative privilege on Android, which is however inaccessible on stock Android devices. Due to the desire for privileged functionalities and the reluctance of rooting their devices, Android users seek for no-root approaches, which provide users with part of root privileges without rooting their devices. Existing no-root approaches require users to launch a separate service via Android Debug Bridge (ADB) on an Android device, which would perform user-desired tasks. However, it is unusual for a third-party Android application to work with a separate native service via sockets, and it requires the application developers to have extra knowledge such as Linux programming in application development. In this paper, we propose a feasible no-root approach based on new functionalities added on Android, which creates no separate service but an ADB loopback. To ensure such no-root approach is not misused in a proactive instead of reactive manner, we examine its dark side. We find out that while this approach makes it easy for no-root applications to work, it may lead to a “permission explosion,” which enables any third-party application to attain shell permissions beyond its granted permissions. The permission explosion can further lead to exploits including privacy leakage, account takeover, application UID abuse, and user input inference. A practical experiment is carried out to evaluate the situation in the real world, which shows that many real-world applications from Google Play and four third-party application markets are indeed vulnerable to these exploits. To mitigate the dark side of the new no-root approach and make it more suitable for users to adopt, we identify the causes of the exploits, and propose a permission-based solution. We also provide suggestions to application developers and application markets on how to prevent these exploits.
