PG - Treble or Trouble: Where Android's Latest Security Enhancements Help And Where They Fail - Tami

hi everyone yeah so my name is Tamir and I'm going to talk about Android security and some new stuff in Android security basically I'm going to start speaking about some Android security enhancements security enhancements in general and your background I'm going to talk about 40 tribal the topic of this talk and new security enhancement by Android I'm going to talk about the vulnerability I found related to project rebel and lastly I'm going to discuss whether project rebel is actually a good security enhancement or not so one thing I think should know that I know Android the PI Android 9 came out two days ago but still like these features was done and under a torero but it's all still

completely relevant ok so before we go into details a little bit about myself my name is Tamara Zahavi brunner I worked in I work in a company called Imperium where I do mostly Android research and reliability research and I would like to use this point to really thank the Imperium for allowing me to do this interesting research and work with really smart people ok so security enhancement let's start back with a question so my show hands how many of you has ever dealt with exploits within a CTF challenge exercise whatever ok nice still keep your give your hands up and after few guys who here has ever dealt with a security enhancement nice ok so

you kind of know what I'm talking about to mention it a little bit more so we know by now that that when writing code code is written by humans so we know that we can prevent bugs humans obviously make mistakes so you can't really expect to prevent all the bugs in the world instead what we do is that we introduce security enhancements security enhancements are added as an extra layer of Defense they are there to basically do mostly either prevent bugs from turning into vulnerabilities or to prevent vulnerabilities from being exploited easily so I have here some examples for very common security enhancements I'm not going to go into every single one but the important thing here is that

Google really like the security and has met approach they add new security enhancements in every major version this is something they really do a lot and one very massive security enhancement in Android is SELinux let's look a little bit into that so this diagram I have here is actually I think similar to many operating systems in that you have the untrusted code this time the application and it wishes to perform a privileged operation it doesn't have direct access to this driver so it uses inter process communication IPC in order to ask a privileged service to perform that operation this again is a very common process but here we have a 'selenic so how is that relevant

everything here every application and every service are a process excellence allows you to apply a set of rules for each process limiting what each process can do this way every application is limited by the same set of untrusted application the same set of rules for untrusted application but is service because it's service performs a different operation each service has its own custom set of false and sometimes the service would have a very very narrow set of rules this means that if you manage to compromise the service what is you can do with that is limited you are only limited to that narrow set of force okay so this is one security enhancement let's talk about another

example but this time from the bad point of view I'm going to start with a bug so stage-fright kind of going back to Android their security history set of vulnerabilities published in 2006 so there was a whole talk about stage fright there's no point about talking about it that much but the core issue here is that you could through a single vulnerability to a media file which means completely remotely you could compromise the media server process which was very high privileged you could get access to the camera for instance do with the audio very dangerous obviously something that Google wanted to defend against so the first step was to fix the bugs but then a more drastic approach

was needed let's look at that so as I mentioned in the first slide when when humans write code you can expect bugs to be there so media files are very hard and very hard to process and a very complex file format so even today so stay fit was in 2015 this is from a bulletin from 2018 with similar bugs in the media file person code googling you okay they knew that they couldn't fight each small battle and really work hard and fix every single bug that was just not going to be possible so the approach they took is a security enhancement so it took them some time from stage fight but eventually they reach the media

server hardening or separation what you see here is the in Android nougat Android 7 they decided to separate the service the media the highly favorite media server service into multiple processes this way the service in charge of processing media files is no longer very privileged you can almost do nothing with that so vulnerabilities like stage fright no longer are dead dangerous ok so up until now I've been talking about kind of history stuff but again this talk about spur to travel so less that predictable maybe some of you heard about that already Google discuss about project rebel a lot in the context of Android updates so Android it's a project rebel was introduced as part of Android the real

hundred eight and essentially what it does is that it separates between the AOSP the Android Open Source Project part basically the core the raw open sourced Android part and the vendor part the samsung galaxy samsung samsung LG nokia their own code this way when you want to update you can update only the USB part meaning that updates are much easier it also authorizes a security enhancement so this telegram here is also based off based on stuff that Google discuss so basically Google after the separation in Android nougat of media server they noticed that there were still some services single services with access to multiple drivers so they wanted to perform similar separation with for all these services and they

actually combined that idea with the separation between vendor and OSP part so what they did is I as you can see in the diagram previously you have a service with access to multiple drivers but with project travel it is separated there's like the which previously was one service with both vendor code and ASP code is now a single AOSP only service and multiple vendor or hal hardware abstraction layer services mode and you you but you usually have is for each driver you would have its own hull this way you no longer have a single service accessible to multiple drivers and you have a separation between the AOSP and the vendor part also worth noting the linux again is relevant here

because when you separate between what each service and each process should perform the rules become again much narrowed alright this is an example so you know services were separated in Android nougat and in other where they were imported travel they were separated even more okay so up until here I've been talking about kind of background information this is what Google talked about okay this is from Google presentation this but you know I'm a security researcher I went to research how stuff actually work behind the scenes I want to really understand how they work internally so I decided to look into it and basically research how for the treble really works so in order to do that I decided to pick

single service which went to portraiture modifications I picked media TM server so immediately REM server in short it is in charge of helping applications decrypt DRM encrypted media like Netflix and in order to do that you need to have access you have access to the tea or trust zone so I'm not going to go into that you can have a whole talk about the trap zone itself but basically the you need access to the tea driver so again you have this whole format of untrusted application contacting service for access to the drug to the T so this is how it works but still this is kind of wrong because as we said for the travel came into

