An NCC Group Publication A few notes on usefully exploiting libstagefright on Android 5.x Prepared by: Aaron Adams © Copyright 2016 NCC Group Contents 1 Introduction .................................................................................................................................. 3 1.1 Credits ................................................................................................................................... 3 1.2 tl;dr ........................................................................................................................................ 3 2 A few notes on usefully exploiting libstagefright on Android 5.x .......................................... 3 2.1 MMS as a realistic exploit vector? ........................................................................................ 3 2.2 Leveraging recursion for more efficient heap spray.............................................................. 4 2.3 Bruteforce complexity woes .................................................................................................. 9 2.4 Semi-effective multi-device support on Android 5.x ............................................................ 10 2.5 Working within the Android SELinux sandbox .................................................................... 10 2.6 Breaking out of the SELinux sandbox ................................................................................. 14 2.6.1 Improving reliability ................................................................................................ 14 2.6.2 Improved stability by cleaning up ........................................................................... 14 2.6.3 Disabling SELinux .................................................................................................. 18 3 Conclusion ................................................................................................................................. 22 NCC Group | Page 2 © Copyright 2016 NCC Group 1 Introduction At NCC Group, a colleague and I recently spent some time trying to develop a more robust exploit for the Android libstagefright bug CVE-2015-3684. This is a bug that persisted through the patches Joshua Drake (jduck) originally provided to Google, so a few more firmware versions are vulnerable. In this white paper, I will discuss a few tricks we came up with to make the exploit a bit more robust with regards to address space spraying, dealing with SELinux sandbox restrictions, automating device identification, and staging a kernel exploit. Unfortunately I didn’t have any breakthroughs on the ASLR bypass front, and similarly I couldn’t come up with a reliable exploit when using dlmalloc feng shui on Android 4.x devices, because the combined brute force complexity resulting from layout instability (thanks to so many noisy mediaserver threads) and no ASLR bypass makes the timing required for exploitation unrealistic. It’s possible I missed some useful approach though, so feedback is more than welcome. Despite the noted failures, I think some of the improvements I made could be interesting to some and so are worth documenting. As is often the case, I highly recommend reading a few other blog posts before reading this post, as they provide good background information and provide details I don’t bother replicating here. Jduck’s original presentation and exploit is the best starting point; then Exodus Intelligence’s bug writeup and reports about CVE-2015-3684; the Google Project Zero blog on exploiting the bug on Android 5.x with the jemalloc heap; and the Keen Team write up on CVE- 2015-3636 exploitation. I glaze over many technical details under the assumption you have first read and understood these write ups. Also please note that I will refer to MP4 headers as either an ‘atom’, typically when referring to the actual type indicator of the header, or a ‘box header’, typically when referring to the header as a whole (both the type and length fields). This is consistent with the terminology used by the actual MP4 standard. Some sources seem to use the term chunk, which is especially confusing when you’re also talking about heaps which have their own meaning for the word chunk. 1.1 Credits I talk about a few different exploits and bugs in this paper, and want to give credit to those that did the work on these before me. Kudos to Joshua Drake from Zimperium for originally finding the libstagefright bugs and releasing an exploit targeting 4.0.4; to Jordan Gruskovnjak from Exodus Intel for finding and explaining the hole in the libstagefright patches that led to CVE-2015-3864; to Mark Brand from Google Project Zero for releasing details on exploiting CVE-2015-3864 on Android 5.x; to Wen Xu and Yubin Fu of Keen Team for finding and exploiting CVE-2015-3636; and to fi01 for posting exploit source for CVE-2015-3636 on GitHub. If I missed anyone, please let me know and I’ll update the paper. 1.2 tl;dr I built a slightly more reliable exploit for Android 5.x, which works across multiple devices and can stage a kernel exploit that breaks out of the SELinux sandbox and turn SELinux off. ASLR bruteforce is still required however. 2 A few notes on usefully exploiting libstagefright on Android 5.x 2.1 MMS as a realistic exploit vector? NCC Group | Page 3 © Copyright 2016 NCC Group You will notice that we focus on the HTTP vector rather than MMS and maybe you would wonder why? There are at least few problems related to the MMS vector: 1) Sending a large file is not a very effective spray mechanism across devices and the optimal spray approach I will show later in the paper only works over an HTTP transport. 2) MMS gateways seem to actually vary on how large of MMS files they accept. This wasn’t thoroughly investigated on our part, but in practice we were unable to even send 2MB media files between devices. 3) Assuming you had a solution for problems 1 and 2, you would still need to bruteforce ASLR which doesn’t seem feasible over MMS (pending some other trick someone hasn’t published). This means you’d be limited to non-ASLR devices (as shown by jduck), which are Android 4.0.4 devices and earlier. There are still plenty of those devices floating around, but we found even exploit reliability on 4.0.4 and earlier isn’t ideal due to heap layout issues. 4) Finally, for generic MMS-based exploitation on ASLR-enabled devices to really be effective you’d also have to have a way to either ignore device versions or automatically determine them as part of the ASLR bypass. For instance, a blind ASLR bypass that lets you re-use existing code that you could predict at static offsets from some partially corruptible pointer still means you need to know the exact model and build you’re targeting, which you won’t easily know through the MMS vector, without having done some pre-exploitation reconnaissance. Maybe someone out there has figured out a way to practically overcome all of these problems and if so I do hope to see a post about the solution someday! 2.2 Leveraging recursion for more efficient heap spray The bugs in libstagefright can be triggered locally or remotely, with the latter being possible over HTTP. I started working with the exploit released by Google Project Zero, which only works over an HTTP transport, although this isn’t explicitly mentioned in their post. The reason is that it relies on the allocation and corruption of a new MPEG4DataSource object, and in order for this to be allocated the data source being used to read the MP4 must be cache-enabled, which is only the case for the HTTP transport. It’s probably worth noting that you can target a different object (like a SampleTable object) for corruption, which allows for exploitation over non-HTTP transport, but then you lose the ability to heap spray effectively in the way I am about to describe. In the Project Zero blog the following observation was made: “After a bit of experimentation, it seemed that the best way to achieve this in practice is by wrapping a number of our ‘pssh’ chunks inside a valid sample table (‘stbl’). This triggers the creation of a caching MPEG4DataSource, which will then allocate and save all the data for the contained chunks; and will then be used to parse out the chunks. This essentially doubles the size of our spray, reducing the size of file needed.” This was a pretty interesting finding, and to me seemed worth thinking about more. First, let’s revisit the main idea. Assuming we send an approximately 2MB MP4 file, where most of the data is contained with a sample table (designated by the stbl atom), that means we get approximately 4MB of data copied into memory. This isn’t too bad, but also really not great in practice. I found in testing across a large number of different builds, on a few different devices, that spraying this amount of memory wasn’t very reliable as far as being able to use a constant address for every target. The address that worked on some devices would often not work on others. So the question I inevitably asked was whether or not this observed functionality could be leveraged to spray an NCC Group | Page 4 © Copyright 2016 NCC Group almost arbitrary amount of memory with a minimal amount of in-file overhead, and the answer turns out to be yes. First, to understand why this is an HTTP-only trick, it is important to understand that the creation of a caching MPEG4DataSource is actually only possible if the primary data source itself supports caching, as specified by the kIsCachingDataSource flag. Let’s take a look at the related libstagefright