Android multiuser model architecture and related security threats

I have recently bumped into a very interesting research article called “A Systematic Security Evaluation of Android’s
Multi-User Framework” and want to leave here a digest and some of my analysis in the aspect of Enterprise use. I recommend reading the paper for more details, it’s only 10 pages. The more I learn of Android, the more it reminds me of a cheese grater (other OSes are no better). This doesn’t include any of Android L enhancements, as those are not officially released yet.

Overview of Android Multi-User model.

The Multi-User feature was officially introduced in Android 4.2 (and only in tablets). However, I found some bits of it already implemented “under the bonnet” in 4.1.

A quick reminder of how user-facing part of multi-user looks like:

• There’s one ‘main’ user of the device called ‘the owner’ that can do everything (as in typical single-user model)
• This user can create/edit/remove additional user profiles
  • These profiles can be unrestricted or restricted
  • Restricted profiles will only be able to run the allowed apps and access the allowed settings (settings control is not very granular, though)
  • The data is separated between users – multiple users using the same app will not see each other’s data
  • Some of the OS settings are separated, and some of the settings are shared (those belonging to Settings.Global)
• Only one user can be active at a time, but up to 3 other accounts can have their processes running in the background at the same time. The main idea was sync (emails, FB, etc), but wait until you see how much exploit potential this leaves 🙂

How it’s made in the OS

On the OS level, the following changes are implemented:

• In addition to per-app user IDs (used forsandboxing), per-user user ID are introduced. Let’s call themappID anduserID respectively. TheuserIDs are defined as follows:
  • 00 – device owner
  • -1 – all users
  • -2 – current user
  • -3 – current user or self
  • -10000 – null user
  • <nn> – userID of any ‘secondary’ user, starts with 10 (i.e. 2nd user on the device will have userID 10, 3rd user – 11, etc)
  • List of users is stored in /data/system/users/userlist.xml
• By concatenating theuserID withappID we get the standard UnixUID, which allowssandboxing to continue to function, and elegantly allows separating memory, processes and storage for the same app when ran by different users. Ex:
  • Two device users, owner and 2nd user, run the same app with appID 12345. The resulting process UID will be 0012345 for owner and 1012345 for the 2nd user. Thus, the apps will have their own independent private memory and process space, as well as private files and folders.
  • Note that because device owner userID is 00, it is very easy to revert to single-user model at any time – nothing changes for the ‘owner’ user.
• Each installed app get’s it’s own data directory (in /data/user/<userID>/<pkgname>/ instead of usual /data/data/<pkgname>), however the app code is not isolated – the APKs are shared and still located in /data/app.
• Some additional permissions were implemented to allow controller interaction across user accounts.

As you can see, the entire solution is quite elegant and lean – all it took “under the bonnet” was prepending double-digit userID to an appID and creating a few additional folders/files to store app data. The rest is more or less transparent. However, this lean approach opened new potential attack paths.

Threats

1. Bypassing secondary user app/settings restrictions

Secondary users may be restricted from accessing some apps or parts of the OS, such as certain settings, etc. But the researchers found out, that there are no extra safeguards for this.

The apps are hidden by simply listing them in a specific XML file, which hides the app icon from the user 🙂 The OS restrictions are not much better. For example, the settings restrictions are handled by the Settings app itself – it simply hides certain menu items! However, they found a way to bypass some of these restrictions by directly calling the specific settings screens, such as VPN settings, Mobile data settings, backup & reset, etc. Some of these elements actually contained additional logic that prevented exploitation, but it’s important to stress, that there is no unified framework mechanism to support this – pretty much every app and OS component must implement extra code to support user separation.

Another aspect is that some settings cannot be hidden from user altogether, such as Wi-Fi settings. This means that, for example, secondary restricted user can reconfigure Wi-Fi on the device to work via another malicious AP and intercept all the data.

2. Exploiting background tasks.

Since some apps may run in the background even when another user is active, it is important to understand, what can those apps do. Turned out, while running in the back, the apps can do pretty much everything: from tracking your location to recording audio and video w/o the current user even realizing that. Furthermore, even if you do realize that, because the other app runs outside of your security context, the only way to stop it is to turn the device off. 😦

3. Exploiting shared app code.

As mentioned before, application APKs are shared between all users. This means that if more than one user has rights to install or update applications – various cross-border exploits are possible.

• Secondary user may update the app to a version that contains known vulnerabilities or ‘features’ unknown to the main user. Even if app requires more permissions (record calls) – those permissions can be approved by the secondary user, and the device owner will never know about it.
• Since Android does not really check app identity when installing the apps (read this blog, it’s awesome), there is a potential for a DoS attack. For example, to prevent a specific package from being installed on the system, one can create the app with the same package name and install it. Subsequent updates will fail due to certificate mismatch. Good to prevent installing any security software.
• Finally, Android allows apps from the same developer to be installed into the same sandbox and, effectively, share permissions. This mechanism was never updated for multi-user. Thus, restricted user may find and install the app that will enjoy all the privileges of the device owner.

Conclusion

The current Android multi-user model seems to be designed with simplicity and ease of implementation in mind. But not with security. Some of the lists risks are minimal if the device is used as the ‘family couch tablet’, but may pose more serious threat in the Enterprise environment, for example.

It is not uncommon in the Enterprise space to have multi-job devices, and logic of creating multiple accounts (“Admin”, “Stock Check”, “Shipping”, “POS”) for each job seems very rational and tempting. However, it’s only a matter of time for someone to exploit this, and even w/o exploitation the secondary users will have enough means to disrupt the workflow (willingly or unwillingly). Spying on device admins or store managers is a totally different level of the game…

The key considerations for mitigation would be

1. Do not allow anyone but the device admin to install the applications. This can be done with native Android means, provided you hide all possible app installation sources and remember to disable ADB as well.
2. Use application whitelisting that actually doesn’t allow apps to run – not just hides shortcuts from the UI. This is not 100% possible in vanilla Android, but various ‘enterprise’ builds such as Motorola’s MX can do it. So can 3rd party tools, but some of them may require rooting.
3. Ensure you have some sort of business continuity in place. Business data on the mobile device should never be unique – should be synced to some sort of back-end at all times. When the device compromise is detected, there must be a quick way to wipe/redeploy it (after the analysis is done), instead of having to spend hours extracting important business data that does not exist elsewhere.
4. Do not allow anyone to install apps and see any of the OS settings. This is so important, I’d like to stress it again.

It should also be noted, that upcoming Android L may bring something completely new to the table, but let’s wait and see…