00:00:01.802,00:00:06.773 >> Uh, Hello hello hello hello, and uh uh I believe the talk is 00:00:06.773,00:00:12.446 beginning very soon and uh my name is Qidan and here my handle 00:00:12.446,00:00:16.550 at flanker_hqd and uh here my colleague, Marco Grassi. Uh now 00:00:16.550,00:00:21.955 we are delivering a talk on the sandboxes and uh how do you 00:00:21.955,00:00:27.828 escape from the chrome sandbox and uh the safari sandbox. And 00:00:27.828,00:00:33.000 how to uh have a good overview of what the sandbox is. And uh 00:00:33.000,00:00:37.938 so… let's get start… let's get started and uh here the 00:00:37.938,00:00:41.742 introductions. [Indiscernible] >> Uh so I'm uh Marco ever.. 00:00:41.742,00:00:46.613 everyone and uh I'm currently a senior security researcher at uh 00:00:46.613,00:00:50.150 Keen Lab of Tencent. The, my main focus is uh vulnerability 00:00:50.150,00:00:57.090 research especially on uh OS X, IOS and the Android. >> Uh and 00:00:57.090,00:01:01.995 also uh uh same title, I not repeat it. And uh, main, uh my 00:01:01.995,00:01:05.799 main focus is bug hunting and exploiting on uh linux and also 00:01:05.799,00:01:12.572 linux and uh another linux like uh platform like Apple stuff. 00:01:12.572,00:01:16.577 And uh to be honest I know nothing about Windows. 00:01:16.577,00:01:23.717 [Laughter] [Clapping] Thank you. >> Thank you. >> And uh for our 00:01:23.717,00:01:27.888 team, we are previously known as the Keen Team and uh uh Keen 00:01:27.888,00:01:31.792 Team is uh Pwn2Own frequent winner and we've been like 00:01:31.792,00:01:35.929 [indiscernible] champions in five or four years. And uh uh do 00:01:35.929,00:01:39.533 to some business issues,we moved into Tencent and we are now a 00:01:39.533,00:01:44.738 deep research lab. Of the Tencent [indiscernible[ or 00:01:44.738,00:01:48.942 whatever it receives. And uh in this year, the March of this 00:01:48.942,00:01:52.946 year we got a Master title uh with the with the Tencent PC 00:01:52.946,00:01:57.317 manager and uh I believe this is the first time that we let the 00:01:57.317,00:02:02.589 Koreans go home and just to tease them. [Laughter] Okay so 00:02:02.589,00:02:07.294 here is the agenda Uh as I have stated before, we are going to 00:02:07.294,00:02:10.864 introduction to sandboxes. The Safari sandbox on the Apple 00:02:10.864,00:02:14.835 platform and the Google Chrome sandbox on the Android platform. 00:02:14.835,00:02:19.272 And uh we do a comparison and uh auditing the sandboxes and uh uh 00:02:19.272,00:02:22.743 how do you do auditing, where you should look at and the give 00:02:22.743,00:02:25.846 some histories from some historical vulnerabilities and 00:02:25.846,00:02:30.250 some vulnerabilities we use in this years Pwn2Own. And also at 00:02:30.250,00:02:35.155 the end of this talk we were like two demos of escaping the 00:02:35.155,00:02:41.194 safari sandboxes and uh uh actually we should present like 00:02:41.194,00:02:45.799 a chrome demo but uh we would hope to receiver for this years… 00:02:45.799,00:02:50.003 [Cough] [Indiscernible] Forgive me, and uh uh finally we will 00:02:50.003,00:02:53.407 get through the summary and conclusions. Okay first. >> 00:02:53.407,00:02:58.345 Okay, so uh we will start with a quick introduction to what 00:02:58.345,00:03:05.118 sandbox are. So what is a sandbox, uh a sandbox is a very 00:03:05.118,00:03:08.722 important concept in an operating system for security. 00:03:08.722,00:03:14.961 So basically a sandbox is uh um mechanism uh a way to run some 00:03:14.961,00:03:18.732 code that you don't trust it too much. An in a constrained 00:03:18.732,00:03:23.970 environment and so in this way if something goes wrong inside 00:03:23.970,00:03:27.641 of this code and uh your an attacker get for example, code 00:03:27.641,00:03:31.711 execution inside of this code um the system is not totally 00:03:31.711,00:03:35.549 compromised and that refs are still restricted inside of the 00:03:35.549,00:03:39.986 sandbox. So uh a sandbox specify which resource this particular 00:03:39.986,00:03:47.994 uh program uh piece of code it have access to. Um so uh I think 00:03:47.994,00:03:51.465 it became a crucial component for security in the last uh few 00:03:51.465,00:03:56.036 years uh after people started noticing that it's impossible to 00:03:56.036,00:04:00.407 uh get rid of all all the box especially in a very complex 00:04:00.407,00:04:06.213 code like web key uh and web page renderers and chrome and uh 00:04:06.213,00:04:10.450 document parser. So it become, became very clear that uh uh the 00:04:10.450,00:04:15.622 defense in depth approach must be taken. >> Because the 00:04:15.622,00:04:18.792 prowlers are a collection of use after free [indiscernible] 00:04:18.792,00:04:25.632 manage to work on html. [Laughter] >> And uh so um uh 00:04:25.632,00:04:30.704 now uh in modern uh software they're choosing strategies. The 00:04:30.704,00:04:34.241 first one obviously to fix bugs but also the second one is to 00:04:34.241,00:04:41.715 constrain the uh untrusted uh code inside of sandbox. So uh 00:04:41.715,00:04:46.953 let's take a look at a couple of uh sandbox implementations and 00:04:46.953,00:04:50.157 uh flanker will give you a intro hmmm introduction to the 00:04:50.157,00:04:53.894 implementation of sandbox on android. >> Uh I believe in the 00:04:53.894,00:04:58.431 historical years, uh people tend to adopt ideas in control that's 00:04:58.431,00:05:02.536 uh at the beginning of android I believe they fact back in 2010 00:05:02.536,00:05:08.008 or 2009 when Android was uh emerging a boy in a small 00:05:08.008,00:05:13.079 company. And uh it first adopted a deep DSA, DSA control and the 00:05:13.079,00:05:17.751 is just the first in its kernel. And the initial original Android 00:05:17.751,00:05:23.323 uh in each application runs and in a unique UID and uh uh the 00:05:23.323,00:05:27.460 kernel will enforces like uh fire XS across even the UIDs 00:05:27.460,00:05:31.131 pick halfway dongle. Uh application with UID uh normally 00:05:31.131,00:05:37.003 can not access uh uh a fires in this UIDB and uh so unless the 00:05:37.003,00:05:41.208 application B smartifies a word readable. Um for this for this 00:05:41.208,00:05:45.612 virus. And uh as with [indiscernible] they can 00:05:45.612,00:05:49.049 understand and linux beginners have a good understanding of the 00:05:49.049,00:05:52.485 U… [indiscernible] DSA control. That's uh you cannot access 00:05:52.485,00:05:55.722 another user with those files. And the android each application 00:05:55.722,00:05:59.659 is the user and uh of course there's an exception that is 00:05:59.659,00:06:03.029 called a shared UID format uh and I believe this is some 00:06:03.029,00:06:07.934 special cases where you consider but in general each application 00:06:07.934,00:06:10.870 have a different UID and this forces file access and other 00:06:10.870,00:06:15.242 access. And also, Android also implements some access controls 00:06:15.242,00:06:19.346 on network and uh you have to [indiscernible] a specific group 00:06:19.346,00:06:23.917 ID in order to access the network as a camera to access 00:06:23.917,00:06:27.854 because some [indiscernible] drivers or whatever. Uh so in 00:06:27.854,00:06:31.558 conclusion the DSA format is uh very easy to understand uh but 00:06:31.558,00:06:37.330 it has been proven to be unfixable. To uh to deal with 00:06:37.330,00:06:40.267 modern attacks on [indiscernible]. Attackers are 00:06:40.267,00:06:43.003 becoming clearer and clearer and are finding more and more bugs. 00:06:43.003,00:06:45.805 So peopler are using the mandatory access control. The 00:06:45.805,00:06:53.680 [indiscernible] control is originated by the 00:06:53.680,00:06:57.917 [indiscernible] and believed it was Snowden who did that. And uh 00:06:57.917,00:06:59.352 it's the originally found in the NSA labs and the some people 00:06:59.352,00:07:02.088 adapted to [Indiscernible[ Android and after like Android 00:07:02.088,00:07:06.660 photos three, it is introduced in the mainstream of Android. 00:07:06.660,00:07:09.929 And this give you some the other atlas give you a chance. But you 00:07:09.929,00:07:13.600 can define your own resources. Uh oh define your own policy 00:07:13.600,00:07:16.703 resources. And uh you can enforce um a whether of 00:07:16.703,00:07:21.107 resources excited the policy can check and they can chose the 00:07:21.107,00:07:27.781 driver kernel that uh uh you should access it so somebody 00:07:27.781,00:07:32.352 should access it or they should not and the only after this 00:07:32.352,00:07:37.757 approach is taken, and if the MSA rejects you and you have no 00:07:37.757,00:07:43.830 chance to fail it's the TSA. And uh also it uh [indiscernible] 00:07:43.830,00:07:46.733 provides some more [indiscernible] and elegant ways 00:07:46.733,00:07:50.970 you can define your own SE Linux policies so that you can give a 00:07:50.970,00:07:54.140 more find grand control of what you can do and what somebody can 00:07:54.140,00:07:59.946 do and what somebody can not. But it is becoming more and more 00:07:59.946,00:08:03.717 complex. Google continues to increase the code bases for this 00:08:03.717,00:08:11.858 access style and uh it somehow become difficult to understand 00:08:11.858,00:08:13.426 and thats how we also are delivering delivering this talk. 00:08:13.426,00:08:17.597 and I believe in OS X the sandboxes are also takes the MSA 00:08:17.597,00:08:21.434 approach format he very beginning of the OS X and some 00:08:21.434,00:08:25.338 earlier like ten dot seven version of OSX. So I turn the 00:08:25.338,00:08:29.509 mic over. >> So, now that Flanker gave an overview of 00:08:29.509,00:08:34.581 Android Sandbox we will check out the OS X sandbox for the 00:08:34.581,00:08:38.351 browser. UH just to give you another example, so we can 00:08:38.351,00:08:42.555 compare the two approach. So this is the structure of the 00:08:42.555,00:08:46.793 Safari sandbox. Uh basically that's the Safari browser is uh 00:08:46.793,00:08:51.865 split into multiple processes and um hmmm this is because to 00:08:51.865,00:08:56.770 to separate uh responsibility and components and to segregate 00:08:56.770,00:09:02.008 entrusted code in a less privileged process. So for our 00:09:02.008,00:09:06.346 purposes we can just uh think that there are two main process, 00:09:06.346,00:09:10.116 in reality there are more but but to simplify it's okay. Uh 00:09:10.116,00:09:14.587 one is the UI process which is the one which the user interact 00:09:14.587,00:09:19.692 on. Where uh you click the bottom and go back and input url 00:09:19.692,00:09:23.563 and the second one is in the background and it's the web 00:09:23.563,00:09:28.134 process and uh it's the process responsible for rendering your 00:09:28.134,00:09:33.373 uh webpage and the handling uh untrusted uh imputes such as 00:09:33.373,00:09:39.145 JavaScript and HTML and the images. So Um as you can 00:09:39.145,00:09:43.950 understand and the the, the web processes the one that is 00:09:43.950,00:09:48.221 handling the most or the biggest part of untrusted content and 00:09:48.221,00:09:53.426 the the UI process is just in charge to manage uh uh the other 00:09:53.426,00:10:00.233 process of of the browser. So like I said uh the web content 00:10:00.233,00:10:04.237 processes uh in response to uh his responsible to handle the uh 00:10:04.237,00:10:08.441 uh uh untrusted input and to render this untrusted input into 00:10:08.441,00:10:13.213 our webpage essentially. So usually a browser uh 00:10:13.213,00:10:16.749 confirmation like when you get initial cod execution inside of 00:10:16.749,00:10:20.286 the browser, you get insides this web contents browser 00:10:20.286,00:10:24.557 because maybe you have a JavaScript bug or maybe some 00:10:24.557,00:10:28.328 rendering bug or something like that you usually um get get it 00:10:28.328,00:10:33.466 here uh but uh this process have a very strict sandbox so what 00:10:33.466,00:10:36.536 you need to do after to compromise the system is to 00:10:36.536,00:10:41.941 escape the sandbox. And uh one attack surface for sandbox is 00:10:41.941,00:10:47.313 the broker interface which is used from the web process to 00:10:47.313,00:10:50.950 communicate with the UI process because for example maybe the 00:10:50.950,00:10:56.523 web browser must open a file but it cannot do it itself. Uh it 00:10:56.523,00:11:01.127 must ask the broker uh to do it through the UI process because 00:11:01.127,00:11:08.034 the web browser is too much sandbox to do it. Oh, the web 00:11:08.034,00:11:12.238 content uh uh sandbox is implemented like any other OS X 00:11:12.238,00:11:16.843 sandbox uh profile, and uh hmm it's leverage [indiscernible[ 00:11:16.843,00:11:21.648 driver which is a sandbox dot kept and the there are some 00:11:21.648,00:11:26.452 files like on Android you have a SE linux profile also in uh in 00:11:26.452,00:11:31.157 uh an… OS X you have uh a sandbox definition file and uh 00:11:31.157,00:11:34.861 for example for a browser uh render you can find it at find 00:11:34.861,00:11:40.066 it at this spot. And uh how it works basically this file 00:11:40.066,00:11:44.037 defines uh what are your capabilities. And uh whenever 00:11:44.037,00:11:49.042 you're you're uh your code execute as system call or 00:11:49.042,00:11:52.345 something like that the kernel will uh check will have will 00:11:52.345,00:11:55.682 have some callback inside of this system call some hooks and 00:11:55.682,00:12:00.853 uh then it will uh ask the sandbox uh driver to have 00:12:00.853,00:12:04.657 evaluate your sandbox profile and uh it will say to you yes 00:12:04.657,00:12:10.196 you are allowed not, you are not. So, let's take a look how 00:12:10.196,00:12:14.801 how a sandbox profile looks like. Uh as you can see here, we 00:12:14.801,00:12:20.707 have uh first uh first uh a very simple snippet. It it's uh 00:12:20.707,00:12:24.877 written in this custom language uh very simple to understand 00:12:24.877,00:12:29.916 very human readable and uh as you can see hmm here there's a 00:12:29.916,00:12:33.987 denied default rule so uh if you are under this sandbox uh 00:12:33.987,00:12:38.958 profile uh everything for you is denied. UH except some uh 00:12:38.958,00:12:43.229 whitelist will uh come after in the file um as you can see after 00:12:43.229,00:12:49.936 uh another sandbox profile is imported, system dot SB so you 00:12:49.936,00:12:55.108 need to follow into this include uh also to audit the sandbox 00:12:55.108,00:13:01.014 profile. Uh recently on OS X there is also another uh 00:13:01.014,00:13:04.884 addition that it worth mentioning it's a system 00:13:04.884,00:13:11.024 targeted protection. Um so basically on OS X the if you 00:13:11.024,00:13:14.794 don't pit in for the sandbox you are you are not sand boxed in 00:13:14.794,00:13:19.098 but now with the system integrity protection in the 00:13:19.098,00:13:23.703 recent version of OS X, uh every process, even the one running as 00:13:23.703,00:13:29.375 root is running inside the uh global system sandbox. So, it's 00:13:29.375,00:13:33.146 a new security mitigation so uh even if you have uh root code 00:13:33.146,00:13:38.985 execution in use of space, there are still some still some 00:13:38.985,00:13:42.955 operation you can not do. As you can se here, I'm running a touch 00:13:42.955,00:13:48.428 command as uh as a root, it's sudo but I cannot write into the 00:13:48.428,00:13:51.764 system partition. This is because there is the system 00:13:51.764,00:13:57.670 integrity protection um.. uh avoid in this. So how can you 00:13:57.670,00:14:02.508 bypass this? Uh well the best option for an attacker is to 00:14:02.508,00:14:05.845 find kernel back because the system integrity protection is 00:14:05.845,00:14:09.248 enforce it inside the kernel so if you have a kernel code 00:14:09.248,00:14:13.119 execution you can also bypass system integrity protection. Um 00:14:13.119,00:14:18.624 as we would see later in our demo. >> So as you can see with 00:14:18.624,00:14:23.763 the sandboxes like SP after they are introduced uh even the root 00:14:23.763,00:14:28.501 uh model is restricted and you can not say to the sudo make me 00:14:28.501,00:14:36.142 a sandwich, no I won't make you a sandwich. [Laughter] So now uh 00:14:36.142,00:14:40.813 let's move to the uh Android Google stuff and uh, uhh there a 00:14:40.813,00:14:44.016 big difference between Android and IOS like, IOS uh almost 00:14:44.016,00:14:50.123 every application in the sandbox by default but in in like uh 00:14:50.123,00:14:53.626 Google, Google format, they usually need to opt in and use 00:14:53.626,00:14:57.430 the isolated process feature to to handle a sandbox in your own 00:14:57.430,00:15:02.301 process. And uh Chrome leverages this isolated prices feature and 00:15:02.301,00:15:06.706 implement his own sandbox and we can kind of see in this android 00:15:06.706,00:15:11.544 uh Android, manifest dot XM .. XML file. And with the isolated 00:15:11.544,00:15:15.915 process uh equals true and that means that this service this org 00:15:15.915,00:15:19.752 dot chrome dot IPV dot sim was a process service in which you run 00:15:19.752,00:15:25.158 the V8 and javascript engine. Uh it is isolated and it has some 00:15:25.158,00:15:29.095 uh some different future… features and uh there is uh 00:15:29.095,00:15:32.632 actually very small and even no privileges for this 00:15:32.632,00:15:37.170 process.[indiscernible] that isolated process will introduce 00:15:37.170,00:15:42.208 android and uh for those three and uh in the official talk 00:15:42.208,00:15:44.877 documentation we have a safe data. If it's that's true the 00:15:44.877,00:15:49.415 service will run special process that is from the rest of the 00:15:49.415,00:15:54.387 system. And no permission of it's own. And uh given like a PS 00:15:54.387,00:15:59.892 uh in.. output we can see that the chrome is splitted into 00:15:59.892,00:16:05.531 three processes and uh they are tool uh like uh a normal process 00:16:05.531,00:16:09.168 but there is the one called sandboxed uh process and we have 00:16:09.168,00:16:15.241 see that it has an UID that is user I zero which means the ISO 00:16:15.241,00:16:18.845 is processed as zero and uh have it isolated context that has 00:16:18.845,00:16:25.084 isolated APP label. So even if you go back in the wait uh wait 00:16:25.084,00:16:30.089 java ranging and uh you only get a code execution in this uh 00:16:30.089,00:16:34.293 isolated process you need to find some way to escape the 00:16:34.293,00:16:39.565 sandbox otherwise you can not rate the weak teams phone SMS 00:16:39.565,00:16:43.069 you can not reason because uh the render process has no 00:16:43.069,00:16:47.907 courage and uh you can use like a kernel exploit like the 00:16:47.907,00:16:51.978 pingpong root uh to to break out the sandbox and also you can use 00:16:51.978,00:16:55.748 the broker exploit and uh also some other attack services in 00:16:55.748,00:17:00.219 Android like the binder and the we will will introduce later. Uh 00:17:00.219,00:17:03.456 first uh you want to find the way to figure out how big 00:17:03.456,00:17:07.226 sandbox is you need to check its isolation policy and uh and know 00:17:07.226,00:17:13.699 it is named isolated_app dot te. In the internal policy. Android 00:17:13.699,00:17:17.870 open source projects uh source root and uh actually to be 00:17:17.870,00:17:21.774 honest the iSynch is not as readable as the apple ones. And 00:17:21.774,00:17:25.211 uh yeah you can see uh first that you have like uh uh a 00:17:25.211,00:17:29.615 domain park that uh the domain is a step to isolate the app 00:17:29.615,00:17:33.986 isolated process and then uh there are some allowed. By 00:17:33.986,00:17:38.424 default you are denied for all you have some a lot of things 00:17:38.424,00:17:42.128 and you also have uh like a father policy you inherit it 00:17:42.128,00:17:45.865 from. Um though for some for some a lot of persons will 00:17:45.865,00:17:49.101 consider there are only tho isolated services or two system 00:17:49.101,00:17:52.805 sources that you can [indiscernible] from the uh from 00:17:52.805,00:17:55.541 the isolated process uh which is the activity min.. activity 00:17:55.541,00:17:58.844 service and the display service. Um you can say some unprivileged 00:17:58.844,00:18:03.883 [indiscernible] controls. Uh but you can not use uh because after 00:18:03.883,00:18:07.320 ping pong root, google introduced its new policy to 00:18:07.320,00:18:11.490 deny, to deny you from exporting this java circuit box. And uh, 00:18:11.490,00:18:15.661 and there are also some never allows. Some never allows it 00:18:15.661,00:18:20.666 actually not a statement in action it's actually like a 00:18:20.666,00:18:24.971 compil.. compiler directive. Which means if you accidentally 00:18:24.971,00:18:29.976 enabled this scenes in your policy files, isolating two 00:18:29.976,00:18:33.279 comparing two generator, generate an error and the 00:18:33.279,00:18:37.283 delivery to compare it. So you can see that uh they have some 00:18:37.283,00:18:41.754 most of frequency to deny the previous errors so they have a 00:18:41.754,00:18:46.826 how make and the we'll see it later. And uh uh I know we 00:18:46.826,00:18:49.862 don't, the graphic drivers have many bugs about the 00:18:49.862,00:18:52.965 [indiscernible] the… specified that you cannot access driver 00:18:52.965,00:18:57.103 from this [indiscernible] process. But uh, uh you make 00:18:57.103,00:19:01.340 think that uh that there are two services like activity service 00:19:01.340,00:19:05.011 and uh display service. Uh you may access all the service, of 00:19:05.011,00:19:09.048 all the interfaces of that two services. The answer is no. 00:19:09.048,00:19:13.619 Because there is an additional check in this uh service enabled 00:19:13.619,00:19:16.756 interfaces, they are like enforced not isolated color and 00:19:16.756,00:19:19.392 uh it will actually use the bundles feature to get the 00:19:19.392,00:19:23.562 color. The who, who initially initialized this bundle 00:19:23.562,00:19:28.834 [indiscernible] and uh they will retrieve the user id that uh 00:19:28.834,00:19:32.538 makes this call and uh checks… you are isolated, oh you are 00:19:32.538,00:19:35.875 labeled, I'm sorry you cannot perform it and also uh they have 00:19:35.875,00:19:39.945 like a father policy like a [indiscernible] domain that is 00:19:39.945,00:19:44.116 not actually quite interests and we made it enough for these 00:19:44.116,00:19:48.154 slides. So let's turn to the you have a brief overview of the how 00:19:48.154,00:19:51.323 sandbox implemented and where you can look intuit he policy 00:19:51.323,00:19:54.627 files and now let's see how to audit the sandbox profile to 00:19:54.627,00:19:59.765 find the possible attack services. >> So, [clears throat] 00:19:59.765,00:20:04.303 how do we audit a sandbox profile? Well the first thing to 00:20:04.303,00:20:07.440 do is obviously is to read the definition of the sandbox 00:20:07.440,00:20:13.479 profile in order to find the the best attack surfaces uh so let's 00:20:13.479,00:20:18.350 try to do this on the the process. The the process.. the 00:20:18.350,00:20:25.024 web process uh uh of safari browser. So um as I show you 00:20:25.024,00:20:28.861 before, there is a deny default disclose but uh shortly after 00:20:28.861,00:20:33.365 there is an import of system dot sb. So we need to check that as 00:20:33.365,00:20:38.504 well. And uh inside the system dot sb there is uh nice 00:20:38.504,00:20:43.809 surprise. Uh as you can see uh it's a define uh something 00:20:43.809,00:20:50.249 called system graphics so we need to check that also. So 00:20:50.249,00:20:54.687 system graphic is defined right here and uh it entitle you to 00:20:54.687,00:20:59.625 open several IO… IOkit user client uh all related to 00:20:59.625,00:21:05.464 graphics. So basically on OS X uh uh the browser the the 00:21:05.464,00:21:11.770 renderer process of the browser, unrestrained and uh the access 00:21:11.770,00:21:16.609 to uh all kernel driver in the interfaces which is very good 00:21:16.609,00:21:20.713 because uh compare it to Android which you can not access, 00:21:20.713,00:21:25.784 instead here on IS… OS X we can access directly the graphic 00:21:25.784,00:21:30.089 drivers which is a really good attack surface and uh hopefully 00:21:30.089,00:21:35.761 we can find some bugs. So uh let's pick this attack surface 00:21:35.761,00:21:42.668 of uh graphics in kernel. So in our sandbox profile uh this line 00:21:42.668,00:21:49.775 is uh very interesting which is uh allow, allow-iokit-open of 00:21:49.775,00:21:53.379 IOAccelerator. IO Accelerator is um uh the graphic driver 00:21:53.379,00:21:58.317 interface into the kernel. And uh uh with this uh property in 00:21:58.317,00:22:02.855 our sandbox profile we can open more than ten iokit user clients 00:22:02.855,00:22:07.660 and speak to the kernel hoping to trigger some back. >> Because 00:22:07.660,00:22:10.930 people like a fancy graphics, they're brothers, so Apple had 00:22:10.930,00:22:13.933 to make decision to all these graphics. >> Yeah, for for uh 00:22:13.933,00:22:17.102 performance also really. >> But really tough. >> Yeah. [Laugh] 00:22:17.102,00:22:23.209 SO hm let's see an example of vulnerability. Uh this 00:22:23.209,00:22:28.013 vulnerability uh we found we found it last year, and we 00:22:28.013,00:22:32.017 wanted to use it in the Pwn2Own but uh unfortunately for us uh 00:22:32.017,00:22:36.722 we got a bug collision and this vulnerability was also found by 00:22:36.722,00:22:41.827 Project Zero which reported it before we would use it at 00:22:41.827,00:22:46.432 Pwn2Own. SO uh this bug was a race condition inside uh 00:22:46.432,00:22:51.470 external method of AppleIntelBWGraphics which is um 00:22:51.470,00:22:59.445 a graphic driver of almost all the uh most recent MacBooks so 00:22:59.445,00:23:05.084 it affects every recent macbook with this particular CPU family 00:23:05.084,00:23:08.854 which is the newest one available for Apple products. UH 00:23:08.854,00:23:13.759 we found it by code auditing uh of this code uh reachable from 00:23:13.759,00:23:20.699 the safari sandbox. Um it was patched in uh ten dot eleven dot 00:23:20.699,00:23:25.371 four and it was reliably exploitable. So, it was a cool 00:23:25.371,00:23:30.709 bug but uh like we said it got uh fixed before we could use it. 00:23:30.709,00:23:37.016 And uh it's also funny because uh Apple uh uh fixed it wrongly 00:23:37.016,00:23:42.187 and uh Flanker reported this mistake so now the bug is 00:23:42.187,00:23:45.758 properly fixed. >> Uh you know previously, just I believe for 00:23:45.758,00:23:49.795 the day before yesterday, Apple get free bugs from everyone. And 00:23:49.795,00:23:55.167 uh so actually they lose track over this report uh although 00:23:55.167,00:23:58.270 they have fixed it and I write and email to them and maybe 00:23:58.270,00:24:01.140 after one months or two months I think they will say oh I'm 00:24:01.140,00:24:05.778 sorry, you lose track of it and uh oh I hope that after they pay 00:24:05.778,00:24:09.748 bounties to everyone they will become, uh they will have a more 00:24:09.748,00:24:16.989 like uh better attitude. In 06. >> [Clears throat.] So uh, so 00:24:16.989,00:24:20.259 this bug works, very very quickly. Uh there is this uh 00:24:20.259,00:24:26.465 chew uh user client uh which uh relates to open GL and open CL 00:24:26.465,00:24:32.604 that which can be used from sandbox. And the problem is that 00:24:32.604,00:24:38.711 uh who wrote this driver didn't think about race condition 00:24:38.711,00:24:42.948 problems so we have some uh some race condition problems inside 00:24:42.948,00:24:48.487 the map user memory. So as you can see here there are some 00:24:48.487,00:24:52.524 operation performed on EG hash table inside this external 00:24:52.524,00:24:58.464 method but uh as you can see the method on this EG hash table 00:24:58.464,00:25:03.902 they are called a three different method in in uh 00:25:03.902,00:25:08.540 sequentially. But uh the lock is acquired after. So what happen 00:25:08.540,00:25:14.213 if two threats are racing inside this function? Of course race 00:25:14.213,00:25:19.451 condition is triggered. SO how to trigger it? Well it's actual 00:25:19.451,00:25:24.823 very simple to just trigger this but not so simple to exploit it 00:25:24.823,00:25:29.428 like uh we will see. Uh in order to trigger it you'll just have 00:25:29.428,00:25:34.166 to open this user client and uh call uh one time or more than 00:25:34.166,00:25:38.804 one um up user memory to insert uh one element inside uh the 00:25:38.804,00:25:43.509 hash table and then you have to try to race with the two threads 00:25:43.509,00:25:48.113 that call inside the unmap user memory and then you have to 00:25:48.113,00:25:54.920 repeat this map in the map race till you trigger the bug. Uh at 00:25:54.920,00:26:01.160 first the bug will manifest itself uh like a double free but 00:26:01.160,00:26:06.765 as we can see after we can turn it to something more useful. >> 00:26:06.765,00:26:10.903 Okay now, I get a record of the elective structure classes in 00:26:10.903,00:26:16.008 universities or high schools if you are a genius. And uh let's 00:26:16.008,00:26:20.679 look at this list and actually we know that we will call memory 00:26:20.679,00:26:24.616 to memory to uh your input is maintained as a link list and uh 00:26:24.616,00:26:28.720 hashed and the link list is also linked to hash table because you 00:26:28.720,00:26:32.624 know that we use a hash table, there are hash collision issues. 00:26:32.624,00:26:35.327 This data structure has solved this problem by maintaining a 00:26:35.327,00:26:38.931 list on the colleague data elements. So we actually have 00:26:38.931,00:26:42.134 like a IG Element uh link them uh here and from here that uh 00:26:42.134,00:26:47.806 our elements have a pervious pointer point to it uh he's like 00:26:47.806,00:26:51.577 a brother, and uh he uh also has a nest. A nest pointer points to 00:26:51.577,00:26:54.780 his next brother. And so the ideal situation that we 00:26:54.780,00:26:58.684 originate imagine that we risk the threads is if we pass the 00:26:58.684,00:27:03.388 hash tables contains check and when one is retrieving a pointer 00:27:03.388,00:27:07.459 from this IG element the other will if the frees it and we can 00:27:07.459,00:27:12.331 feel something in this free element then the RP control to 00:27:12.331,00:27:15.467 get to the instruction point or control but uh in reality we do 00:27:15.467,00:27:19.238 some testing and we find that uh two [indiscernible] they do pass 00:27:19.238,00:27:23.575 , they do pass the contain code but the [indiscernible] is more 00:27:23.575,00:27:27.679 faster but maybe uh ten meters, ten meters per second faster 00:27:27.679,00:27:30.983 than the second stride. And UH maybe there's some schedule 00:27:30.983,00:27:34.753 policy you should with Apple and uh it with the second one we 00:27:34.753,00:27:37.422 remove, removed this element. For [indiscernible] for 00:27:37.422,00:27:40.425 [indiscernible] two get uh access to these elements and uh 00:27:40.425,00:27:43.962 stride two we unfortunately keep uh like a no pointer references 00:27:43.962,00:27:47.633 and the window that after Apple finally released the IFMVP you 00:27:47.633,00:27:52.638 can't uh you actually cannot [indiscernible] this with the 00:27:52.638,00:27:57.809 references on on their platforms. So actually uh after 00:27:57.809,00:28:02.714 some uh I believe I reconciled my destructive clauses and uh I 00:28:02.714,00:28:08.620 found that actually you can do a race on the tool on just the 00:28:08.620,00:28:10.255 elements because we know that if we remove an element from a link 00:28:10.255,00:28:14.426 list uh the next link to next element to this one which was 00:28:14.426,00:28:18.130 removed uh it will link to the previous element this one which 00:28:18.130,00:28:21.733 was removed uh it will link to the previous element to the one 00:28:21.733,00:28:23.368 to removed. So you can see that in this list we have element 00:28:23.368,00:28:24.970 one, two, three, four and if two, two is removed, one will 00:28:24.970,00:28:28.607 link to three and three is removed, it will relink to four 00:28:28.607,00:28:33.512 and we risked these two removes at the same time, we may get uh 00:28:33.512,00:28:38.550 one to three but three is also removed so we get a free element 00:28:38.550,00:28:43.388 that is stably connected in this link list. And after we call the 00:28:43.388,00:28:47.759 link to travel or so and we will hit this user free bug and uh we 00:28:47.759,00:28:51.797 turn this originally double freight like still like bug into 00:28:51.797,00:28:54.232 like a uf bug and this is like is much more stable. And uh huh, 00:28:54.232,00:29:00.505 [indiscernible] also found this bug it didn't figure out how to 00:29:00.505,00:29:04.376 exploit it. Uh at least on his blog post they were approaching 00:29:04.376,00:29:09.615 their issues and uh on our list Apple fixed it fixed it and they 00:29:09.615,00:29:13.685 add a log in this remove function but it would not add a 00:29:13.685,00:29:16.955 log in this add function. Um maybe they think there is no 00:29:16.955,00:29:21.994 issue here but actual we would like to say no to this because 00:29:21.994,00:29:24.696 if you do not lock the add function and also the unlock 00:29:24.696,00:29:28.700 function uh you can still, like we can still raise like the add 00:29:28.700,00:29:31.770 function and the remove function at the same time we can actually 00:29:31.770,00:29:37.009 get [indiscernible] link to get rid of that chaos. For example, 00:29:37.009,00:29:41.046 when we are inserting an element off of the link list because if 00:29:41.046,00:29:44.149 you know that you are inserting an element after this link list 00:29:44.149,00:29:48.987 it is get a pended to that tail of the current element. So we 00:29:48.987,00:29:53.091 can see that uh it is either an open element or will be uh added 00:29:53.091,00:29:57.396 to the element history like you have the element history and the 00:29:57.396,00:30:00.132 next pointer point to the element four. But if we are in 00:30:00.132,00:30:03.935 another stride, the race to remove element three, actually 00:30:03.935,00:30:07.372 you can get like a [indiscernible] address in the 00:30:07.372,00:30:10.208 free element and use some sort of like a memory function 00:30:10.208,00:30:13.945 technique to get to get out of this hit point address. In the 00:30:13.945,00:30:18.250 kernel contest. Yeah so this the partial [indiscernible] and we 00:30:18.250,00:30:24.322 disclosed example and uh I will fix again if if uh not there 00:30:24.322,00:30:28.393 should be no problem. And uh if you are more interested in the 00:30:28.393,00:30:31.997 more details, you can check out the slides if you are 00:30:31.997,00:30:36.702 interested. Okay now is enough time for the Apple stuff and now 00:30:36.702,00:30:41.039 look into the Android stuff. The Android. In the Android uh 00:30:41.039,00:30:46.411 platform that the application contest it is inherited from the 00:30:46.411,00:30:50.148 application policy. Application dot te policy and the 00:30:50.148,00:30:53.618 application dot te policy or it's the domain policy. A domain 00:30:53.618,00:30:58.623 policy they have some uh more like complex uh complex rules 00:30:58.623,00:31:03.128 and uh for example that uh in in the old domains you can you you 00:31:03.128,00:31:08.667 can allow process to fork to get some signal out to send signal, 00:31:08.667,00:31:10.936 to resist signal, but uh actually you know in our os 00:31:10.936,00:31:14.773 platform uh a container application is not allowed to 00:31:14.773,00:31:20.612 fork the android its allowed to fork. Uh in like the uh sounds 00:31:20.612,00:31:25.383 policy, application dot t policy uh we have some like uh 00:31:25.383,00:31:29.321 [indiscernible] but you can buy my portion of memory and make it 00:31:29.321,00:31:33.225 executable so that it can press it there to after you can 00:31:33.225,00:31:38.029 instruction pointer control. But this is uh not I believe this is 00:31:38.029,00:31:42.367 going to be this loud in this cylinder uh process.. they have 00:31:42.367,00:31:46.805 because they figured out some ways to by to make a giant te uh 00:31:46.805,00:31:50.976 modifications. Like the stuff that Apple does. Uh the day 00:31:50.976,00:31:55.413 before yesterday. So uh now we have done uh an understanding of 00:31:55.413,00:32:00.018 this sandbox policies and uh we have some some options. First, 00:32:00.018,00:32:03.488 the binder interface. We know that binder is the core of the 00:32:03.488,00:32:07.659 Android interprocess communication and uh although 00:32:07.659,00:32:11.263 the binder interfaces are strictly restricted in the 00:32:11.263,00:32:16.368 chrome sandbox we still have some some ways to figure out 00:32:16.368,00:32:20.772 sandbox and to to get some collocation. For example uh uh 00:32:20.772,00:32:26.578 in wait we have a bug actually I believe I found a bug uh 00:32:26.578,00:32:30.081 yesterday, uh last year by somebody that is sharing storage 00:32:30.081,00:32:33.118 in [indiscernible] overflow in the vector implementation of the 00:32:33.118,00:32:37.422 Android [indiscernible]. And uh peoples think that it's a like a 00:32:37.422,00:32:42.127 remote uh it is kind of triggered media fire pausing but 00:32:42.127,00:32:45.030 actually it can also be triggered in sandboxes because I 00:32:45.030,00:32:48.433 know that particle.. and particle which is basically a 00:32:48.433,00:32:53.839 unit in the binder interfaces at the Java level you can specify a 00:32:53.839,00:32:57.709 class name at the string and in the java code and when the java 00:32:57.709,00:33:01.780 object is destabilized uh uh class based on this string name 00:33:01.780,00:33:05.884 is constructed and you actually have additional pass to trigger 00:33:05.884,00:33:10.722 the deserialization in code in the system server contest. I 00:33:10.722,00:33:18.296 will… if you call the system, I recall the activity manager 00:33:18.296,00:33:20.632 services interface that are from not even the that is accessible 00:33:20.632,00:33:23.235 from the renderer sandboxes. And uh you like uh you make this 00:33:23.235,00:33:25.837 code. You make this deserialization code uh code in 00:33:25.837,00:33:29.307 the system server contest and the uh uh actually you can 00:33:29.307,00:33:32.878 trigger like the CVE 2015 and the 38 74, 75 I'm sorry, in the 00:33:32.878,00:33:40.018 system server contest. And also we believe that uh sometime they 00:33:40.018,00:33:43.989 forgot to do a more [indiscernible] lock down on 00:33:43.989,00:33:47.826 this binder interface. For example in this portion of code 00:33:47.826,00:33:52.063 we found that uh they uh uh accidentally placed a some more 00:33:52.063,00:33:56.368 serious handle like the package service handle, and the window 00:33:56.368,00:33:59.471 service handle and the alarm service handle, in this, this 00:33:59.471,00:34:03.475 [indiscernible] cost. So although the render process can 00:34:03.475,00:34:08.046 not open the services, uh uh this function can.. can open 00:34:08.046,00:34:12.117 these services already for them that to the the render sand.. 00:34:12.117,00:34:15.387 renderer… renderer sandbox process [indiscernible] handles 00:34:15.387,00:34:19.758 when it's initialized. So it actually it opens to like three 00:34:19.758,00:34:23.862 additional attack surfaces. Uh fortunately a bit of the Google 00:34:23.862,00:34:26.865 engineers are clever and they figured it very soon and theta 00:34:26.865,00:34:31.436 patched already unfortunately. So after this binder stuff, we 00:34:31.436,00:34:36.708 still have like uh some more like chrome IPC that you you you 00:34:36.708,00:34:40.712 know that Marco has introduced in the previous slide. Uh the 00:34:40.712,00:34:45.483 render process had to ask the broker process which is a more 00:34:45.483,00:34:48.820 British process to do something for it and they communicated uh 00:34:48.820,00:34:51.423 where are they uh using the chrome ipc. And the Chrome IPC 00:34:51.423,00:34:54.859 is implementing a native code that uh we and… that uh we 00:34:54.859,00:35:00.131 actually there are some bugs in it. And uh also in Android 00:35:00.131,00:35:03.969 platform, unlike the Windows ones, the geo process, running 00:35:03.969,00:35:07.038 the host process it is not running a separate process in 00:35:07.038,00:35:10.408 the chrome. Rather it is running the host process that is the 00:35:10.408,00:35:14.946 chrome process itself. So we have bug in the Web GL just like 00:35:14.946,00:35:19.384 I was look hard to on this year and last year, we can get uh 00:35:19.384,00:35:22.721 collocation in the GL process actually we get collocation as a 00:35:22.721,00:35:27.525 normal application in Android and uh you get much more contest 00:35:27.525,00:35:32.430 to to to to play with. And finally we also have some like a 00:35:32.430,00:35:37.035 kernel stuff just like what [indiscernible] in our 00:35:37.035,00:35:43.375 sandboxes? Uh if we dump all the CVE 2015 18 05 it's a bug that 00:35:43.375,00:35:48.480 is fully by us to gain a stable root. Stable root on android and 00:35:48.480,00:35:52.183 we tried to port it to the rendered sandboxes and uh there 00:35:52.183,00:35:55.687 are good news and bad news for us to exploit here in the 00:35:55.687,00:35:58.957 android sandbox. The good news is that there's no right policy, 00:35:58.957,00:36:02.293 you know that this bug is really to the pipe. [Indiscernible] 00:36:02.293,00:36:04.596 means kernel and there's no pipe policy in this application 00:36:04.596,00:36:08.733 because actually its like uh nobody believes that this bug is 00:36:08.733,00:36:12.237 avoidable so no policy for this bug in the isolation process. 00:36:12.237,00:36:16.574 And uh you can not uh find this like uh very fundamental 00:36:16.574,00:36:20.278 technique fundamental uh technique that got used by 00:36:20.278,00:36:23.782 almost every linux process. uh But I have to admit there are 00:36:23.782,00:36:30.221 still bad news because our exploration technique uh use 00:36:30.221,00:36:34.192 many send uh uh message cost to prepare the kernel memory but 00:36:34.192,00:36:37.429 unfortunately there were no.. sandboxes to use in a full video 00:36:37.429,00:36:39.731 to do so. So, but it force out to find some news way to uh to 00:36:39.731,00:36:43.568 exploit and uh [indiscernible] of this makes our life harder. 00:36:43.568,00:36:48.373 And also you know that even if you are clever you can't make a 00:36:48.373,00:36:51.109 sim conniver or some your neighbor also is clever because 00:36:51.109,00:36:53.745 they're winners. They auto [ indiscernible] to 00:36:53.745,00:36:56.014 [indiscernible]. They always in a hurry and either called nor 00:36:56.014,00:37:00.218 here nor there. And uh here is their in the Huawei uh phones 00:37:00.218,00:37:03.788 like uh how ext the service that is running the system server 00:37:03.788,00:37:07.125 contest and uh there is there there is a very obvious 00:37:07.125,00:37:11.896 [indiscernible] you can like uh get auto bars accessed, post 00:37:11.896,00:37:14.566 read and write and whatever you like. But uh you you realize 00:37:14.566,00:37:18.236 google of course are not aware of this kind of interfaces uh 00:37:18.236,00:37:21.606 but the windows themselves and windows do not modify their 00:37:21.606,00:37:25.210 linux policy to adjust the list so they're opening also new 00:37:25.210,00:37:28.913 interfaces for the attack. So let's go to the comparison part. 00:37:28.913,00:37:33.685 >> So [clears throat] we analyze the presentation of sandbox on 00:37:33.685,00:37:37.755 OS X and Android and now we want to do some comparison and uh 00:37:37.755,00:37:42.227 wrap up. And uh after this short comparison we will do uh quick 00:37:42.227,00:37:48.066 demo of uh our OS X code execution and uh remote uh 00:37:48.066,00:37:53.104 [indiscernible] execution. And uh after that we will just do 00:37:53.104,00:37:58.543 some uh very small conclusion and then we will conclude. So um 00:37:58.543,00:38:02.814 both platform share a lot actually. They both have a file 00:38:02.814,00:38:08.820 uh file based uh sandbox profile definition uh which you can 00:38:08.820,00:38:14.392 audit and uh but except from that we can feel that the 00:38:14.392,00:38:19.230 chromium sandbox android is stronger than the other platform 00:38:19.230,00:38:23.968 because it offer very small attack surface. And also in 00:38:23.968,00:38:28.006 Android the sandbox is more layered like first you have the 00:38:28.006,00:38:33.745 [clears throat] uh chrome se linux uh uh sorry the isolated 00:38:33.745,00:38:41.085 app uh se linux policy and uh then it’s running as uh um it uh 00:38:41.085,00:38:44.489 even if you escape this uh sandbox uh chrome is an 00:38:44.489,00:38:49.627 application so it’s restricted by the DAC sandbox so there are 00:38:49.627,00:38:56.234 quite a lot of layers you have to take into consideration. >> 00:38:56.234,00:38:59.571 So let’s go to demo and uh after the demo we go to the 00:38:59.571,00:39:04.742 conclusion. And uh we are presenting two demos for this 00:39:04.742,00:39:12.617 year Pwn2Own and uh one we exploit one in the uh uh OS X 00:39:12.617,00:39:19.857 uh… >> Yeah so the two demos are about two remote compression of 00:39:19.857,00:39:24.229 OS X one.. >> I can’t find my pointer. >> One is uh user 00:39:24.229,00:39:30.568 safari code execution bug and then a sandbox escape in user 00:39:30.568,00:39:36.374 space and the second one is uh safari render bug and uh sandbox 00:39:36.374,00:39:41.179 escape to kernel and uh in this demo you will see that uh the 00:39:41.179,00:39:45.316 victim inside the virtual machine will browser to our 00:39:45.316,00:39:49.787 website and uh then the attacker on the left will get a remote 00:39:49.787,00:39:56.661 root shell. >> Uh this, ten dot eleven dot three is a what we 00:39:56.661,00:40:04.702 exploited is the newest version at the time of the Pwn2Own.. So 00:40:04.702,00:40:37.468 first there’re like uh Javascript GSE. So you can see 00:40:37.468,00:40:42.407 on the left side attacker can remove the shell because… 00:40:42.407,00:40:45.877 because we are exploiting the Windows server which is 00:40:45.877,00:40:49.847 responsible for the graphics stuff of USB graphics stuff is 00:40:49.847,00:40:56.387 OSX. You can see the graphics has a free this in the victim 00:40:56.387,00:41:00.692 machine so we choose to get [indiscernible] out and connect 00:41:00.692,00:41:07.966 it in root shell. So this is our.. uh user mode exploit and 00:41:07.966,00:41:11.936 [indiscernible] uh you have got a useable root you but you can 00:41:11.936,00:41:15.707 not make make a sandwich for you. You still need a kernel 00:41:15.707,00:41:27.285 exploit. Also credit to Qoobee for making this. Uh there’s some 00:41:27.285,00:42:07.392 fancy music credit to Hans Semer. [Laughter] [Music 00:42:07.392,00:42:10.495 Playing] Uh an interesting observation that uh you cannot 00:42:10.495,00:42:13.564 add a user mode root to on calculator. You see that a sudo 00:42:13.564,00:42:17.468 calculator it will tell you uh uh it will not tell you no I 00:42:17.468,00:42:20.405 will [indiscernible] a calculator, it will say illegal 00:42:20.405,00:42:24.042 instruction. but as a kernel model you have actually a spawn 00:42:24.042,00:42:27.745 user mode a spawn user mode for calculators. So if you see like 00:42:27.745,00:42:31.916 a kernel.. like a root uh UID calculator on your user oh you 00:42:31.916,00:42:39.924 are you are doomed. [Laughter] >> So uh last uh slide. >> So uh 00:42:39.924,00:42:48.166 to draw conclusion uh we did the sandboxes are uh great security 00:42:48.166,00:42:52.904 modification uh on the I believe the all recent. And the rest of 00:42:52.904,00:42:56.774 the operation system has sandbox support and uh they take some 00:42:56.774,00:43:00.244 different approaches to they have the same concept and uh 00:43:00.244,00:43:05.216 they make attackers to require some of these at least 00:43:05.216,00:43:08.453 additionals but to these sandboxes. So but a determined 00:43:08.453,00:43:10.354 hacker can still compromise the system but uh as you can see in 00:43:10.354,00:43:13.024 the previous demo. SO with some credit, goes to um colleague 00:43:13.024,00:43:16.828 Liang Chen, Qoobee, Wushi and all out other colleagues of KEEN 00:43:16.828,00:43:19.964 Lab. So if you have questions, contact us at out Twitter at 00:43:19.964,00:43:22.834 keen lab or my twitter and Marco’s twitter.. >> Or you… >> 00:43:22.834,00:43:25.303 Yeah. >> Or you can find us around if you have any 00:43:25.303,00:00:00.000 questions. >> So thank you for coming. >> Thank you. [Applause]