 So without further ado let's jump right in because there are many slides and very few minutes. So you guys probably all know why you're here. So here's a little agenda. We'll get through it hopefully. I'll do a little bit turbo version. So if I talk too fast just kind of raise your hand and I'll try to slow down a little bit. But I have to go quick. So let's jump right in and talk about Android. Let's go. So I'm Josh. Go by Jduck on the internet. Some of you may or may not have interacted with me. I welcome you to say hello anytime. Currently I work for Zimperium doing mobile defense research. It's excellent to work. Lead author of Android Hector's Handbook and founder of DroidSec which we'll be having a little event somewhere in the building later. So if you see us drinking join us. Previous affiliations and all this stuff. So my motivations in doing this research really were to improve the overall state of mobile security especially in Android. There's been years and years of people talking about all these problems in Android and I'm like I got to be able to do something about that. So I kind of decided to do what I do best which is discover and eliminate critical vulnerabilities and also exploit them to show people that they're real. They're not some BS. I'm trying to save my phone battery. There we go. All right. So I also wanted to spur people to start thinking a lot harder on some of the mobile security issues so that they could really make the improvements in their organizations that they needed to. I wanted to increase visibility of risky code in Android. There's a lot of code in Android. It's like 60 gigs of stuff. And apparently people don't read any of it as you'll see later. And also last year I gave a talk at Black Hat and a couple of other conferences about the joint army. Basically I collect Android devices, have them all connected right now through USB to a computer, can query them at any time, cross versions, across OEMs, across CPUs, whatever. So I want to use that some more. So I want to thank the sponsors. I started this work when I worked with Occubant. We was now Optiv. They graciously allowed me to take this research on with me and see it through to the end or at least, I guess I would really call this the end, but at least do this. I want to thank Amir as Amir here. Come on. You missed Botox Amir. Man. I'll get him later. Don't worry. All right. So I also want to thank Colin and Matt Selnick. Are they in the room? They're probably not either. Okay. They're both fired too. All right. So what is stage fright? Stage fright is Android's multimedia library. It's primarily written in C++. There are some parts of it that are written in Java. We're getting that a little bit more. The handle is basically all audio and video on the device. It's meant to stand as a kind of go between the Dalvik applications and other sort of high level stuff in Android and the hardware because a lot of Android devices actually have hardware video decoders. Yeah. It also extracts metadata, which we'll see is kind of important. So a brief history. Android back in the 1.0, 1.5 days, they launched with an engine, a multimedia engine called OpenCore, which was apparently donated to them by some random organization. Later, during the 2.0 development, they added stage fright to the ASP. However, they weren't really using it. It was kind of like they were starting to develop it. In 2.2, they made an optional to use. So it had like a setting that you could set in the system properties. But all the devices I had with 2.2, which isn't very many, they had it enabled by default, so I just assumed everyone would do that. That's a pretty good assumption, I think. I also saw some really nice forum posts where everyone were like, oh, we need to enable stage fright because it's fast and OpenCore slow, it sucks. Anyway. So, at 2.3, Gingerbread, and we're talking about 2010, I think, time frame here, set this as a default engine and got rid of OpenCore entirely. A side note, this code was pulled into Firefox and Firefox OS. Well, Firefox OS is a fork of Android at the beginning, so that's not really a surprise. But they also decided to pull it into Firefox, ship it on all versions of Firefox except Android, sorry, except Linux around version 17. So why did I look at stage fright? What was the big deal? And honestly, I can't remember exactly why I started looking at it. It might be the name when you kind of look through, you're like, oh, stage fright, that sounds interesting. Sounded scary, right? Definitely a big plus if you want to audit some code to look for native code. It's oftentimes much bugger than Java code. A lot more ways to screw that up. And also a lot of times the people who do end up writing native code often are not very good at writing code. They don't really understand what they're necessarily doing. So that's cool, especially with respect to security. So also there's various public mentions. So people on Reddit and other places posting saying, my phone keeps rebooting randomly and you know, you read down and somebody's like, oh, you have a corrupt file on your SD card or something. So I was like, that sounds really bad. It's got to be pretty bad code. I have to check that out. And then finally, like there was some related work that was published in my recently in April where I was like, you know, that is really cool stuff. Maybe I should do a talk on that stuff. So we'll talk more about some of the issues reported in this one. It's pretty cool. These guys fuzzed a crap out of basically stage fright directly on Android emulators I think. And they work for Intel so they were x86 Android emulators. And basically they said they had like 11.5 terabytes of media files that they created that crashed stage fright, which was pretty intense. That's more data than I think anyone's going to go through. So they reported some bugs and we'll talk about them a little more later. So another related work was there was this paper about black box fuzzing on mobile devices. This is pretty much what I did in part of it. So it's definitely related and they also talk about some of the stuff they had found in stage fright. So related work, really old stuff, was Charlie Miller's talk where he talked about Android hacking like back before Android was even released. He found a vulnerability in a multimedia file that he reported. This was so long ago that it was on open card and on stage fright. So stage fright is pretty big. It's about I think something like 10,000 lines of code. Probably actually more than that. And it supports a wide variety of multimedia file formats. There's a spot in the code where you can literally look at this one function and it's like if it's this format do this, it's this format do that. And then you can see which way it goes. Most of the code that they support in stage fright is backed by common open source libraries like libvorbis or libflac or vpx, all these other kind of open source libraries which are projects of their own. However, there is also a bunch of code that it lives directly in stage fright. So that was my focus. I decided to pick MP4. I thought it was, you know, relatively straightforward file format. But I thought it would be a good one to mess around with. So the rest of this talk will primarily focus on MP4 stuff for the examples and findings. So system architecture, let's talk about how it looks on a system where this code runs. A little bit of high level. This is the new diagram that they like to that they're showing on the developer site. It's pretty cool. And now they're calling out media servers specifically. I'm not really sure why they decided to do that. There's many more things that run in the background besides system server and media server. What they do is a lot of inter process communication to talk between processes. Basically, media server is running as a background, native service. It starts from a knit. And in Android, I've heard somebody told me recently that this wasn't necessarily a case in older versions. But in Android now, if something that's running from a knit crashes, it's just automatically restarted. So we'll revisit the knit thing a little bit. There's also some other things that it affects. We'll talk about again. So let's look at privileges, right? Like what do you get if you pop this thing? That's very interesting to find out, I think. And this is actually another reason why I looked at this service. Remember, I wrote a little tool called PRIVMAP to look at processes and see what they were running as. And this one stood out as like having some potentially like silly permissions right away. So you can see at the bottom line of the kind of like coded text area that they have all these groups there. So actually the media server, although you would think it's been sandboxed and moved and segregated in order to limit risk of the code, they're actually like making it very privileged, I guess, in order to do what it needs to do for the most part. So for example, the audio group is used to lock down access to the speakers and the microphone. If you have the audio group, then you can do anything with input and output of audio. Camera is a similar thing, iNet. There's actually things within the media stage fright and other parts of the media server that require connecting back to the internet. The biggest example being DRM media, which will have to go out and get a license for that when you try to play it. And then also, you can see the group here for DRM. So I did a survey of the joint army. I wanted to figure out, yeah, this is that slide. So I made this slide, I had no idea what this number means on the left. Accessible groups sorted by number of devices. And these numbers don't make sense to me. 17 doesn't seem like a number that would jive with what I wrote here. So I will look into that later and fix it when I publish the slides. All right, so I did some more surveying just besides whatever the hell that set is. I think maybe it was the breakdown of devices. Okay, yeah, so this is how many devices I looked at out of the 51 were from Google or from Motorola or from Samsung. So this kind of gives you a little bit of an overview of what my joint army collection looks like. Okay, so the privilege survey, I want to look at each group and see how many devices had which groups. So you can see they all say 51 on the left because these groups are on all devices. So we already talked about what you can do with that. It's pretty bad. So let's look at the other groups that are hanging out. We start with this bandwidth band with the counting thing. I think that's really pretty much uninteresting. But then you have DRMRPC. Usually that is used to talk directly into trust zone. Which trust zone is a very sort of interesting attack surface I think on Android devices. Because it's kind of like ring negative one, right? So it's above the kernel. It's more privileged than the kernel. So then you have the next one which is system. So system is the number two sort of user on Android. It owns the slash data partition. So everything that's writable on slash data is writable by that user. And if it's not writable since it owns slash data, you can just move it out of the way and put whatever you want there in its place. So system is a very high privilege. It's really just under root and it's well thought of in the research community in Android that if you have system that getting root is pretty much just an engineering effort, not really too much of a serious full reach of effort. So then we have the next one is graphics. So graphics is used to lock down basically the frame buffer devices for Android. And there have been numerous vulnerabilities discovered and exploited in the frame buffer stuff. I think right now it's pretty solid. But I couldn't be proven wrong, of course. So we keep going down the list that we got input. That means if somebody gets a device, one of these eight devices and they get in through media server on that, then they can watch your keystrokes or inject keystrokes into your use of the device. At the bottom you have shell. So shells, the user, they assign to ADB shell. I have no idea why they would give that to media server at all. It blows my mind really. But it's interesting. And then the last one is radio. So radio is basically right below system in that if you have radio you can make calls and MMS, man in the middle, all communications with the cellular network. You can take down cellular network connection that you have. So it basically runs all the stuff that's between the cell network and the rest of Android. Okay, so architecture recap. Live stage fright runs inside media server. Media server is fairly privileged, including sometimes system. It automatically restarts whenever it crashes. It's a fairly large attack service that's provided based on all these groups that you're given. The path from remote to the kernel through another vulnerability that you have to find in a driver or something is probably not too difficult because of all this extra attack service that's being given to you once you're in with those privileges. So let's talk about the attack service of Android. Basically in order to figure out what's going on with the code I just opened up a movie while I had a debugger attached. I put a break point just on the open thing. I was like, okay, we're going to play a file so it's got to open it. And then when I hid I looked back and started digging around in the code. So here's what the back trace looks like. You can see I'm playing the playing .mp4 file. And you can see all the different functions that are called in the process, including some paths to where they are in the OSP code base. So when you start looking closer you can see the set data source function. I think it's like, this is not even showing right here, but basically you can see where at the top it calls create from URI and then after that it calls this media extractor. And so we start looking at that and we end up with this function that loops through all the tracks that you count. When you look at that it says read metadata. So in order to find out how many tracks there are in a media file you have to extract the metadata because that's where it stores that information. So we look at that and it just goes into this function parse chunk. So let's look at that a little bit. So the parse chunk function is the primary attack surface inside stage-fried .mp4 parsing code. It's a recursive function so when it sees an atom that's supposed to have more atoms inside of it, when I say atom I'm talking about a tag length data piece of the file. So they just, I think actually they put it length tag data, but anyway that's what it is. Hey Amir come in here. Let the guy in the green chair and his lovely wife in here please. Yes those two. Yes and the lovely wife of course. You missed your shot out again but now you're here. Give it up for Amir. When you look at Android all versions like across the ASP which is beautiful because Git is wonderful. I love Git. You see that earlier versions had about 80 atoms supported and newer versions had about 140. So it's roughly almost double the amount of code over the course of the development. So we'll look a little closer later but you can see here an example where the move and the track chunks are especially handled where they say oh well we have more chunks inside so it recurses. And the recursion is really not relevant other than it's annoying to debug recursive codes sometimes but let's keep going let's talk about attack vectors. So when I talk about attack surface I'm always thinking about things that are deep in the code that you're trying to tickle and try to find the volts in and when I talk about attack vectors I'm thinking about all the ways to get there. So the ultimate goal on looking for attack vectors is to figure out like I said how to get my data in there. Oh I'm in trouble now. So first you can try all possible ways to send yourself a media file. Unfortunately it depends on. No no no go ahead. All right you want to try? Sure. All right go ahead. A thorough methodology. Find all calls into this function and ask yourself can an attackers data reach here? How am I doing? You're good. Maybe I should try that more. You need to work on your graphics. So if you had any idea how hard it was to do graphics in this presentation framework you wouldn't say that. Just put a picture of a waterfall in the background. Waterfall? Make everybody have to go to the bathroom. So you just repeat this process until you find them all right? You can't really know necessarily without looking all through the code all the ways it's possible. There's some problems with doing the second methodology when it's more thorough and after you have to deal with all these complicated issues like there is a place inside media server in this code path it actually calls into and out of Java code like back and forth about three times in one stack trace. So that's pretty wild. You got to open a lot of files and have them all kind of in the background or however. Excuse me. Yes sir? This one is not. Let me come on the other side. Let's dance. All right. Are we live yet? Awesome. All right now. How many of your first timers at DEF CON? Awesome. But you all know the drill by now. What do first time speakers do? So how's he doing by the way? Geez. Slow down speedy. All right. Anyway, so I'll become a speaker with a little tradition we call shot the new. Cheers. DEF CON. Thank you my friends. I owe you a shot. All right. Let's do it after. All right. So the other thing is there's a lot of object oriented code. We mentioned C++. We mentioned Java. So that oftentimes when you're like auditing code paths or looking to try to understand the code you have to do all this crappy stuff where you remember the member functions and variables and all these crazy classes and stuff. So then again more files to have open. It's fun. You have to be careful about objects instantiation and lifetimes and things like that. Further on Android because of the modularity and the IPC you end up having to sometimes cross boundaries that are like between processes. That can be hard to follow. But you can get through it if you keep trying. Sometimes you might have to take a break or a nap or something. I know that works for me. So that's the best way all possible ways. Go to the code, right? If you want to know what the code does, it's in the code. So go there. So the first vector I kind of stumbled upon or thought about was the video tag in HTML5. It's like this is brand new. I wonder if it does. So I fire up the device with the debugger attached to the parseChunk function or actually the readMetadata function which is a little bit better. If you put a breakpoint on parseChunk, it's great. But as soon as you hit the first chunk, it will break. But then every other chunk it hits, even when it's recursing into more chunks, it will keep getting hit. So it's pretty annoying to just keep saying continue all the time. So definitely we hit the breakpoint. And so I went on and tried to, I was like, you know, Thomas Cannon back in the day talked about this way to force Android to download files. And they used it in some sort of vulnerability that would load JavaScript through a weird content provider or something. So this is actually a straight screenshot other than the part on the left where the path is wrong in the URL. But anyway, so you go and as soon as you touch this link, you see this page in the middle which can be anything. It doesn't have to be, you know, what it is right now with this big white screen. It can be like cat pictures or whatever you want. You see this downloading toast come up which disappears after basically like one second. The only other indication that you did anything downloading anything is this little downward arrow with a line at the top. Now if you swipe down from the top and touch that, it'll tell you that you downloaded a file, you can touch that and you see what's on the right. Now the crappy and scary thing is here that the vulnerable code, the stage fright code is actually triggered as soon as the file is downloaded and it does not require you to go and open the media or touch it or look at it or anything like that. That's interesting. Oh look, I also did a feature request that was like, hey, can we like get some kind of prompting for this? Like I don't really want auto download stuff. I may not expect a link that I click to cause a download. So maybe that's not a good idea. So when I look deeper into how this worked, I decided to take a step back and say how is this working? What I found was that this whole subsystem called the media scanner. And so the only thing really documented in AOSP that is for people to use as developers is the media scanner connection. And really all that does is you create an object and you say scan this file and that's really it. The other thing is they're in the intent documentation. So there's the intent class and the Java stuff for Android. They have this long, long, long, long list of intents that are supported in the system. They have these two media mounted in media scanner scan file. So they're documented as well although they're basically one line and a huge table. And then if you look closer, there's this class that's used a lot internally in the code, the media scanner connection client. That one actually is used a lot. So I don't want to go too much deeper into this. Actually when I was making the slides I went all crazy deep and then I was like, you know what, there's no way I can talk about that. That's like a whole other talk right there. So I put it at the back of the slide deck so when you get a slide deck, you can go back there and check it out. So tons of attack factors, right? We're talking about once I went through the methodology, I looked at all these different ways to call onto this media scanner and stage fright other ways. I basically found that you can do through MMS, it triggers this code because it's showing you a thumbnail of the video. Even if it didn't show you a thumbnail, I just wanted to know how many seconds long the thing was that would still trigger it. So there's client size, we mentioned browser and download, there's also email. So if you get an email with an attachment on Android, it'll basically say it has an attachment but it won't download it automatically. You have to like push the button to download the attachment. When it's downloaded, of course it will scan it. How nice. So to back up just for one second, there's a way inside of these APIs to actually tell it, so not media scanner stuff, but a lot of these attack factors use the download manager. That's what I talk about a lot in the bonus slides, the download manager. There's ways to call in the download manager where it tells it not to scan the file. However, everywhere where I saw it in the code where they said don't scan the file when you download it, immediately afterwards they called the media scanner on the file. So okay. So physically adjacent, that's stuff like we're all in the same room together. Or in the case of NFC, you're a little bit closer. These are also attack factors. If you have an SD card slot on your device, somebody could totally insert an SD card in your device and potentially compromise it. Or an OTG drive if your device supports that special USB mode. And then there's the MTPPTP mode. This has been the default mode on Android devices, including Nexus devices since 4.0. I have a whole bunch of other research into this subsystem, but it's not going to fit here. And so if you connect the device to your computer with this mode and you transfer a media file to it, it will also scan it. So I say 11 plus attack factors, but really if you think about it, anywhere that a media is thumb nailed or like in any way like probed for metadata will trigger the stage fright code. So do you guys use any of these to talk to people you don't trust? Or even worse, do you think anybody who you don't trust could somehow communicate with you without you asking with any of these? So the scariest part is MMS by far. My research initially was on doing stuff over the SD card. I said, discovered the media mounted intent, which basically says when you stick the SD card in the volume manager says hey, there's a new SD card mounted and then the media scanner does its thing. So that's where I started, and then eventually through the attack factor research I found MMS and I was like, wait that can be good. So one day I just was messing around, I sent myself a video to it, not a malicious video at all. Just sent it to myself with the debugger attached of course. And my screen was off, phone was locked on the table and it hit the break point. I'm just like, what? Are you kidding me? So before even creating a notification it's like trying to get a screenshot of this video and then it's going to put it at least on newer versions, it will put it in the notification. See if I have some pictures. I don't know if I have some pictures on this. Ah yeah. You're right, I need more pictures. So I don't have some, I just put them in here. So in theory hey Dan, how are you? So in theory, if you exploit this vulnerability through MMS and you do some pretty neat engineering work you could potentially stop the whole process of the MMS going through. You could delete it from wherever it's stored. You could stop the audio notification because you've already taken control of the process that does all audio. And then you can, nobody would know anything even if they were using their device at the time. So that is a theoretically possible thing and it freaks me the fuck out. I don't know about you guys. But it is a lot more work. I did not do that work. I didn't want to do that work. So the MMS stuff works in hangouts. Further testing later like I guess a couple weeks ago the new version of the app Messenger which is kind of like the throwback of the old messaging app that they removed in your versions also does a lot of processing automatically and especially on receipt. The older version does not do it although if somebody sends you an MMS message you can imagine who it is and it's like hey did you see this video of you? You might want to be like me and then you look at it and then you're done. So turn off auto retrieve if you guys use hangouts or messenger because it's nasty it's vulnerable potentially. So the vulnerable code is invoked all the time. This device here I think I disabled the app if you haven't had a MMS that comes in messaging in this phone like if you're looking at it it triggers the vulnerability if you turn the screen sideways it redraws the activity and then triggers the vulnerability again you do that again triggers the vulnerability again you lock the screen and then you unlock it triggers the vulnerability again so basically anytime it's drawing the screen it's like that's another trigger so are there any other attack factors? I do not know I got this question a lot on Twitter like is silent text effected is like the whatsapp effect I don't know I don't use any of those things because a lot of times when a lot of people jump on to a technology it becomes kind of like a big risk in itself. So reach out if you have any ideas or any thoughts or you do any testing I'd love to hear about that sort of stuff so let's get into bugs I think I have like 10 minutes or something is that not right? Who's got the timer? Oh we can do this yeah we can do this so the basic methodology was just to write a fuzz or a simple one really dumb it will just process media repeatedly repeatedly and while it's running go read some code and if it crashes then go read, go request because obviously that's got to be some pretty bad code you just do that until again your brain melts and you want to go nap or whatever. First round the details again focused on MP4 we didn't bother to create a large corpus we basically just used one media file or two I can't see my cursor is it over there? Yeah here it is maybe we can play the video that we used fuzzing this is a total waste of time but it would be funny yeah not normal to use a computer screen that's 20 feet from you so yes thank you for that that was badass so you can imagine it was a lot of fun hearing that sound over and over again when you don't hear it you're like hmm wonder what happened then so we deposit for about a week and we found 6200 crashes I went through all these crashes and bucketed them and then looked deeper into them and unfortunately the crashes we found from the fuzzer were all very sort of not interesting bugs they're like checking if something is zero not the guys who wrote stage fright decided they were going to kill themselves and crash the whole process thus making you lose audio and everything else so about 20 bugs but they're not that awesome a lot of no point of reference as well but when I was looking at the code I'm like okay well that's lame but let's look around maybe just at this function and within two or three lines there was just very important vulnerabilities so I found about five during code review then they became these two CVEs the first one was like kind of a merger of several issues because of similar root cause and affected versions so on second round we decided to throw American Fuzzy Lop I don't know how many people have heard of American Fuzzy Lop because he loves it, he's used it how many people have actually used it we got really like not very many people who said they heard of it even and like tend heard it heard of it so American Fuzzy Lop is a fuzzer developed by Michael Zalewski he's been in the security industry for a very long time and basically he came up with this idea of like let's look at the way code flows and if code flows from here to here then let's treat that as like a transition and keep track of like I guess like three things like a try and then he's like if there's a new one like code flow from here to here instead of from here to there then that's new, that's good, we want more so his goal in creating this fuzzer it wasn't really necessarily to find crashes although that's always going to happen when you do a lot of automated testing his goal was more to find new code paths with the purpose of building corpus in a more programmatic and more sort of intentional way rather than you know the traditional other way is to go down with all the files you can find and then run through this like long process where you see like what code does it hit which not very much fun so I didn't really again develop a corpus the thing is with AFL you don't really need one so I'm just kind of like echo yo yo yo into the file and then I ran it and it went really well so the work involved I had to develop code I ran AFL on my Linux server that I just got it was like 32 core machine double hi-fines and every once in a while like I guess every day or so maybe two days I would stop the fuzzer go all through the results triage them and bucket them and then look at each individual unique thing and try my best usually I got it on the first try but sometimes I had to do a little more deep analysis to fix the vulnerabilities and start the fuzzer running again the idea being what is the point of finding the same free conformability 800,000 times not really fun so this slide is super cool I don't think I finished it but let's go ahead anyway like the testing we tested for about two maybe three weeks off and on going through that methodology the speed was about 3200 executions per second so it was about 1000 executions per second per core found a lot of bugs and when I say it was fixing vulnerabilities that includes no pointy references I'm like that's land crash let's get it out here so that's nice get rid of the noise so that resulted in some more bugs you can see the first four actually so I guess that slide before was a little inaccurate those first four were the ones I found during the first round and the remaining those other six came up during the second round in addition to all the no pointy references which didn't get assigned to these so let's look at that issue that I said we'd look at it again from the other related work so around a year ago they put stuff fixed into the AOSP from those guys who did the fuzzing and here they say check in a drill flow during the table these three bugs even closer I saw this go in Android 5.0 was released and I'm like that's really interesting so here's the new code you can see they're assigning the results of some math to a 64 bit unsigned integer that looks like it would be good but is it? I thought this was good by the way I don't know where I went just now so I thought this was good I was like they fixed that one let's just keep going so when I was running FL I actually found this crash over and over again and I'm like wait a minute I thought they fixed it but it turns out when you multiply a bunch of 32 bit integers together and assign them to 64 bit integers it does all the math first in a 32 bit sort of way and then it just goes in and assigns the result to the 64 bit integer so there's no promotion happening at all and so the fix and I don't think I even had the fix in here but the fix was basically just casting one of them to a 64 bit integer it could have been the 2 it could have been the size of it could have been in here so these vulnerabilities remain they basically zeroed in themselves by saying come look at this although it did look like it was fixed so let's talk about exploitability but let's just go faster so many of these results in memory corruption and heat memory these have been proven exploitable lots and lots of times especially in C++ code given that they often have virtual function pointer tables and other sort of strange things going on in heat memory so mitigations do come into play though and diversity although it is a barrier that will make it take more time it doesn't necessarily prevent something like a worm which could just build support for as many things as it knows about into itself so media server recap we talked about this before but let's talk about it in a frame of exploitation so we have a net starting media servers that means two things on the positive side that means this weakness that's been in Android since the beginning and is still there where Zygote as apps are created and it doesn't work because it forks but it does not exec and it does fork and exec so every time it crashes the address space will be completely more randomized again and this only applies to newer devices a 4.0 and later the AVE SLR at all so but on the downside because it restarts whenever it crashes you can just trigger it over and over and over and over again although that does depend on attack factor you can't imagine to download your email attachments and look at them over and over again he's going to get kind of fed up so it also means is that word possible or poisible that's new so you can also bypass with cheer root force so another thing is multiple threading in media server basically has some threads that listen for binder events which are completely uncontrollable by an attacker because they're coming from outside and that means that there's a little bit lack of determinism in the heap layout so apart from AVE SLR even if it was all not randomized chunks might get in the way cause a little bit of a boundary so how many slides do I have left so new and Android 5.0 so Android 5.0 added a mitigation that most people were probably not aware of in fact the guys who actually make Android were probably not aware that they got this basically the code here in the top block it's doing a new number of elements of an array creating an array with new bracket bracket GCC they finally like added a way to catch this sort of problem where the integer overflow happens kind of intrinsically inside of what's generated by the compiler this I don't have a link right now but the work that these guys did was almost ten years old so the compiler team and Android decided to switch to GCC 5.0 maybe because it matched Android 5.0 I'm not sure but they decided to do that so let's look at a breakdown of the big important mitigations on Android how they apply to vulnerabilities so SC Linux pretty much doesn't come into effect unless you're already in so if you get in it may limit you from what you can talk to although if you have a vulnerable audio driver it makes block you from the audio driver stat cookies completely irrelevant because there's not stat corruption going on fortify source irrelevant because these are all dynamically allocated heap buffers and fortify source has no visibility into dynamic memory allocation ASLR as we said it only applies we got another ten minutes I thought that was GTFO or big ups let's just keep going I understand you just drag me off when you're ready so basically what we're attempting to do is we're going to hold this track and go a little bit longer we're going to hold this track and go a little bit longer I'm almost done I want to do a demo first though so NX is not a big deal you can bypass through the rock ASLR again some stuff the newer versions it's still probably possible to bypass ASLR newer versions it just requires either something maybe an information like vulnerability or it might require you to do some really neat tricks because it's only a 30 minute layout so exploitability definitely on old versions very badly definitely on old versions the newer versions yeah I think it's doable and I want to spend some more time with it but right now I do not have time because I am speaking to you guys on stage so I think I have somewhere on this computer a window not the cap window let's try this one is that good can you guys read that in the back the text or do I need to make it super bigger if you're going to read I got a thumbs up from row like negative 3 bigger okay bigger boom boom boom boom boom boom boom boom boom is that good enough where's my mouse it's on the wrong screen here so I don't know if this is going to work I did not do a live demo but let's try it we got the device right here I'm deleting messages I sent myself in the speaker room I'm just going to leave the screen on right here and then we'll run this exploit just like this so one point of importance is that this attack right now is not going over a carrier network it's a violation of the end user license agreement and in terms of conditions that you use the network so this is going over a tool chain basically that allows me to pretend like messages are coming in from the carrier network and then also host my own MMSC server so let's just run it so this made a big old 2 meg video file and it sent it down this channel I probably can't see this I'm just looking like an idiot over here I didn't get any messages yet either that's why you don't do live demos because people show up to your talk and they bring stuff like rogue base stations I still haven't got a message yet although I see it transferring something I want to show you guys the screen but it's like tricky it's tricky to show you both of the screens at the same time open what? something get, user, media I can't see down there so I still haven't got a message I think we're just going to go back to the video because this is retarded I'm really disappointed because this exploit works like every time but not always on the first try unfortunately except for right now because of whatever reason it's preventing it from working it looks like a network issue so let's play a video it'll be more fun and it's got cool music by Archie Vartek I'm going to tell you guys how we get audio from there so the first time we did it with the screen off just to show you that there's no indication that anything happened so also when the screen's off the device goes low power mode and it goes very slow this privilege escalation is old old old buck so that's the thing about old devices is they're easy to exploit and they're also full of old bucks that give you root that makes it extra bad there thank you how to do this, they hooked me up before you coming to beat me? a couple more slides I told people do not go out the side door go out the back it doesn't work go out the back not the side please so I hope you guys get an update soon I think they're rolling out now