00:00:00.000,00:00:06.406 >>Um so hey everyone um that’s my first Defcon actually. So 00:00:06.406,00:00:11.078 smile. [cheering] [whistling] [applause] [laughter] Okay um so 00:00:11.078,00:00:16.083 today i’m going to present to you a research that we have had 00:00:18.685,00:00:25.425 done last year on the Qualcomm driver’s code for Android. So uh 00:00:25.425,00:00:30.197 are agenda for today first we’ll briefly speak about chip sets eh 00:00:30.197,00:00:33.367 the location in the Android ecosystem how they affect the 00:00:33.367,00:00:35.836 overall security of an how the effect the overall security of 00:00:35.836,00:00:40.340 Android. Then we’ll focus on Qualcomm as a chip set and 00:00:40.340,00:00:44.077 review its values uh sub systems. After all to be able to 00:00:44.077,00:00:46.914 reveal 4 new Audi vulnerabilities that we have 00:00:46.914,00:00:50.984 recently discovered including a fully working exploit for one of 00:00:50.984,00:00:54.755 them. Finally we’ll discuss some ideas for improving the overall 00:00:54.755,00:01:00.127 security of Android. So just a little bit about myself, um my 00:01:00.127,00:01:04.064 name is Adam Donenfeld I’ve been a security researcher for years 00:01:04.064,00:01:08.235 and both in the mobile and in the PC field. I’ve merely done a 00:01:08.235,00:01:11.271 vulnerability assessment and exploitation. Eh right now I 00:01:11.271,00:01:13.674 work at checkpoint as the lead security researcher for Android 00:01:13.674,00:01:18.879 and in my free time I also study German. Eh additionally I would 00:01:18.879,00:01:23.483 like thank uh Avi Bashan, Danny Brodie, and uh Pavel Berengoltz 00:01:23.483,00:01:28.822 For supporting me during your research. Okay so uh most people 00:01:28.822,00:01:32.359 think that go only go getters involved in the development of 00:01:32.359,00:01:36.229 Android but that’s not the case. Many other third party vendors 00:01:36.229,00:01:39.900 still take a large part in the final product we buy. Um the 00:01:39.900,00:01:44.504 heart of every Android is obviously um the linux kernel. 00:01:44.504,00:01:48.976 Afterwards we have a the AOS. The Android open source project 00:01:48.976,00:01:53.480 which is developed exclusively by Google. And then things uh 00:01:53.480,00:01:56.583 start to get a little bit more complicated because then we have 00:01:56.583,00:02:00.954 the chip sets. So what is actually the chip sets? So when 00:02:00.954,00:02:05.892 you buy an LG, a HTC, Nexus or some sort of device. Even though 00:02:05.892,00:02:09.162 these companies do manufacture some of the hardware, the 00:02:09.162,00:02:11.999 majority of the hardware is actually manufactured by the 00:02:11.999,00:02:15.502 chipset vendor. Now not only is the hardware manufactured by the 00:02:15.502,00:02:19.306 chipset vendor uh but the drivers for this hardware is 00:02:19.306,00:02:24.011 also all the vendor and then this entire package is uh 00:02:24.011,00:02:29.416 forwarded uh to the OEMs and is modified by each OEM and 00:02:29.416,00:02:34.287 receives various customizations and then finally uh we gets our 00:02:34.287,00:02:39.693 device. Now as you can see uh chip sets is very essential in 00:02:39.693,00:02:43.330 this process and if you find a vulnerability in the chip 00:02:43.330,00:02:46.867 [inaudible word] in a chip set code it means that it has to go 00:02:46.867,00:02:51.104 through the entire uh all the OEMs so does uh does not only 00:02:51.104,00:02:54.541 mean a long wait and fix but also a very large victim pool to 00:02:54.541,00:02:58.378 attack. So if you find a vulnerability in Qualcomm 00:02:58.378,00:03:04.184 reposing leads to all Nexus, HTC, LG and many Samsun Samsung 00:03:04.184,00:03:09.890 devices. So um Qualcomm has a very large impact on the overall 00:03:09.890,00:03:14.528 system. Infact there are a lot of different sub system systems 00:03:14.528,00:03:18.098 which are completely written by Qualcomm. Each one of these 00:03:18.098,00:03:21.268 subsystems is a great place to start look for all 00:03:21.268,00:03:23.870 vulnerabilities and if the company is lower level enough in 00:03:23.870,00:03:28.008 the system uh one vulnerability would probably be enough to 00:03:28.008,00:03:31.678 completely compromise the system and that with not mentioning 00:03:31.678,00:03:35.415 companies that have been modified by Qualcomm to satis to 00:03:35.415,00:03:40.287 to satisfy its requirements. And we’ll see an example soon. Um 00:03:40.287,00:03:45.292 so, this again. So today, I will be disclosing 4 new Audi 00:03:49.796,00:03:53.100 vulnerabilities. Each one of them accessible for any 00:03:53.100,00:03:56.970 unprivileged application on the device. The first one is 00:03:56.970,00:04:02.676 Hashemian devil Uh the second one is core roots uh which we 00:04:02.676,00:04:05.812 already explained. The third vulnerability is called 00:04:05.812,00:04:11.451 sincockaroot And the last one is kangaroot. So let’s start with 00:04:11.451,00:04:15.956 ash with Hashemian devil. So Hashemian devil is a 00:04:15.956,00:04:20.393 vulnerability in the Ashmem mechanism uh Ashmem or androids 00:04:20.393,00:04:23.930 uh shared memory is unique shared memory uh allocator for 00:04:23.930,00:04:28.568 android. It reminds a little bit the Linux SAG mechanism but with 00:04:28.568,00:04:32.372 slightly different behavior and it support a very simple uh file 00:04:32.372,00:04:37.344 based API. Now Qualcomm expanded the functionality of Ashmem, the 00:04:37.344,00:04:41.715 API of Ashmem, so it can easily obtain um an information about 00:04:41.715,00:04:45.819 the file uh eh eh an Ashmem file from an FD. So for example we 00:04:45.819,00:04:52.259 use it if we want to map Ashmem meh the memory to the GPU. So 00:04:52.259,00:04:56.997 Qualcomm added this function so basically uh what the- what the 00:04:56.997,00:05:01.635 function does this. it gets a file descriptor and a few output 00:05:01.635,00:05:06.306 pointers it extracts from the file descriptor uh then internal 00:05:06.306,00:05:09.776 [indiscernible] structure of the file. It checks that this file 00:05:09.776,00:05:13.547 is actually an Ashmem file and if it is it extracts data uh 00:05:13.547,00:05:17.584 from the file. If it’s not the earth count is dropped back and 00:05:17.584,00:05:22.889 the function uh is finished. So it’s kind of straightforward and 00:05:22.889,00:05:26.459 in fact we couldn’t find a vulnerability there but a 00:05:26.459,00:05:32.032 question that most of us mus uh must uh must ask ourselves is 00:05:32.032,00:05:35.802 how does Qualcomm actually verify that our file descriptor 00:05:35.802,00:05:41.441 is an Ashmem file descriptor? So the way to that to do that in 00:05:41.441,00:05:45.745 Linux is first to extract from the file descriptor the internal 00:05:45.745,00:05:50.750 structure of the file which we can see here. Just a second uh 00:05:53.153,00:05:58.592 which you can see here and then it’s filing in the system uh I 00:05:58.592,00:06:01.928 mean for let’s take for example a socket file. Each socket in 00:06:01.928,00:06:04.798 the system has a file so there are a lot of file types in the 00:06:04.798,00:06:09.869 system. So in order to determine their type each socket each file 00:06:09.869,00:06:14.507 has it's uh a pro a a specific operation handler. For example, 00:06:14.507,00:06:17.978 let’s say that we perform the right operation on a socket 00:06:17.978,00:06:22.415 file. The behavior in comparison to a regular file is obviously 00:06:22.415,00:06:25.886 different. So we simply has to check uh we have to check the 00:06:25.886,00:06:28.688 the handler of this specific operation and then we know the 00:06:28.688,00:06:33.727 type of the file. So uh Qualcomm reside uh decided to reinvent 00:06:33.727,00:06:39.499 the wheel and the way that they checked for type file um was by 00:06:39.499,00:06:43.136 the name of the file yeah. If the file is called Ashmem, it 00:06:43.136,00:06:47.240 must be an Ashmem file right? [laughter] So [laughter] So so 00:06:47.240,00:06:52.245 what they got here uh if we have a file called Ashmem route of 00:06:54.881,00:06:59.886 any mounting point we can fake the internal Ashmem uh data but 00:07:01.921,00:07:06.626 unfortunately flash is with only and any mounting point on a 00:07:06.626,00:07:11.431 system uh that a is inaccessible for unprivileged applications 00:07:11.431,00:07:13.933 and we say that we want to exploit it without any prior 00:07:13.933,00:07:19.873 permissions. So what I did to overcome that was using uh a 00:07:19.873,00:07:26.513 feature called OBB. So OBB or opaque binary blobs is a feat a 00:07:26.513,00:07:30.317 deprecated feature that fortunately still works. So as 00:07:30.317,00:07:33.219 you might know Google Play doesn’t allow apps with file 00:07:33.219,00:07:37.157 size that is greater than 100 uh megabytes. Now obviously there 00:07:37.157,00:07:41.127 are some apps especially games that have lots of sounds, talk 00:07:41.127,00:07:45.965 structure, uh textures even uh pictures whatever and they cross 00:07:45.965,00:07:51.171 the 100 megabyte limitation. Um so what I usually do is first 00:07:51.171,00:07:54.240 downloading just the code functionality and then they 00:07:54.240,00:07:58.712 download externally and the rest of the textures. So what OB is 00:07:58.712,00:08:03.149 it’s basically a file system that uh any app can download and 00:08:03.149,00:08:06.152 mount and so let’s take that with let’s take Angry Birds for 00:08:06.152,00:08:10.290 example it’s off a game. Once we the first time we load we launch 00:08:10.290,00:08:13.526 uh Angry Birds it downloads externally all the all the 00:08:13.526,00:08:17.630 pictures and sounds and then it just it downloads and OBB file 00:08:17.630,00:08:21.267 and it mounts it. So any developer can create an OBB file 00:08:21.267,00:08:25.772 and put there any file he wants externally download it and then 00:08:25.772,00:08:30.643 just mount it on the device. So in order to fake an Ashmem file 00:08:30.643,00:08:34.681 what we can do is first just create an OBB file and put their 00:08:34.681,00:08:38.551 file called Ashmem in the route uh directory then we can just 00:08:38.551,00:08:44.190 mount the OBB and then we can send our file descriptor to the 00:08:44.190,00:08:48.495 Ashmem file from OBB to the system and therefore we can fake 00:08:48.495,00:08:54.200 um the Ashmem uh internal structure. [applause] thank you 00:08:54.200,00:08:59.205 [applause] Okay so um now going to the second vulnerability uh 00:09:04.511,00:09:09.749 quarter root. So quarter root is a vulnerability in the IPC 00:09:09.749,00:09:11.117 mechanism of Qualcomm. It’s basically a new address uh 00:09:11.117,00:09:12.452 family in the system uh AFM and IPC it has but it has so many 00:09:12.452,00:09:17.457 unique features. For example uh I can whitelist or blacklist uh 00:09:20.093,00:09:25.098 blacklist um other sockets in the system and filter them by uh 00:09:28.268,00:09:33.873 the group ID or other um uh properties and therefore I can 00:09:33.873,00:09:38.144 prevent unprivileged processes from communicating with me. And 00:09:38.144,00:09:42.115 now another cool feature in this IPC anyone can monitor the 00:09:42.115,00:09:46.820 entire system so for example I can get a notification for any 00:09:46.820,00:09:51.057 creation or destruction of the socket with this uh address 00:09:51.057,00:09:55.562 family. And the best thing about it no permissions are required 00:09:55.562,00:10:00.567 to do that. So um this this uh address family has 4 different 00:10:02.769,00:10:07.207 uh subtypes and we are going to focus only on client port and 00:10:07.207,00:10:11.211 control port. Mainly because IRSC port and Server Port 00:10:11.211,00:10:15.615 require um high privileges. So everytime you create a socket 00:10:15.615,00:10:19.152 the socket is a client port socket. A client port socket can 00:10:19.152,00:10:23.623 communicate with other endpoints and send and receive a data. Now 00:10:23.623,00:10:27.927 control port is a socket that can not communicate with other 00:10:27.927,00:10:32.165 endpoints it will only receive messages about the creation or 00:10:32.165,00:10:36.302 destructions or destruction of sockets in this address family. 00:10:36.302,00:10:40.840 So how do we create a control port? Um we simply issue an 00:10:40.840,00:10:45.812 ioctl on the client port. So the function that um handles the 00:10:45.812,00:10:52.352 octile is this one. Basically it um it locks the all current end 00:10:52.352,00:10:56.956 point so we can’t issue to octile simultaneously on the 00:10:56.956,00:11:01.561 same socket and then according to our command it uh performs 00:11:01.561,00:11:05.732 operations so if we issue IPC router octile bind control port 00:11:05.732,00:11:10.069 it will be converted from a client port to a control uh to a 00:11:10.069,00:11:14.140 control port. So that’s the function that converts uh our 00:11:14.140,00:11:19.712 socket. So each type has a list and the conversion is simply uh 00:11:19.712,00:11:23.950 taking out uh a client port from it’s list and putting it back 00:11:23.950,00:11:29.422 into putting putting it into the control port list. So that’s the 00:11:29.422,00:11:34.827 conversion function and there is a vulnerability here. So let’s 00:11:34.827,00:11:40.233 examine this function uh step by step and find a vulnerable code. 00:11:40.233,00:11:46.673 So can you see the code here? Is it visible? Okay so uh the first 00:11:46.673,00:11:50.977 instruction is um taking a lock on the client list that’s 00:11:50.977,00:11:54.914 because you modified the list and then we take the object out 00:11:54.914,00:11:58.952 of from his list. Then we unlock the client list we lock the 00:11:58.952,00:12:02.188 control list we add our object to the co to the control list 00:12:02.188,00:12:05.992 and then we unlock the control list. So let’s examine it. 00:12:05.992,00:12:10.430 Locking the control the client list taking the object out from 00:12:10.430,00:12:16.302 his list, and locking the client list, locking the control list, 00:12:16.302,00:12:21.941 adding our object there and then unlocking the control list. Um 00:12:21.941,00:12:26.446 pretty straight forward and in this flow nothing was uh 00:12:26.446,00:12:30.550 problematic. But what happens if we try con to convert an object 00:12:30.550,00:12:34.454 that we’ve already converted before? So we lock the client 00:12:34.454,00:12:38.558 list, we take the object out from his list, which is not the 00:12:38.558,00:12:42.996 client list, we unlock the client list, we lock the control 00:12:42.996,00:12:47.433 list, we put the object back, and we are unlocking the control 00:12:47.433,00:12:52.305 list. So for those of you who missed uh we even though we take 00:12:52.305,00:12:57.443 a lock on the client list we are modifying without uh locking and 00:12:57.443,00:13:04.183 we modify uh the control list. So um we got something here. The 00:13:04.183,00:13:08.087 control ports list is modified without the lock and therefore 00:13:08.087,00:13:11.824 there is erase condition. We can delete 2 objects simultaneously 00:13:11.824,00:13:16.829 from the control ports list. [laughing] Okay so now um just a 00:13:21.434,00:13:26.005 second sorry. Let’s see what happens when we delete the 2 00:13:26.005,00:13:30.343 objects simultaneously from the list. Um uh we’re work we’re 00:13:30.343,00:13:34.981 working in the context of A and that’s the Linux kernel that 00:13:34.981,00:13:38.851 removes objects from a double linked list. And if you can see 00:13:38.851,00:13:42.755 here if you can see it so you have the serial code here. So 00:13:42.755,00:13:47.560 basically uh we are taking now A’s next which is B and we set 00:13:47.560,00:13:52.598 B’s pref to be A’s pref. So B’s pref equals control ports and 00:13:52.598,00:13:56.769 now since the list is not locked there might be a contact switch. 00:13:56.769,00:14:03.009 So uh now we are working on the context uh of B. So we take B’s 00:14:03.009,00:14:08.014 next which is C and we set C’s pref to be B’s pref so C’s pref 00:14:08.014,00:14:13.953 equals control ports and now we have to take care of um B’s pref 00:14:13.953,00:14:18.491 which is control port which is um uh control ports. Just a 00:14:18.491,00:14:24.731 second ya now k here sorry. So we set control ports next to be 00:14:24.731,00:14:30.703 B’s next so control ports next equals C and finally B is being 00:14:30.703,00:14:32.972 all points to poison and remove is removed from the list and 00:14:32.972,00:14:38.311 it’s not wo- just removed from the list but it is also freed. 00:14:38.311,00:14:41.948 So now this memory is reclaimable by uh kernel hit 00:14:41.948,00:14:47.887 spraying or any other method you choose. And now uh going back to 00:14:47.887,00:14:54.127 A uh we take care of A’s prefs so control ports next equals B 00:14:54.127,00:14:58.231 and just like B, A is removed from the list. It will now point 00:14:58.231,00:15:03.169 to poison and uh that’s it so. If we uh remove all the unused 00:15:06.439,00:15:11.444 object in this list you get this so the list now points to a free 00:15:14.213,00:15:19.418 reclaimable by kernel history data. So uh we just use uh you 00:15:19.418,00:15:23.689 unix dgram to spray that now since this is the list of the 00:15:23.689,00:15:27.493 control ports now once we fake an object there we want the list 00:15:27.493,00:15:32.565 to be used. So we just create or destroy any endpoint in this 00:15:32.565,00:15:35.668 address family becau and each time we do that all the object 00:15:35.668,00:15:39.539 on this list must be modify uh notified about that. So the 00:15:39.539,00:15:43.810 notifying function is post pocket to port. So each object 00:15:43.810,00:15:47.079 in the controlled ports list is transferred to the post pocket 00:15:47.079,00:15:52.585 port uh function. So that’s the function. Uh we are not going to 00:15:52.585,00:15:56.622 go [stuttering] all over it. As you can see here we have a lot 00:15:56.622,00:15:59.592 of new primitives from information disclosure to 00:15:59.592,00:16:04.597 function calls and memory corruption and many other uh 00:16:04.597,00:16:07.400 primitives. I think that there is at least one more way to 00:16:07.400,00:16:12.038 exploit the vulnerability but the path that we chose was using 00:16:12.038,00:16:17.944 wake up. So what is wake up? Wake up is actually a micro to 00:16:17.944,00:16:21.848 another function called uh wake up common and as you can see 00:16:21.848,00:16:26.853 here since we control um the first primitive of wake up we 00:16:28.888,00:16:34.727 also control Q. Now task list is derived from Q so therefore we 00:16:34.727,00:16:39.098 control we control curr. So we have a new primitive here we can 00:16:39.098,00:16:43.502 we can call any kind of function um on the ca uh we can call any 00:16:43.502,00:16:48.274 kind of function while we control uh a large por- portion 00:16:48.274,00:16:53.112 of the first primitive. Now if we wouldn’t have snap it would 00:16:53.112,00:16:58.484 be uh a game over but uh we uh overcome snap. So a new 00:16:58.484,00:17:01.787 primitive uh ca uh camera function call with the first 00:17:01.787,00:17:05.458 with the first param control controllable. However uh it’s 00:17:05.458,00:17:07.927 not good enough for commit creds. Commit creds for those of 00:17:07.927,00:17:11.097 you who don’t know is a kind of function that allows you to 00:17:11.097,00:17:15.868 change your current credentials. Now since we control most but 00:17:15.868,00:17:19.972 not all of the fields parameter we can’t call common creds 00:17:19.972,00:17:23.509 because we want full capabilities. That's because the 00:17:23.509,00:17:27.513 current address is a part of the first parameter. So if you want 00:17:27.513,00:17:31.083 to control the accurate kind of address we can not control 1 100 00:17:31.083,00:17:35.688 percent of the first parameter. So we had to upgrade our 00:17:35.688,00:17:39.525 primitive. We have to find a function that controlling just a 00:17:39.525,00:17:42.795 little bit of its first parameter will allow us to call 00:17:42.795,00:17:47.800 another function uh which full 100 percent control over um it’s 00:17:51.170,00:17:56.175 parameters. So we look for such a function and we got USB read 00:17:58.177,00:18:03.616 it and walk FN um as you can see here we control walk so we 00:18:03.616,00:18:08.521 control SA SCH. Controlling CH allows us to control rec and 00:18:08.521,00:18:12.391 therefore we can call any function while we have 100 00:18:12.391,00:18:15.861 percent control of the first parameter and so buff is an 00:18:15.861,00:18:19.732 address and we can just put any pointer here and so each time we 00:18:19.732,00:18:23.102 want to call a can a function out we have to go through ovel 00:18:23.102,00:18:26.505 over over this over this this chain so first we call uh wake 00:18:26.505,00:18:29.875 up common which you can see here then we call using this function 00:18:29.875,00:18:33.779 we call USB read it and walk FN and finally we can call any kind 00:18:33.779,00:18:36.983 of function uh uh while controlling uh the first 00:18:36.983,00:18:41.053 parameter. And now we have enough uh primitives to 00:18:41.053,00:18:43.990 completely cover by the system [laughter] get ourselves good 00:18:43.990,00:18:48.928 disable the Linux and clean up our mess. So uh let’s start 00:18:48.928,00:18:53.265 again exploitation flow. We have a list a a double link list and 00:18:53.265,00:18:57.703 each time we create or destroy an end point on the list, the 00:18:57.703,00:19:02.541 list is iterated and we uh we can you uh it will be used. So 00:19:02.541,00:19:06.545 the first that thing we’re going to do is get the use after free 00:19:06.545,00:19:09.115 situation that we saw before using the vulnerability and 00:19:09.115,00:19:14.387 therefore put a fake object there so first we um so there is 00:19:14.387,00:19:18.557 a free object in the list. Now uh since this memory is 00:19:18.557,00:19:23.362 reclaimable we can just can use heap spring to uh reclaim this 00:19:23.362,00:19:27.400 data. We used in instagrams but again you can chose your co 00:19:27.400,00:19:32.905 convenient uh convenient uh spring method and now we control 00:19:32.905,00:19:37.443 this object. Sorry. Cover this object and the next thing we 00:19:37.443,00:19:41.380 wanna do is get the system to use this object. So triga- 00:19:41.380,00:19:45.751 trigger iteration on the list so we just close or create any 00:19:45.751,00:19:50.156 socket on this endpoint and the list uh our object is being used 00:19:50.156,00:19:53.559 and then we go toward the function chain call. We go to uh 00:19:53.559,00:19:57.830 wake up common we chooses our fake task list and then we can 00:19:57.830,00:20:02.068 call um criminal functions uh conveniently. So the first funct 00:20:02.068,00:20:06.605 function that we call is Q disk list del um it cleans up lists 00:20:06.605,00:20:10.576 so our fake object will no longer be there. Inface the list 00:20:10.576,00:20:14.313 will be just empty so for for the use of the list nothing will 00:20:14.313,00:20:20.086 crash then we call enforcing set up which uh effectively sets SE 00:20:20.086,00:20:25.057 linux permissive and finally we call common creds which sets our 00:20:25.057,00:20:28.828 UID to zero and gives us the full available capa capabilities 00:20:28.828,00:20:35.134 of on available to the system and we want haha [laughter] 00:20:35.134,00:20:40.139 thanks [applause] and now um time for a demo so um [laughing] 00:20:43.209,00:20:48.214 on the left we have a console I hope you can see it but if you 00:20:52.518,00:20:58.758 have to believe me at first we install uh our demo app um now 00:20:58.758,00:21:02.795 ss now uh and we’re going to the see that this device is uh a 00:21:02.795,00:21:08.934 marginal device which relatively new Linux conversion. Now and 00:21:08.934,00:21:12.571 additionally we’re going to see that SE linux is fully enforced 00:21:12.571,00:21:17.042 uh and that’s uh super suite is not installed on the device so 00:21:17.042,00:21:20.813 it’s not routed it actually comes like from the store like 00:21:20.813,00:21:25.284 that. And um we’re going to see that we are not route so it’s we 00:21:25.284,00:21:31.657 are we are running on the user tool 000 so shell. Um okay now 00:21:31.657,00:21:35.594 our payloads sim uh pay uh our payloads uh put the sword file 00:21:35.594,00:21:40.900 in the system partition and it creates a service uh a local a 00:21:40.900,00:21:46.138 local uh netcat server listening on port 1337 which simp uh which 00:21:46.138,00:21:50.242 just forwards commands to um bash as route. So now we’re 00:21:50.242,00:21:53.979 going to see that system is not modified and that this local 00:21:53.979,00:21:56.849 server uh does not exist. K now we are going to launch our 00:21:56.849,00:21:59.385 exploit uh so we’re gonna see some crap on it uh locate 00:21:59.385,00:22:01.253 [laughs] be patient. That's it we’re route so now just uh 00:22:01.253,00:22:03.589 cleans up stuff uh then enter uh it takes approximately 2 seconds 00:22:03.589,00:22:05.925 to exploit this um vulnerability and then you get you can run 00:22:05.925,00:22:08.060 your own payload uh as route without noting inter uh that 00:22:08.060,00:22:10.963 will uh stands in your way. So now we are going to see that um 00:22:10.963,00:22:14.133 we’re still not through er uh we don’t have LSO and we are not 00:22:14.133,00:22:16.368 through yet but SE linux is now no longer enforcing its 00:22:16.368,00:22:20.306 permissive and if we try to netcat to our local server 00:22:20.306,00:22:25.311 instead of getting connection refused, we are in. So now we 00:22:35.154,00:22:40.159 see the new system has a file called Zugan that’s access in 00:22:51.370,00:22:56.375 German. I’m studying German [laughs] and you’re going to see 00:23:02.881,00:23:07.886 now F stop which is unaccessible to uh route. So and finally ID 00:23:13.726,00:23:18.731 shows that we run SD Kernel and [applause] Um thank you uh so 00:23:26.772,00:23:31.777 that was core root and now we are going to uh the last 2 00:23:40.819,00:23:45.824 vulnerabilities see the cockaroot and uh G- kangaroot 00:23:49.295,00:23:53.299 but before we talk about em uh we have to uh swear uh talk a 00:23:53.299,00:23:58.837 little bit about a mod um um a mechanism called IDR. So IDR is 00:23:58.837,00:24:01.874 a Linux kernel mechanism so it’s not just for Android and it 00:24:01.874,00:24:06.512 allows mapping between numbers like just ruh ID’s to counter 00:24:06.512,00:24:11.283 pointers. When to use that let’s say that we want to let the user 00:24:11.283,00:24:14.953 uh reference kernel object so we don’t wanna reveal the kernel 00:24:14.953,00:24:20.793 object so we just give them uh an safe ID. So how does it look? 00:24:20.793,00:24:23.929 Uh the user wants to create an object so it sends the kernel it 00:24:23.929,00:24:25.964 creates object request, now the kernel allocates data and 00:24:25.964,00:24:30.202 initializes a new object now the kennel doesn’t want to give back 00:24:30.202,00:24:35.207 this address to the user so instead of instead of doing this 00:24:37.910,00:24:42.414 it just uh passes this address through the IDR mechanism which 00:24:42.414,00:24:47.519 now maps between this address and the number 1 and now the 00:24:47.519,00:24:50.622 number 1 is returned to the user and each time this uh wants to 00:24:50.622,00:24:54.526 update the object eh destroy the object do whatever it want to do 00:24:54.526,00:24:58.297 the object. It will send a kernel uh just hey I wanna 00:24:58.297,00:25:03.068 update this object object ID 1 and the kernel will use the 00:25:03.068,00:25:07.873 ideal mechanism to get the address from this one. And now 00:25:07.873,00:25:11.877 uh syn cockaroot. So syn cockaroot is a vulnerability in 00:25:11.877,00:25:17.015 an object called sync source in an ioctl sync source eh it’s in 00:25:17.015,00:25:20.152 the synchronization mechanism between the GPU and the 00:25:20.152,00:25:23.722 currently running appla- application. We don’t have to 00:25:23.722,00:25:26.258 know a lot about this object to understand and see the 00:25:26.258,00:25:30.396 vulnerability we just have to see how to create and destroy 00:25:30.396,00:25:34.433 this object. And as we’ve seen before the IDR mechanism this 00:25:34.433,00:25:38.604 object is referenced with the IDR mechanism. So that’s the 00:25:38.604,00:25:44.510 function that destroys that frees the object um uh here’s 00:25:44.510,00:25:48.013 the controls data I mean it’s it is sanitized so actually just 00:25:48.013,00:25:54.286 controls uh ID here. And kgsl syncsource get obtains from this 00:25:54.286,00:25:59.792 ID this IDR ID. I kennel object uh coding source now how does it 00:25:59.792,00:26:04.496 work here? It’s a brief count based object so first it’ll it 00:26:04.496,00:26:08.000 the F count is 1, once we did that uh once once we called this 00:26:08.000,00:26:12.037 function the ref count is increased to 2 then it is 00:26:12.037,00:26:15.107 dropped once for the creation of the object because it’s the 00:26:15.107,00:26:19.978 destroying function and it it is called once again because we 00:26:19.978,00:26:24.416 increase the refcount here. So at this point the object is 00:26:24.416,00:26:30.989 freed but something is missing here is there any pending free 00:26:30.989,00:26:34.993 check uh on the object? What happens if we call this re uh 00:26:34.993,00:26:39.731 this function on 2 different threads simultaneously? So let's 00:26:39.731,00:26:44.470 examine it. We have tread uh thread A and thread B thread A 00:26:44.470,00:26:47.906 called uh the destroying function so now their F count is 00:26:47.906,00:26:52.911 2. Now it drops their F count to 1 and then their mit their might 00:26:52.911,00:26:56.748 be a contact a contact switch so thread B now caused the destroy 00:26:56.748,00:27:01.320 function. Now ref count is going again to 2 but immediately they 00:27:01.320,00:27:05.958 drop back to one. Then we are going back to thread A which 00:27:05.958,00:27:10.529 drop your drops your F count to 0 and at this point the object 00:27:10.529,00:27:15.534 is freed reclaimable and any kernel can uh heap spring will 00:27:15.534,00:27:21.306 catch it and finally uh since thread B did not finish the 00:27:21.306,00:27:26.278 destroy sequence their F count will be dropped to minus 1. And 00:27:26.278,00:27:30.449 on this point once the ref count is 0 we can cause another object 00:27:30.449,00:27:36.655 out our malicious fake object to be freed and then we can further 00:27:36.655,00:27:41.493 it so again if you’ll see we are creating an object and a sync 00:27:41.493,00:27:45.097 source for object we create create 2 threads which call 00:27:45.097,00:27:48.333 destroy which we choose the destroy function on the object 00:27:48.333,00:27:51.670 simultaneously the ref count will be dropped to minus one 00:27:51.670,00:27:55.207 before it gets to minus one it’s on 0 and then we can can heap 00:27:55.207,00:27:59.244 spray the kernel catch it and we have a double free which leads 00:27:59.244,00:28:04.383 to use after 3 so that was in cockaroot and now finally uh 00:28:04.383,00:28:10.489 Kangaroot. So uh kangaroot is a vulnerability um in the KGSL 00:28:10.489,00:28:15.827 minor 3 3DO uh Zero um mechanism. Uh it’s the wrapper 00:28:15.827,00:28:22.267 between uh user mode and the GPU um so each time we map um data 00:28:22.267,00:28:28.340 to the GPU another object called KGSL mem entry is located and 00:28:28.340,00:28:31.877 this object uh manages the address range the range uh that 00:28:31.877,00:28:37.249 is uh mapped. Uh how many uh object like your F count uh 00:28:37.249,00:28:40.485 protection level and many other properties. And again if you 00:28:40.485,00:28:44.790 want to unmap this data we can use the audio mechanism because 00:28:44.790,00:28:48.894 the mappings are mapped uh used by the audio mechanism. So the 00:28:48.894,00:28:52.998 first uh thing that we did was going to destroy function and we 00:28:52.998,00:28:57.402 saw this which looked pretty cool because there was ah there 00:28:57.402,00:29:02.841 was also pending check on the um on the destroy sequence. And 00:29:02.841,00:29:08.080 then we went to shared mem free entry and for some reason 00:29:08.080,00:29:11.984 unfortunately they didn’t forgot to do that here so it’s 00:29:11.984,00:29:15.988 appropriately um locked so we don’t have the same 00:29:15.988,00:29:22.094 vulnerability again. So in fru- in frustration we went to the 00:29:22.094,00:29:28.066 creation creating object so uh this is [stutters] function gets 00:29:28.066,00:29:32.304 I told the kgsl mem entry so we just get blob of data it 00:29:32.304,00:29:36.575 associates this this data with the I uh with an IDR with an ID 00:29:36.575,00:29:40.479 using the audio mechanism and then it is it initializes uh the 00:29:40.479,00:29:45.484 data mounted to the GPU and it add it to some list. So that’s 00:29:48.220,00:29:52.758 not appropriately locked why? Because once we associate we 00:29:52.758,00:29:56.795 associate it with and IDR number it is already be uh ref uh we 00:29:56.795,00:30:00.966 can already reference it from the user from the user mode. So 00:30:00.966,00:30:06.104 here’s how we use this object. Thread A creates some a 00:30:06.104,00:30:09.941 allocates some data. It It’s already uh uh everything here is 00:30:09.941,00:30:15.614 by the way in the kernel already so uh thread A it allocates data 00:30:15.614,00:30:20.419 it associates the um the uh the data with and IDR number so 00:30:20.419,00:30:24.022 anyone can reference it now and then it initializes uh the data. 00:30:24.022,00:30:30.829 Then thread B it it checks for if the IDR item exists and since 00:30:30.829,00:30:35.834 it is it passes this check and frees the data. But what happens 00:30:40.072,00:30:45.077 [laughs] what happens if thread A allocates data associated with 00:30:45.077,00:30:52.050 an IDR number and right then thread B uh issues uh release a 00:30:52.050,00:30:55.721 free request on this object. The object is already there so we 00:30:55.721,00:31:01.593 pass the if check and then the object is freed. So even though 00:31:01.593,00:31:04.096 the object is freed and reclaimable again by kernel heap 00:31:04.096,00:31:10.368 spring thread A did not finish yet. So now uh free not unused 00:31:10.368,00:31:14.973 data which can be used by us will be initialized and we have 00:31:14.973,00:31:19.845 another use after free. So again uh the POC at first we map data 00:31:19.845,00:31:24.516 data to the GPU we get a number um we are going to know which is 00:31:24.516,00:31:27.385 which number will be next because as you can see here it 00:31:27.385,00:31:32.691 is always increased by 1. And then we issue simultaneously a 00:31:32.691,00:31:37.028 create request and a free request on another thread. And 00:31:37.028,00:31:41.166 and there might be again easy to free in the function KJSL mem 00:31:41.166,00:31:45.737 entry at that process on the entry parameter. [laughs] Um so 00:31:45.737,00:31:50.742 that's what you’ll see. Now uh disclosure. So obviously we 00:31:55.714,00:32:00.118 disclosed everything we had a collaboration both with Google 00:32:00.118,00:32:03.255 and with Qualcomm and I must say that Qualcomm was very 00:32:03.255,00:32:08.593 responsive the uh were very uh in very they were very 00:32:08.593,00:32:11.696 cooperative. So uh since cockaroot was fixed uh only 00:32:11.696,00:32:15.433 fixed uh on the 6th of JUly a patch was released and Google 00:32:15.433,00:32:19.671 deployed it to the Nexus devices on the 6th of July also. Um 00:32:19.671,00:32:24.676 Kangaroot was also fixed uh on the 6th of July and but for some 00:32:26.812,00:32:30.749 reason it was only fixed on on on the the patch was only 00:32:30.749,00:32:35.821 deployed uh on the 1st of August. Um Ashmemiam devil I’m 00:32:35.821,00:32:38.490 sorry to disappoint you even though Qualcomm released 00:32:38.490,00:32:42.360 released the patch uh no device was fixed so far at least not 00:32:42.360,00:32:45.730 that no no not knowing that we know about so you are all 00:32:45.730,00:32:49.301 vulnerable congratulations. [laughter] And uh finally uh ka 00:32:49.301,00:32:55.640 kawala root so i uh kawala root was uh was the first 00:32:55.640,00:32:59.544 vulnerability that we disclosed and even though Qualcomm 00:32:59.544,00:33:05.684 released a patch back in April Google did did not deploy it yet 00:33:05.684,00:33:12.190 and I would like to talk about Google for one minute. [laugher] 00:33:12.190,00:33:17.462 So um despite average bug report which usually contains the 00:33:17.462,00:33:21.933 document and 5 lines of code in the best case, we supplied them 00:33:21.933,00:33:27.839 with a fully working exploit for any Qualcomm based device. And 00:33:27.839,00:33:32.777 they classified kawala root as a loss of available vulnerability 00:33:32.777,00:33:38.917 Now what the hell? [laughter] I mean I mean it was an exploit. 00:33:38.917,00:33:43.355 So we approached Google and we asked them why’d you classify 00:33:43.355,00:33:48.026 this repor- our vulnerability as a loss ability of vulnerability 00:33:48.026,00:33:51.763 and you know what they said? They said that they planned to 00:33:51.763,00:33:56.001 block this mechanism using an using using NS Linux lahool in 00:33:56.001,00:34:00.839 the future. So we send it to them it was vulnerable on the on 00:34:00.839,00:34:04.175 all the devices and yet they said ya in the future we’ll fix 00:34:04.175,00:34:10.949 that so just a matter of timing sorry. Um so maybe I hope that 00:34:10.949,00:34:15.120 it will it will it will it will be different for the next time. 00:34:15.120,00:34:18.957 And this is just a single example. I mean that that’s like 00:34:18.957,00:34:23.862 a walking that’s proof that it’s possible. We might have other 00:34:23.862,00:34:26.231 loss of abilities, vulnerabilities which are 00:34:26.231,00:34:30.535 exploitable and it poses a very high risk on all our Android 00:34:30.535,00:34:36.908 devices. So uh so instance for the future and I’m not going to 00:34:36.908,00:34:40.378 say pay attention pay more attention to your code because 00:34:40.378,00:34:44.382 it will never uh uh that's that's not uh a practical uh 00:34:44.382,00:34:48.253 suggestion. I’m gonna give you concrete suggest suggestions. So 00:34:48.253,00:34:52.123 uh the first one for more than for more than a decade common 00:34:52.123,00:34:55.393 creds was an extremely convenient function for 00:34:55.393,00:34:59.864 exploiters. I mean back in two thousand and eight people did 00:34:59.864,00:35:04.836 that. So maybe we can somehow harden it. Let’s take syscall 00:35:04.836,00:35:09.374 reboot for example it actually receives magics so you can’t 00:35:09.374,00:35:13.311 call syscall reboot by mistakes. So maybe we can harden it make 00:35:13.311,00:35:17.082 it inline put magics but this function can not be in the 00:35:17.082,00:35:21.353 kernel anymore. Not in this current situation. Now my second 00:35:21.353,00:35:26.358 advice um KSLR so ASLR is not a new concept iphones are also 00:35:28.393,00:35:33.098 running arm and they have it for years. New Linux kernels do 00:35:33.098,00:35:37.135 support ASLR and yet for some reason Android devices uh 00:35:37.135,00:35:40.772 Android users don’t enjoy from this benefit. So I really think 00:35:40.772,00:35:45.510 that KSLR for Android should be prioritized without KSLR it 00:35:45.510,00:35:49.981 would be much more complicated to exploit kawala root and I 00:35:49.981,00:35:54.319 think every other kernel vulnerability. Um the last uh 00:35:54.319,00:35:59.391 device um so SE linux is very irregulated uh mechanis uh 00:35:59.391,00:36:01.359 security mechanism and it greatly decrease decreases the 00:36:01.359,00:36:03.395 attack surface uh but still I’ve learned thing that unprivileged 00:36:03.395,00:36:05.830 applications should have access to Qualcomm’s internal IPC and 00:36:05.830,00:36:09.401 even though it it’s nice to have it but we should pay more 00:36:09.401,00:36:16.174 attention to the holes that will deploy there. Now with that said 00:36:16.174,00:36:22.981 the over secure uh current the overall uh status for Android is 00:36:22.981,00:36:27.752 fairly good smap or PXM for in forearm which was introduced 00:36:27.752,00:36:31.923 last year made everything much more complicated and yet a few 00:36:31.923,00:36:35.393 small companies are missing to make everything much more safe. 00:36:35.393,00:36:41.232 Now um we created an app uh cre cre created an app which should 00:36:41.232,00:36:46.337 be uh published like now. So it is called core roots scanner you 00:36:46.337,00:36:51.242 can check using the using this uh app you can check if your 00:36:51.242,00:36:56.281 device is vulnerable. Now for Hashemian devil it must be but 00:36:56.281,00:36:59.884 ya know for the rest of them you might be surprised if the it's 00:36:59.884,00:37:05.156 um if it’s like that or not if it’s vulnerable. So it is also 00:37:05.156,00:37:08.660 searchable on the Google Play just uh quad root a scanner. So 00:37:08.660,00:37:13.665 um thank you very much and I hope you enjoyed the 00:37:17.235,00:37:22.240 presentation [applause] and [applause]. So we have like 5 00:37:24.409,00:37:27.178 how many how much time? Like we have like [inaudible voices] so 00:37:27.178,00:37:30.515 we have like 5 10 minutes for Q and A so if you wanna if you 00:37:30.515,00:37:35.520 have a question just uh Q in front of the microphone and ask 00:37:43.928,00:37:45.697 [inaudible voices] >>How many devices do you think are 00:37:45.697,00:37:48.533 affected by these vulnerabilities? >>So the 00:37:48.533,00:37:51.503 question was how many devices are affected by this 00:37:51.503,00:37:56.174 vulnerability by these vulnerabilities. So a few 00:37:56.174,00:38:01.946 hundreds of millions I think lout about 700 800 millions more 00:38:01.946,00:38:06.951 or less. No small number. [laughter] [applause] >>hey 00:38:11.723,00:38:14.759 awesome work. I was wondering if you’ve looked into any of the 00:38:14.759,00:38:18.596 Qualcomm OS’ like the radio OS RPMB uh [inaudible words] >>can 00:38:18.596,00:38:22.300 can you repeat that I couldn't’ hear you very very well >>a 00:38:22.300,00:38:25.270 little louder >>hey I was wondering if you’ve looked into 00:38:25.270,00:38:29.107 any of the uh Qualcomm other OS’ that run on your device and non 00:38:29.107,00:38:34.112 Linux OS’ like RPMB, uh uh TZ uh or any of the non Linux stuff 00:38:38.349,00:38:44.989 that’s running >>I. Okay uh ya we actually we weren’t sure 00:38:44.989,00:38:49.694 about it but since for example um Qual uh the Android 00:38:49.694,00:38:52.931 [indiscernible] like the watch. Since they also use the same 00:38:52.931,00:38:56.701 okay for at least for Qualcomm since it’s not arch based just 00:38:56.701,00:39:01.606 logical code I mean not logical but it’s not based on the CPU um 00:39:01.606,00:39:05.009 we do believe that it might be vulnerable we did not check that 00:39:05.009,00:39:10.148 though so you’re welcome to do that. Ya. >>Hi uh on the 00:39:10.148,00:39:13.518 demonstration I noticed the security patch string was from 00:39:13.518,00:39:17.088 October of 20 15 is there a reason you didn’t demonstrate 00:39:17.088,00:39:21.993 against the latest version? >>Um not really uh we discovered it 00:39:21.993,00:39:25.730 back in like January and that’s the device uh january or 00:39:25.730,00:39:29.634 february so that’s the device that’s like we just took it from 00:39:29.634,00:39:35.640 this set 8 but um there’s no reason for that I mean on the 00:39:35.640,00:39:42.013 latest versions uh Google did deploy a sec- SE linux uh world 00:39:42.013,00:39:46.184 dot plugs access to the Qualcomm IPC but you can just you you can 00:39:46.184,00:39:49.787 I mean if you disable SE linux so it’s exploitable and it is 00:39:49.787,00:39:53.391 indeed vulnerable. I mean the devices did not receive a patch 00:39:53.391,00:39:59.797 yet. >>Uh did you get trust on access at all through >>okay so 00:39:59.797,00:40:05.536 um once your root you can you have access to the uh trust uh 00:40:05.536,00:40:09.674 trust uh mechanism this vulnerability is however in the 00:40:09.674,00:40:14.212 uns un un unsecure kernel uh context and therefore it does 00:40:14.212,00:40:17.015 not give you access to the trustzone kernel. However you 00:40:17.015,00:40:21.619 can exploit previously disclosed vulnerabilities to achieve this 00:40:21.619,00:40:25.790 uh uh code execution in trust zone level as seen on all the 00:40:25.790,00:40:29.894 research uh uh the research on the internet. >>Cool cheers. 00:40:29.894,00:40:34.899 >>Um other questions? Um thank you [applause]