One of the strongest points of Android has primarily been its open source nature, which allows for stakeholders to fork, modify and redistribute the OS in a way that suits their particular needs. But this very advantage of being open source acts like a double-edged sword when it comes to the issues of malware and security. It is easier to find and patch flaws when you have a lot of able contributors on a project whose source code is available freely. However, fixing the issue at the source level does not often translate into the problem being fixed in the hands of the final consumer. As such, Android is not the premier choice when it comes to choosing an OS for data-sensitive enterprise needs.
At Google I/O 2014, Google gave its first push towards a more secure and enterprise-friendly ecosystem with the launch of the Android For Work program. Android For Work adopted a twin profile approach for enterprise needs, whereby IT administrators could create a distinct user profiles for employees – one focused on work, leaving other profiles for the employees’ personal use. Through the use of hardware-based encryption and admin-managed policies, work and personal data remained distinct and safe. Subsequently, Android For Work received more attention in the later months, with a large focus being on the security of the device against malware. Google also planned to enable full device encryption for all devices that were to be released with Android Lollipop out of the box, but this was scrapped due to performance issues with the move being made optional for OEMs to implement.
The push for a secure Android is not entirely Google’s work, as Samsung has played a rather significant role in this via its KNOX contributions to AOSP, which ultimately strengthened Android For Work. However, recent security exploits and vulnerabilities in Android point to an uphill task when it comes to popularity for enterprise adoption. Case in point is the recent Stagefright vulnerability.
In simple terms, Stagefright is an exploit which utilizes the code library for media playback in Android called libstagefright. The libstagefright engine is used to execute code which is received in the form of a malicious video via MMS, thus requiring only the mobile number of the victim to carry out a successful attack.
We reached out to our in-house expert, XDA Senior Recognized Developer, and Developer Admin pulser_g2 to provide a more detailed explanation.
“As I write this, the [Stagefright] exploit was due to be explained at BlackHat [Link], although there are no slides or white paper details available yet.
I’m therefore giving this explanation more as a rough idea of what’s going on, rather than as a heavily in-depth explanation with full accuracy etc.
Unfortunately the patches which are available are not linked directly to each CVE (as they should be), so this will be a bit messy to explain.
In the MPEG4 handling code, the 3GPP metadata (the stuff that describes the format and other extra info, when a video is in 3GPP format) handling code is buggy. It didn’t reject metadata, where the data was excessively large, rather only checking if it was too small. This meant it was possible for an attacker to craft a “modified” or “corrupted” file, which would have a longer metadata portion than it should.
One of the big challenges in writing code to handle “untrusted” data (i.e. from a user or from any other kind of place external to your code) is handling variable-length data. Videos are a perfect example of this. The software needs to allocate memory dynamically, depending on what’s going on.
In this case, a buffer is created as a pointer to some memory, but the length of the array it points to was one element too short. The metadata was then read into this array, and it was possible to have the last entry in this array not be “null” (or zero). It’s important the last item in the array is zero, since that’s how the software tells the array is finished. By being able to make the last value non-zero (since the array was potentially one element too small), the malicious code could be read by another part of code, and read in too much data. Rather than stop at the end of this value, it could keep on reading into other data it shouldn’t read.
The shortest possible “size” of the metadata should be 6 bytes, on account of it being a UTF-16 string. The code takes the integer value size, and subtracts 6 from it. If this value was less than 6, the subtraction would “underflow” and wrap around, and we’d end up with a very large number. Imagine if you can only count from 0 to 65535, for example. If you take the number 4, and subtract 6, you can’t go below zero. So you go back to 65535 and count from there. That’s what’s happening here!
If a length of under 6 was received, it could lead to frames being incorrectly decoded, since the byteswap process uses the variable len16, whose value is obtained from a calculation beginning with (size-6). This could cause a much bigger swap operation to happen than intended, which would change values in the frame data in an unexpected way.
A biggie! This one is nasty. There’s the exact opposite of this last issue – an integer overflow, where an integer can get “too big”. If you reach 65535 (for example) and can’t count any higher, you would roll around, and go to 0 next!
If you are allocating memory based on this (which is what Stagefright is doing!), you would end up with far too little memory allocated in the array. When data was put into this, it would potentially overwrite unrelated data with data the malicious file creator controlled.
Another nasty one! Very similar to the last one – another integer overflow, where an array (used as a buffer) would be made too small. This would allow unrelated memory to be overwritten, which is again bad. Someone who can write data into memory can corrupt other data that’s unrelated, and potentially use this to have some code they control be run by your phone.
Quite similar to these last ones. A variable is used when skipping over some memory, and this could be made negative during a subtraction (like above). This would result in a very large “skip” length, overflowing a buffer, giving access to memory that shouldn’t be accessed.
This adds checks to stop issues with a past security fix to add bounds checks, which can itself be overflowed. In C, numbers that can be represented as a signed int are stored as a signed int. Otherwise they remain unchanged during operations. In these checks, some integers could have been made signed (rather than unsigned), which would reduce their maximum value later on, and allow for an overflow to take place.
Some more integer underflows (where numbers are too low, and then subtraction is carried out on those numbers, allowing them to go negative). This again leads to a large number, rather than a small one, and that causes the same issues as above.
As per the blog post published by the parent researching company, Zimperium Research Labs, the Stagefright exploit potentially exposes 95% of Android devices – roughly 950 Million – to this vulnerability as it affects devices running Android 2.2 and up. To make matters worse, devices prior to Jelly Bean 4.3 are at the “worst risk” as these do not contain adequate mitigations against this exploit.
With regards the damage that Stagefright could deal, pulser_g2 remarked:
"“In itself, Stagefright would give access to the system user on the phone. You’d have to bypass ASLR (address space layout randomization) to actually abuse it though. Whether or not this has been achieved is unknown right now. This exploit lets “arbitrary code” be run on your device as the system or media user. Those have access to the audio and camera on the device, and the system user is a great place to launch a root exploit from. Remember all the amazing root exploits you used to root your phone?
Those could potentially be silently used to gain root on your device! He who has root owns the phone. They’d have to bypass SELinux, but TowelRoot managed that, and PingPong has managed too. Once they get root, everything on your phone is open to them. Messages, keys, etc.”"
Talking about worst case scenarios, only an MMS is needed to deliver code and trigger this exploit. The user does not even need to open the message as a lot of messaging apps pre-process MMS before the user interacts with it. This is different from spear-phishing attacks as the user could be completely oblivious to a successful attack, compromising all present and future data in the phone.
What makes Stagefright different from other “massive vulnerabilities”?
"“All vulnerabilities pose some risk to users. This one is particularly risky, since if someone finds a way to attack it remotely (which is possible, if a way around ASLR was found), it could be triggered before you even realise you’re under attack”"
Older exploits like Android Installer Hijacking, FakeID as well as root exploits like TowelRoot and PingPong require user interaction at some point in order to be executed. While they are still “exploits” in the fact that a lot of harm can originate if used maliciously, the fact remains that Stagefright theoretically needs only a victim’s mobile number to turn their phone into a trojan and hence is being given so much attention in recent days.
Android isn’t entirely at the mercy of this exploit, though. Lead Engineer of Android Security, Adrian Ludwig addressed some concerns in a Google+ post:
"“There’s common, mistaken assumption that any software bug can be turned into a security exploit. In fact, most bugs aren’t exploitable and there are many things Android has done to improve those odds…
A list of some of those technologies that have been introduced since Ice Cream Sandwich (Android 4.0) are listed here. The most well-known of these is called Address Space Layout Randomization (ASLR), which was fully completed in Android 4.1 with support for PIE (Position Independent Executables) and is now on over 85% of Android devices. This technology makes it more difficult for an attacker to guess the location of code, which is required for them to build a successful exploit…
We didn’t stop with ASLR, we’ve also added NX, FortifySource, Read-Only-Relocations, Stack Canaries, and more.”"
However, there is still no denying that Stagefright is a serious matter for the future of Android, and as such is being taken seriously by the stakeholders involved. Stagefright also highlighted the white elephants in the room – the problem of fragmentation and of updates finally reaching the consumer.
The Update Dilemma
Speaking of updates, it is good to see that OEM’s are taking responsibility of users security, as many have promised to improve upon the update process specifically for incorporating security fixes and patches for exploits like Stagefright.
Amongst the first to release an official statement, Google has promised monthly security updates (in addition to the planned OS and platform updates) for most of its Nexus devices, including the almost 3-year-old Nexus 4. Samsung has also followed suit by announcing that it will work with carriers and partners to implement a monthly security update program but it failed to specify the devices and timeline details of this implementation. This is interesting as it mentions a “fast track” approach to security updates in collaboration with carriers, so we can expect more frequent updates (albeit security based, but hopefully it’ll accelerate firmware upgrades as well) on carrier devices.
For once, carriers are also forthcoming with updates. Sprint has issued a statement that some devices have already received the Stagefright patch, with more devices scheduled for the update. AT&T has also followed suit by issuing the patch to some devices. Verizon has also issued patches, albeit this is a slow rollout that prioritizes high-end smartphones like the Galaxy S6 Edge and Note 4. The T-Mobile Note 4 received a Stagefright patch update as well.
As an end-user, there are a few precautionary steps that can be taken to lessen your chances of getting attacked. For starters, disable auto retrieval of MMS messages in the messaging apps present on your phone. This should keep in control the cases where no user interaction was required for the exploit to work. After this, do take care to avoid downloading media from MMS messages from unknown and untrusted sources.
As an XDA power user, you can also make edits on your build prop to disable Stagefright. There are also custom ROM solutions, most of which sync sources with AOSP on a regular basis and hence, will have the Stagefright fixes incorporated. If you are running an AOSP based rom, it is highly recommended that you update to a newer release of the ROM which incorporates the Stagefright patches. You can use this app to check if your current daily driver is affected by Stagefright.
Stagefright has been nothing but a wake up call towards Android and its problem of fragmentation as well as updates. It highlights how there is no clear mechanism by way of which such critical fixes can be rolled out in a timely manner to numerous devices. While OEM’s are trying to roll out patches for devices, the harsh truth is that most of these fixes will be limited to recent flagships only. Other non-flagships and older devices, much less from smaller OEM’s will continue on being exposed to the like of Stagefright.
There is a silver lining to this exploit: It did re-draw attention over Android’s update process and pitched it in a light which will not attract as many future corporate companies towards adopting Android for enterprise use. As Google works towards greater enterprise adoption, it will be forced to rethink its update strategy and the amount of control it allows OEM’s.
With Android M coming closer to market release by the day, it would be no surprise if Google chose to break away more and more components of AOSP in favor of its Play services package. After all, that is one area that Google still retains complete control over if a device is to ship with Google Play Store. This has its own downsides in the form of replacing open sourced areas with close sourced walls.
When speculating the future of Android, there is a (very small) possibility that Google may also limit the changes that OEM’s can do to AOSP. With the RRO framework being present in a functional state in Android M, Google could restrict OEM’s to make only cosmetic changes in the form of RRO skins. This should allow for faster update deployment, but would be at the cost of OEM’s being denied the opportunity to fully customize Android.
Another route that may be a possibility would be to make it mandatory for all devices shipping with Google Play Store to receive guaranteed security updates for a fixed time period, possibly two years. The Play Services framework could be used to check for the presence of important security updates and patches, with Play Store access being rescinded in case of non-compliance.
This is still speculation at best as there is no elegant way to fix this problem. Short of a very totalitarian approach, there will always be some shortcoming in the reach of fixes. Due to the sheer number of Android devices out there, keeping track on the status of each device’s security would be a very gigantic task. The need of the hour is a rethinking of the way Android updates as the current way is certainly not the best. We at XDA Developers hope that Android still continues on staying true to its Open-Source roots while working along with Google’s closed source plans.
Is your phone vulnerable to Stagefright? Do you think your phone will ever receive a Stagefright patch? Let us know in the comments below!