place the services were separated and you don't know no longer have a single service you have the AOSP service and the vendor service ok cool now let's go a little bit deeper and talk about real technical stuff in how maybe there are M server operates so this is how the decrypt method of media DRM server and let's talk a little bit about the input that the do QT method receives the acute method is in charge of decrypting encrypted data so the input and this is a little bit complex show so bear with me in order so first of all the decrypted data can be very large it can reach hundreds of megabytes even so you

can't really write all of that through the IPC mechanism that would take a lot of resources and very very costly instead what they used and this is used in many services in Android they use a feature of the operating system called shared memory the encrypted data is on the space in the memory space of the application and the application simply writes to the IPC mechanism our reference to that area in them in its memory the service can then use that reference in order to map it the same memory area to its own memory space and have instant access to the encrypted data and after it writes the decrypted data into that same shared memory the

application again will have instant access to that give the data making everything much quicker so some data that does pass through the IPC mechanism there's some metadata as you can see here about the source and destination buffers basically indicating where the encrypted data is on the source buffer and where did the keep that data should be written to the destination buffer one thing you should note is that the Health Service is the one who actually performs the write operation and rise to the destination buster so this is how the do keeps method operates normally one more thing I mean again for us from a security researcher point of view to make stuff a little bit simpler you can

actually send a flag here that indicates has no data data is encrypted but rather the data is clear meaning that the Health Service would simply copy the data as it is from the destination from the source buffer to the destination okay cool okay so that's all the information about the input format so what we have here when you think about it is a copy of data between this one buffer to another based around on our own input this is an interesting place for vulnerability research right you have copy of data between buffers in a privileged service so I decided to really take a good look into that and into the validation code because if you

think about it if they miss something in the validation for the input before the copy itself then you might have an out of front read or an out of bounds right so yeah I looked at all the validation code and it looked at yeah I found nothing yeah and that's it that's not the talk hey and I'm kidding so I actually found something and so this interesting line or rather this interesting missing line so let's explain the highlighted line here is actually a perfectly fine validation line so what happens here is that another input parameter passes to the IPC mechanism which is the size of the data which is separate like it's separated from this side of the source

or destination buffer is another completely different input parameter this means that the service would have to verify that this the number like the this number the size of the data doesn't surpass the size of this source or destination buffers so this line basically verifies that it verifies that for this first buffer the total size here is the size of the data and this time verifies that total size is less than or equal the side of the sauce shared memory but there is no similar line for the destination buffer which means that let's say we send the service a very large source buffer with a lot of data and a very small destination buffer what would happen here is that the

Health Service would attempt to copy all the data from the source buffer to the destination buffer essentially causing a buffer overflow kind of a classic case of a vulnerability we have we can overwrite data in the hull memory space the health service outside the shared memory with our own data again data completely under our control you know kind of a classic buffer overflow vulnerability so yeah successful vulnerability okay so yeah that is very cool but again this talk is about project rebel and security enhancements so how do they come into place so I actually looked at it and one of the first thing they noticed was how stuff like portable kind of changed stuff here so before / - okay

let's think about this further treble actually modified how the whole chain operates here I mean if you think about it a whole new process was added to the chain the new vendor process everything was modified the whole code was we factored one of those changes was how the inputs were structured before for the treble you had one buffer basically which contained both the source and destination which means that the the encrypted data would be overwritten where the service will decrypt the data but in Project rebel they separated it into two different buffers but forgot to add the check for the destination buffer and this essentially caused a vulnerability but now this is a little bit strange because okay you're thinking

wait poetry was supposed to be a security enhancement it's not supposed to introduce new vulnerabilities it's supposed to remove them so weird but okay maybe they miss something they didn't spot that can really blame project rebel for that so actually okay I took a very good look at the code it was a factor because the further table and there were many other issues yeah the vulnerability was a little bit hard to spot but some of the stuff here I spotted them very easily this really led me to the belief that maybe this code didn't receive enough attention and because I think that perhaps if a developer would have looked at least and found one of those issues the developer

would maybe spend more time on the whole code and maybe even prevent the vulnerability but then you could say all right so media tear em server wasn't refactored properly is portable to blame here so this is a list of vulnerabilities not in media DRM server but rather in other services all similar in the way that they were all introduced because of portraiture we'll be factoring so this kind of raises the question was there all be factoring like it was enough attention put into the whole refactoring and kind of leads me to the final conclusion of this talk which is the answer to question-is protectable a good security enhancement so my answer is actually yes but or yes in theory so well the way

Google described project revel in theory yeah it's good the whole process separation very nice and it actually benefits security as it is right but I believe that the actual implementation here was neglect a little bit su so with all the vulnerabilities and stuff I discussed which can I mean and it's kind of important because you know in order to yeah it sounds important to really have really invest in the implementation as well because I I kind of like it makes me think at least that maybe Google were a little bit too keen with the whole announcing new security enhancements and yeah we have portable so sophisticated we need stuff and that and that but they didn't like invest

time in its implementation so to sum it all up my final point here is that I believe that in order to really have good security good security you need to have good code quality as well as security enhancements yeah so yeah that's it I would also like to use this opportunity to thank some we're friends and colleagues who helped me with the research and presentation specifically a Sneha my besides mentor who really helped me a lot throughout the presentation so thank you very much and also some references if you in case you want to read some more technical information about the vulnerability okay yeah that's it and thank you for coming [Applause]