Xposed Framework – Proposed Solution

After my post on Google Wallet and the Xposed Framework I’ve done some thinking to see if there was some sort of solution to the security issue that is inherent in the Xposed Framework. It hit me. The answer is kind of obvious.

My big gripe with the Xposed Framework is that it operates with impunity. Once a module is added to the white list, either through user interaction or a malicious action, there are no more checks done to insure that the functionality which is being altered is acceptable to the user.

With standard root access there is a barrier that apps must cross. In most cases it is the Superuser app. Superuser acts as a gatekeeper to the elevated privileges that are granted with root access. Superuser keeps a list of applications which are allowed root privileges and logs their use this privilege  The reason I have more faith in this access method is because I get a toast message whenever an app access root and this access is logged. In the current versions of Superuser included in CyanogenMod 10.1 and ParanoidAndriod 3.15 a time period can be granted to the application requesting root. A user can select a one time, 10 minute, or indefinite access for root privileges.

Proposed Solution

My solution to the security issues in the Xposed Framework is to apply the same principles included in the Superuser gatekeeper for root privileges. Some of these may be implemented in the current framework, but I am outlining what I think would be an acceptable solution with the Xposed Framework What I would like to see is thus:

• A check should be implemented that no method in the Xposed Framework should be allowed to be overridden by a module. Priority number one is the integrity of the framework.
• Each module should contain a manifest of what it alters. The module interface should define fields that a developer should display to the users such as title and description. The manifest should work like the permissions included with all Android apks. Permissions in the manifest will dictate what the module is allowed to modify. Access_SystemApks, Access_UserApks, etc.
• A protected log of access should be created.  The log should indicate when a module was added and when and what the module overrode. I say protected because the only writes to the log should be performed through the framework.
• Configurable toast messages indicating what the framework is doing. This should be similar to the toast message “[APPNAME] requested Superuser permissions” that is shown whenever an app requests root privileges. The toast messages should be configurable by module so that a user can hide messages for a module he or she believes is safe.
• A timeframe when module access to protected calls takes place. This should function the same as I have described the Superuser access above. When the framework goes to execute a module’s override it should defer first to a screen that asks the same questions as the Superuser app. If the user selects the option to never be prompted again then the screen is not shown again for that module. If the user selects a 10 minute window then the module should operate without showing the screen for the next 10 minutes. If the user selects the “only this time” option then the current action will execute and for any other override the user will be prompted again.

I think all of these points could be implemented without a ton of effort. The second point would take the most effort, but I do not think it is overly burdensome. The project is on GitHub. If I come across some free time I may try to take a look at what it would take to implement some of these suggestions.

Hopefully this article brings up some discussion on the topic!