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?
Very interesting read highlighting potential exploits in a tool that is becoming more and more popular in the android community. What I found most interesting, however, is that no one has commented on your post with relevant feedback.
This post is one of my more popular in regards to views. I agree with you that I don’t understand why this topic hasn’t generated a larger conversation. I know the topic is a bit alarmist and to many people may seem like the ranting of a paranoid person.
The Xposed framework is a really interesting solution. I just think that as much security focus the Android platform receives in general makes this topic highly relevant. Why shouldn’t you be concerned with unfettered access to your device? Why even have SuperSU if this topic doesn’t hold weight? It just seems that there should be some sort of discussion to keep us on our toes regarding these tools and what they do.
Erm, where exactly is the problem with the framework now? Once an app has been granted root, it can do whatever it wants even without this framework – may be a little more complex to do, but it’s possible.
Agreed. In my response to James I concede this fact. Once an app has elevated privileges it could modify the SU management application to not notify the user of it’s use of elevated access.
I am not surely I understand author’s view on this one.
I see a “possible” way to use it maliciously buy it’s nearly the same with SU.
Author complains that rooting+installing xposed framework(+su permission)+installing module+giving permission to a module is less secure than just rooting and running superuser popup (which in most cases likely is set to remember setting to always allow root access).
I believe this is rather more secure but as everything requires user to think what he’s doing. The same comes with any Android app, requiring just root or a normal one requiring access to eg. your contacts
Thanks for the comments guys. Let me elaborate a little on where I’m coming from and highlight a few things in the article. I am just getting into this blog writing thing and sometimes what I have in my head doesn’t quite make it to the page how I imagine it.
I think everyone can agree that giving any application privileges beyond userspace runs some amount of risk. Unless you get the source and compile the app (with your own compiler because you may have a compromised one) you can never be 100% sure that what you’re giving permissions to is completely safe. Oh, and let’s not forget that once you have the source you need to be able to read it and understand it so you can identify security issues!
The idea is that we’ve mitigated some of the risk with elevated privileges with SU and similar types of applications. In the example of SU we have an application that sits between root actions and the user. We get notified. When the notification screen comes up it does not default to always allow access from that point forward (at least in the CM10.1 baked in version it does not). I find the similarities between the *nix “sudo” command and this operation very similar and acceptable. The commands are logged (if something seems screw-y then I can go and look at what’s been requesting root; also there are toast messages which I can admit can be a bit annoying sometimes).
With the Xposed framework, and this article and my review of the code are now getting a bit dated so please understand if things have changed in a recent version, there does not seem to be any catch mechanism beyond the whitelisting of modules.
To address the chain of events that James points out, once the framework is installed any app that asks for root can modify the whitelist and then run with no further notifications. I could start off installing the Xposed framework to use the Google Wallet module (why I looked into this in the first place). If for some reason I found a file manager app that billed itself as better than Root Explorer and decided to try it out then something malicious could happen when it asked for root and I’d be none the wiser for the rest of the time the framework was installed and running on my phone. Contrast that with how I described the SU functionality above. Once a module is whitelisted it can operate with no checks, no log, no user knowledge.
I concede 100% that running anything with elevated privileges is a risk. There is probably an outline for how something like this could modify a given SU manager so that the same scenario could be played out without the need for the Xposed Framework.
Please understand that have the utmost respect for the solution that the Xposed Framework provides. I think it is an awesome idea and after seeing more and more modules released for it I am swaying to the side of installing it. I really hate to put out a cliche but as it has been quoted many times before, “with great power comes great responsibility.” I guess what I would like to see some manner of logging or similar functionality to SU within the framework. I think it would go a long way to making paranoid folks like me feel a little less sketch over running it on our daily drivers.
Very interesting post which points out the limit of the confidence we can give to Android apps.
I came here because I was looking about XPrivacy, an XPosed app which can restrict other apps from accessing to private resources such as contacts from unwanted leaking for instance.
This app is really amazing because it fools the asking app with fake data.
In fact, the problem is to know where to put the cursor between “Don’t do any modification on your phone and use only official market apps” and “Root your phone or flash a non-stock ROM and install any apk from any source”.
The problem is that in the first case, which is implicitly chosen by most of the users, you accept easily using registrered apps and all their permissions without having the ability to choose which ones you want to grant and which you don’t.
And even in this case, you could install an insane app which will access to your phone resources (contacts, send SMS, issue taxed phone calls, …).
I think that the solution is in including in the OS the choice for wised and expert users to grant or not the permission.
But this will certainly imply OS and apps redesign in their way of communicating together.
It will imply also users’ responsibility. But are they ready for that ?
I’ve also been interested in the security implications of Xposed Framework. Thanks for the writeup. The risks are real. I don’t understand the attitude of the other posters here. It seems like they just didn’t really understand what you wrote and are just blindly defending Xposed.
I’ve been testing the Android waters after years on iOS. A famous iOS developer, Saurik, recently released a similar framework. I respect his work. He had some thoughts on Xposed as well. Have a read.
Thanks for the link!
Arguments can be made either way with Xposed. As a software developer I look at what it is doing and marvel at the inginuity that it took to put together the framework. It’s actually quite impressive how reflection is used to hook into methods. When I was reading over the code for the first time I was more wondering what the performance implications of all that reflection would be visible by the end user. When I look at it as a security concious user I see it differently. I could reiterate my earlier speaches about how to improve the framework but I feel like I made that point. I think everyone should just know the risks that they are taking when they step out of the security bubble that is provided to them. I think this XKCD comment sums up most security ideas.