Android Processes & Security
How I circumvented restricted Google APIs and discovered the Chinese applications that took advantage of it on 1.2 billion+ devices.
In 2015, I was working on an Android app that needed to retrieve a list of running process names to display to the user. Upon upgrading to Android 5.0 (Lollipop) I noticed that my app no longer worked as intended. The list of processes returned my application process only. I discovered that Google deprecated getRunningTasks(int) and getRunningAppProcesses() in Android 5.0. Both of these methods now only return the caller’s application process.
As an alternative workaround, Android 5.0 introduced UsageStatsManager which provides access to device usage history and statistics. This API requires the permission android.permission.PACKAGE_USAGE_STATS, which is a system-level permission and will not be granted to third-party apps. However, declaring the permission implies intention to use the API and the user of the device can grant permission through the Settings application. Several users and developers reported that some OEMs have removed this preference from Settings. Therefore, this isn’t very reliable and useful for developers or users who want to access information on what processes are running on a device.
I think every operating system should allow the user to easily discover what applications are currently running on a device and provide an API to do so. I was determined to find a way to get a list of running processes on Android 5.0. First, I ran the ps command in a shell and parsed the output. This worked but it wasn’t efficient. After seeing many fellow developers post about this issue on StackOverflow, I determined I would develop an open source library to work around Google’s changes.
In October 2015 I open sourced the AndroidProcesses library. To my surprise, the library started trending on GitHub and was quickly forked by developers in China where it received even more attention.
I recently decompiled the top 150 free apps on Google Play and was surprised by how many apps were using the library. Companies using the library include Cheetah Mobile and Baidu. Apps I found that are currently using the library include ES File Explorer, Clean Master, Security Master, CM Launcher 3D, Virus Cleaner by Hi Security, and Super Cleaner. Combined, these apps have at least 1.2 billion downloads!
I personally don’t like these “task manager” type apps that falsely promise to boost your device’s performance. Apparently, Google is not so fond of these large Chinese firms’ apps either. One may wonder if Google and these large Chinese firms are both collecting app usage statistics to improve ad targeting and Google’s restrictions are mainly aimed at these firms rather than for security reasons.
In Android 7.0 (Nougat) Google significantly restricted access to the file system which makes it impossible to get a list of running processes using my library. The lead developer of CopperheadOS was kind enough to outline the changes reducing access to /proc:
The procfs filesystem is now mounted with hidepid=2, eliminating access to the /proc/PID directories of other users. This change was implemented in CopperheadOS and was then adopted upstream based on it. There’s a group for making exceptions but it’s not exposed as a permission. It’s only used to make exceptions for some processes in the base system. It could be exposed as a ‘dangerous’ permission and it’s what I expected Google would end up doing but they decided that users wouldn’t understand the implications of it.
https://android-review.googlesource.com/#/c/181345/
SELinux policies also became much stricter. For apps, there’s no baseline access to /proc at all anymore, although that only applies to files other than the /proc/PID directories. There’s still access to a few files with labels not falling under the general proc policy, but it’s mostly gone. This has been gradual and there are many relevant commits. One of the big ones:
https://android-review.googlesource.com/#/c/105337/
This not only removes a lot of obvious information, but it also closes some more blatant security holes involving side channels allowing things like logging keyboard input:
- https://www.lightbluetouchpaper.org/2016/07/29/yet-another-android-side-channel/
- https://staff.ie.cuhk.edu.hk/~khzhang/my-papers/2016-oakland-interrupt.pdf
SELinux policies have also become a lot stricter in general over time. You can see the rest of that in the platform/system/sepolicy repository. Note that it was at platform/external/sepolicy for a long time but it was recently moved.
See: https://stackoverflow.com/a/38728738/1048340
In Android 7.0+ Google’s pre-installed apps will have access to application process information while excluding that information from third-party apps. According to an Android Platform Security Engineer at Google these changes were made to prevent phishing attacks. The Google engineer cited the following two articles in a comment on Android public issue tracker:
- http://www.cnet.com/news/android-could-allow-mobile-ad-or-phishing-pop-ups/
- https://www.usenix.org/system/files/conference/woot12/woot12-final7.pdf
However, Tod Liebeck (Founder of NextApp, Inc. which earned Google’s Top Developer Badge) quickly responded by demonstrating that such an attack was still possible in the latest version of Android. Tod’s reply to the security engineer:
I’m quite frankly stunned by this.
I’m an app developer, not a security researcher. What you’ve cited is certainly a real problem, but I believe you are solving it in the wrong way.
And when I say I’m stunned, I mean I’m so stunned I made a demonstration video of the type of malware attack that you are describing here, and I’m running it on an Android N device:
https://www.youtube.com/watch?v=SkvHA1jBpn8
The changes that have been made to Android N which cripple SystemPanel (and other system utilities, security, and antivirus apps) will do little to stop this kind of attack. Again, the only real beneficiaries will be the malware authors who are better able to hide.
In the video above, the fake malware app–which took about 30 minutes to write, by someone who has never written even “fake” malware before–successfully does exactly what you’re talking about on an Android N device. You’re eliminating one way an app can monitor the operations of others, but there are myriad more. The demo above is triggered by network activity to the target app’s network. An identical attack is possible by monitoring that app’s public directory structure on the filesystem.
The real problem here is that applications are permitted to launch themselves arbitrarily. The fake malware demo above launches from a service. This behavior should ABSOLUTELY NOT BE ALLOWED. I had no idea this was possible until I tried it (given that arbitrarily launching an app to the foreground has never come up…perhaps because the only reasons I can think for doing so are malicious).
It seems Google has no plans on providing access to /proc to third-party apps and has since closed the issue. Accordingly, I plan on deprecating the AndroidProcesses library. Hopefully Google will do what CopperheadOS expected them to do and expose a ‘dangerous’ permission allowing users to grant third-party apps access to running app process info.
