April 30, 2013
SE Android prevents first exploit against commercial phone
That should have been the title of this post, but alas it is not.
By now you may know that the Samsung Galaxy S4 is the first commercial device shipped with SE Android included.
Included, but not enforcing. If you are familiar with SELinux you know that there is a developer mode (also called permissive) that audits access that would have been denied, but does not actually deny them. This is very useful for developing your policies without having to interate through accesses one at a time (this takes a very very long time with complex software).
The standard way of writing policy is to use permissive mode to run an application, then look at the logs and figure out what the access patterns are, what should be labeled what, write the policy, then try again. Eventually you go into enforcing mode when you are ready to send your product to production.
That is the theory, anyway.
History lesson
Back in the Fedora 2 days (that is 2004) SELinux shipped in enforcing, with a strict policy. It was a catastrophy. Linux users who were accustumed to cat'ing /dev/cdrom, for whatever reason, became angry that they couldn't do it all of a sudden. The targeted policy was then created which would resrtict only high-threat applications, like apache and ssh. Most recently Dan Walsh, over at Red Hat, introduces new application policies to the masses in permissive mode (note, SELinux supports permissive mode per-type, not just system wide) and collects denials from users for a few months, to figure out how people use the applications, since he can't be an expert at every single one. He then switches the policy to enforcing when the policy has been fleshed out.
Lost Opportunity
This is the first commercial phone with SE Android; there is a huge amount of risk to going into the wild in enforcing. I don't know if they were nervous that something like Fedora 2 would happen or it was carrier certification delays or perhaps they just don't think SE Android should be on unless explicitely requested. No matter what the reason, a huge opportunity to show the world the power of SE Android was lost. No worries, though, there will be another opportunity.
The Exploit
Ok, lets look at this exploit and see what would have happened. I don't happen to have a Galaxy S4 in front of me, but the stock recovery image has everything I need to look at this.
First, the exploit is motochopper and was originally written for a Motorola. The reason it works on the S4 is that the phones have similar chipsets. The chipset vendors provide kernel patches, drivers, userspace components, etc to the OEM's. The OEM's then integrate that into their version of Android, normally what Google gives them + their extras. In this case the vulnerability was in the code provided by the chipset, it had a world writable fb0 device node, that allowed an mmap() of kernel memory.
Without a phone in front of me, how on earth could I know that the exploit wouldn't have worked, you ask?
Edit: The above isn't quiet accurate. The vulnerability was a bug in the mainline framebuffer rather than in a specific chipset, which means it may affect even more devices.
The Policy
On the recovery ROM are 2 files that I can use to mount this investigation. I know the exploit mmap()'s /dev/graphics/fb0 so first I want to know what that would be labeled:
$ grep /dev/graphics file_contexts
/dev/graphics(/.*)? u:object_r:graphics_device:s0
So, /dev/graphics/fb0 (and indeed everything under the graphics directory) would be labeled graphics_device.
On SE Android the type you get when you use adb shell is shell. So, next I need to look for accesses between shell and graphics_device:
$ sesearch --all -s shell -t graphics_device sepolicy
Found 7 semantic av rules:
allow appdomain dev_type : file getattr ;
allow appdomain dev_type : dir { ioctl read getattr search open } ;
allow appdomain dev_type : lnk_file { read getattr } ;
allow appdomain dev_type : chr_file getattr ;
allow appdomain dev_type : blk_file getattr ;
allow appdomain dev_type : sock_file getattr ;
allow appdomain dev_type : fifo_file getattr ;
Indeed there is no write permission so the mmap attempt to write to kernel memory would fail. This only covers the adb shell case though, and that is typically done by the owner of the device. Granted that this makes problems for BYOD but the more interesting question is, could malicious apps exploit this?
In the seapp_contexts file it shows that third party apps will be labeled untrusted_app, so lets look at that:
$ sesearch --all -s untrusted_app -t graphics_device sepolicy
Found 7 semantic av rules:
allow appdomain dev_type : file getattr ;
allow appdomain dev_type : dir { ioctl read getattr search open } ;
allow appdomain dev_type : lnk_file { read getattr } ;
allow appdomain dev_type : chr_file getattr ;
allow appdomain dev_type : blk_file getattr ;
allow appdomain dev_type : sock_file getattr ;
allow appdomain dev_type : fifo_file getattr ;
Again, no dice. Apps can stat() the file but not read or write it. The same goes for the browser (browser_app) and even platform_app, which includes all of the apps included on the device from Samsung and Google.
But which types can write to the file? Good question, SE Android may be blocking all of this access but we know the vulnerability is there, we should find out what on the system is able to exploit it:
$ sesearch -t graphics_device --allow -c chr_file -p write sepolicy
Found 7 semantic av rules:
allow system graphics_device : chr_file { ioctl read write getattr lock append open } ;
allow system_app graphics_device : chr_file { ioctl read write getattr lock append open } ;
allow mediaserver graphics_device : chr_file { ioctl read write getattr lock append open } ;
allow unconfineddomain dev_type : chr_file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint execmod open audit_access } ;
allow mm-pp-daemon graphics_device : chr_file { ioctl read write getattr lock append open } ;
allow surfaceflinger graphics_device : chr_file { ioctl read write getattr lock append open } ;
allow bintvoutservice graphics_device : chr_file { ioctl read write getattr lock append open } ;
Well, system and system_app, which are pretty powerful either way, granted it is an escalation if you can compromise them. unconfineddomain (hrm.. whats that?), the seapp_contexts file doesn't have any entries for it, so presumably it is there for MDM/MAM vendors to run unconfined apps if they choose to. surfaceflinger obviously needs to be able to write to the graphics device, and possibly mediaserver. bintvoutservice probably does too, and I don't know what mm-pp-domain is, probably a Qualcomm specific thing.
So, there are definitely vectors to get at this, but they involve compromising protected apps (in a real security analysis we'd keep backtracking to see what vectors there are to attack system and system_app, for example) but this exploit wouldn't have been pulled off nearly as easily as it was, if SE Android were enforcing.
Conclusion
Exploits like this are scary, not because of owners that want to root their phones but because, if an owner can do it, it is highly likely that an adversary can. These mobile devices are our lives, they have business data on them, they have private data, and they can be used to steal your money in various ways (such as premium SMS's). There will not be a shortage of vulnerabilities until OEM's and users alike start thinking from a security mindset. The tools are there, no OEM has an excuse not to use them.
It may not be a bad idea to set SE Android into enforcing once you've rooted your phone, so that malicious apps don't take advantage of the same vulnerability, if I get my hands on a GS4 I'll blog about doing that.
April 12, 2013
As a follow-up to my last blog post, I just came across this article: Mobile malware gets serious RATs can bypass sandboxes and encryption
1 in 1000 devices, the tools are in the wild. There is no reason to believe this number will go down. Further, these mRAT's apparently know how to bypass MDM and MAM sandboxes and encryption.
of course, mRAT's aren't anything new, but this is the first I've heard about ones that specifically target/bypass MDM/MAM.
Worse, the tools aren't just being used by experts; hackforums.net has tutorials on using them with commands like 'Hit Start then run, type "CMD" without quotations, hit OK, type "IPCONFIG" without quotations, etc'.
The solution is integrating SE Android into your devices; but SE Android, like SELinux is no silver bullet. You need good policies. Mobile device manufacturers are notoriously bad at securing their devices. The fact that a device node directly exposing kernel memory was world readable/writeable on many Samsung devices is direct evidence of this. The same people writing that software could not possibly be trusted to write secure SELinux policies. Separate teams that do security analysis and testing must ensure the policies are reasonable, etc.
This isn't rocket science, but it isn't standard operating procedure either. We've been doing independent verification and validation (IV&V) in government spaces forever. This needs to happen in mobile and there need to be security mechanisms that don't rely on discretionary access controls in place, which, of course, means mandatory access controls, which SE Android offers.
April 11, 2013
Mobile Application Management (MAM)
Mobile Device Management (MDM) was all the hotness just a few years ago. It gave IT departments the ability to manage both corporate owned devices and devices owned by employees (BYOD) but it was dissatisfying. As BYOD became more prevalent and corporate owned devices less it made users feel like they were giving up all control of their device to their employer, mainly because they were. Most users at this point probably know the feeling of adding their corporate credentials into their phone and seeing the dreaded 'you are giving administrators the ability to wipe your phone, install apps, remove apps, and locate your phone' screen.
Then there was the issue of having multiple administrators that wanted to do different things with your device.
Even for the administrators, the solution was incomplete. It did not give them the ability to manage app configuration, app storage, app authentication, etc.
That is where MAM comes in. For the administrators it means they can package apps with configuration, version it, push it out and wipe only corporate app data when an employee leaves. The nicer systems add single sign-on so that a user can authenticate once and get access to all corporate apps. They also store corporate data encrypted and can report usage statistics back to corporate IT. For users it means that they don't have to give up full control of their device.
Sounds great, right?
How does it work?
Well, mobile devices don't typically have this kind of granular control built in. Further, off-the-shelf applications generally don't come configured or support single sign-on. The solution that MDM vendors started peddling is called app wrapping. Basically it means that the IT department takes the apps they want to manage (whether they are internally developed or 3rd party) and runs a tool from the MAM vendor that packages the app within another app, the wrapper (or the castle).
The outside package interacts with the real device, including storing data to disk encrypted, verifying credentials with corporate authentication servers, etc. The fancier ones even prevent apps from running outside of specific physical locations (geofencing), and will attempt to detect a rooted device (though that is impossible in practice).
So, this still sounds great. From a functionality point of view this is a superior experience for both the user and IT, so what is the problem?
Userspace containerization (or building castles)
Lets start with the obvious one first. The inside (wrapped) app is modified to not be able to interact with the real device, but to interact with the wrapper instead. Two standard ways this is done is by providing an SDK that corporate apps can be written with and the other is called app wrapping. It should be noted that while using the SDK is the safer option, it will likely lock you in to a single MAM vendor.
App wrapping on Android involves modifying the Dalvik bytecode ahead of time to add all of the functional additions as well as changing functions that would normally interact directly with the system (think filesystem operations, intents, binder calls, etc) to use analogous calls in the wrapper instead. The effect here is that the wrapper can 1) ensure filesystem writes only go to allowed locations and are encrypted and 2) to prevent IPC with apps outside of the "container".
Well, that is the thought, anyway.
No one in their right mind would believe that they can write a libc wrapper that intercepts open() calls to make security decisions and think that it buys them anything, but that is fundamentally what is happening here. App wrappers cannot contain numerous, supported features on Android such as jni to native libraries and java reflection. A particularly crafty app might even have a scripting language interpreter or its own java class loader that would be nearly impossible for the wrapper to understand and secure.
There is no chance that an MAM implementation could keep an app that wanted to exfiltrate corporate data from doing so. That is an easy problem to solve though, you only wrap trusted apps, because they are either corporate or known 3rd party apps, right? Well, hopefully, for your sake, those apps don't have vulnerabilities that a spear phisher can take advantage of to gain access to corporate data (spoiler: they do).
In the scheme of things this is a relatively low threat, though, so lets move onto the real issue.
The insecure platform (or the sand)
People have tried building secure on top of insecure as long as personal computers have been around. The appeal is that there is always an insecure platform, be it Windows, Linux, iOS, or Android and there is always a need to access secure data is always there.
I'll take this opportunity to suggest that, if you haven't already, you should read:
The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments
The fact is that if the system below your application isn't secure no amount of anything will make your application (or wrapper) secure. Detecting rooted devices is not enough. Most detection is heuristic, such as checking for the existence of /system/xbin/su. Suppose the device is not rooted by the user such that su exists but by an adversary? Root access gained for the intention of stealing corporate data would not likely be detected by an MAM solution and therefore malicious applications running on the device would be able to affect the corporate apps in various ways, from communicating with them, bypassing the wrapper, all the way to scanning their memory and extracting corporate data.
Most snake oil vendors will claim encryption solves this problem. Encryption may be a suitable solution to data-at-rest, data not currently being accessed that is sitting on disk, but when your corporate email app is running the emails are in memory, not encrypted. Even if an industrious app writer did extra work to keep them encrypted in memory the decryption key must also be in memory, and is vulnerable.
So, this is the real threat. If your app has data I want and it runs on a standard Android or iOS phone, I'll be able to get it, no matter what your MAM vendor is telling you.
As a non-security related aside, you probably don't have permission to download 3rd party apps from the app store and wrap them, which would constitute unlicensed distribution, you'd have to get permission from the app owner. An interesting ramification of this is that GPL apps can't be legally wrapped since the GPL license of the app would have to apply to the wrapper as well.
The solution
Just like in standard computing the solution isn't hard, but is rarely used.
You must have a secure host platform if you want your applications to be secure. Unfortunately not many options exist for this but fortunately there are options that are freely available. The one that I favor is, of course, SELinux. I've been involved in building SELinux systems to secure even the most important data for nearly a decade now and it has proven true.
Anecdotally, I have security researcher friends who work on the offensive side of the fence that have told me when they encounter an SELinux machine they bail and look for an easier target. It is important to note that we aren't talking about out-of-the-box Fedora installs, though, but systems intentionally and knowingly hardened against this type of adversary.
Which brings us back to Android. The Security Enhanced Android (SE Android) project has been picking up more and more steam. Much of it is already merged into AOSP which allows all Android vendors to use it and recently Samsung has announced a device that will have it included by default. This is definitely a step in the right direction but a far cry from what it will take to feel confident allowing important corporate data to be accessed on non-corporate owned devices.
With a secure platform you can enjoy the functionality benefits of an MAM solution and be confident that security provided by the platform will keep their castles secure, both from the inside and the outside.
Unfortunately, none of this is a solution you can use today. Technology must, as usual, catch up to market demands. The demand must be there, though. Demand secure platforms. There is no excuse for Android vendors to not include SE Android in future offerings, all the hard work has already been done by early adopters.
Update:
My next entry has validation for this post, seen in the wild.
Older posts... (see archive for more)