Alrighty, let me put on my software engineering hat and pickup on some regular blogging about important topics!
This is a continuation of my discussion on Android Security. Last time I talked about obtaining root on your phone. Once a phone is rooted the ability to modify system files can be requested by any application running on the phone. The key point being that applications request the ability to operate as the root user, they are not given the ability to do so by default.
I’ve recently been reading about a project called the Xposed Framework. It’s a Github project designed to add hooks into the various methods and functions of applications running on an Android OS. The framework modifies a system file in order to run code at the lowest level of OS execution. The framework doesn’t do anything on its own. What it does is allow various modules, setup within the framework, to hook into the desired methods and functions by use of Java’s Reflection APIs.
The power comes from the ability to execute code both before and after any method is run on the OS. A module can modify the parameters used to check for the phone manufacturer type in order to allow an otherwise unintended application to run on any handset. Another use is for themers to access how the UI elements are displayed.
Broken down here is how the process works for a module utilizing the Xposed Framework running on an Android phone:
- First the Xposed Framework is loaded on to a phone. The user uses an “installer” or bootstrapping application in Java to launch into recovery mode where the framework is placed into the system. Obviously this requires the user’s phone be rooted and the user to have given permission to the installer to execute root functionality.
- NOTE: At this point I’m explaining the intended use of the framework. Please don’t misread the above as the framework executing commands on its own.
- Once the framework is installed the user will load various modules on to their phone which use the framework to modify some behavior.
- In order to use a module the user must whitelist module. No module gains access to the framework by default.
- After the module has been granted access it retains that access indefinitely and runs as the developer of the module intended. The module operates at one of the lowest levels of system operation.
The steps above describe a real use of the framework with no malicious intent.
The key difference between standard SU management of root access and the Xposed Framework is that with SU management an application must always ask for root on every use of elevated privileges and is logged within the management application. With the Xposed Framework the module runs continually and without any monitoring. I’ll concede that most SU management applications allow the user to give an indefinite time period to applications requesting elevated privileges but each time the application uses those privileges it is recorded in a log file. This does not appear to be the case with the Xposed Framework.
Here’s a Little Scenario For Ya!
Assume a user has gone through the above steps to load the framework in order to achieve some legitament use of the framework. Perhaps, they want to use Google Wallet on a Verizon phone. Once the framework has been installed they whitelist the Google Wallet module within the framework. At this point nothing malicious has happened and no unintended use of the framework has occurred.
After some point a malicious application is installed. When the user opens this application it asks for root to perform some operation. If the user allows root access then bad things could occur. Our first thought is that the malicious action could take place through the use of elevated permissions within this first use of root. For the malicious application to do this would be silly because every time it wanted to perform some nefarious action it would get logged by the SU management application. The malicious application would instead whitelist a module within itself to do its work.
Here’s where the hack would get complex and require a bit of sorting on the user’s end to even figure out what would happen. Once they’ve given the malicious access once, and it only has to be once, a module within the application is whitelisted within the Xposed Framework. At this point things could become very bad. If the malicious application wanted to access root from this point forward it could operate at root level with impunity. The module for the application would just auto authorize itself whenever root was needed (using the framework to hook into the SU application running).
The malicious application could go further. If after placing a whitelisted module in the framework the application’s module could hook into the framework’s methods to disable whitelist checking. Other modules at this point could automatically gain access to the framework without having to go through any user intervention. This could be done several ways. If the application downloaded separate files for the module the issue could persist even after the original application was uninstalled. Imagine the damage that has now happened! There is unauthorized code running at elevated privileges tied to no user application! It could do anything it wanted! It’s essentially a rootkit at this point!
So It’s A Framework That Can Be Used Maliciously
Can’t any of the elevated permissions that have been talked about be used that way?
Yes, of course they can! That’s why out of the box manufacturers do not give the users of their hardware root access!
Hands down this is a very innovative solution to a problem with applications such as Google Wallet. Instead of a developer ripping apart an apk, modifying the SMALI, and then repackaging it they would just hook into the various methods which needed to be modified and then either modify the parameters sent to the method or the value returned by it. It goes without saying that with great power comes great responsibility to the user. Either using SU managed access to the system or the Xposed Framwork will carry risks.
I didn’t spend too much time digging deep into the uses of the framework. I found out about it when I was trying to find the latest patched Google Wallet so I could run it on my Verizon Galaxy S3. It turns out that the developer has decided to use the Xposed Framework to modify the methods instead of producing a modified apk. As I mentioned I find this to be a very cool solution to a problem faced by developers. The framework is open sourced so anyone can verify that nothing bad is going on.
I have just decided that I will not be running this on my phone. I do too many things in the scenario that I’ve outlined where I could potentially be a victim. I accept the risks with giving applications root access, but I occasionally check the logs to see what the applications are doing and I rarely give unlimited access to an application unless I am very sure of its operation. I just don’t feel that the Xposed Framework offers as much control over installed modules.
Do you run the Xposed Framework on your phone. I see some ROM devs are incorporating it into their ROMs by default. Let me know what you think?