WEBVTT 00:28.860 --> 00:32.780 It looks like there's actually an ad on Twitch right now. 00:44.180 --> 00:45.300 We're on. 00:45.300 --> 00:46.220 All right. 00:47.660 --> 00:56.220 Hi everyone, thanks for joining us today in the Q&A for Pwn2Own, QAM's compute DSP for fun and profit. 00:56.280 --> 00:58.720 Talk about a mouthful, right? 00:59.500 --> 01:04.800 Hi everyone, thanks for joining us today in the Q&A for Pwn2Own. 01:04.800 --> 01:14.820 I am a bit newer than you because this talk definitely went down into the weeds to a technical level that some of us might not be at. 01:14.820 --> 01:19.560 So I was wondering, one, can you introduce yourself to everyone? 01:19.560 --> 01:26.600 And two, can you give me a explain it like I'm five overview of the research that you did? 01:28.080 --> 01:30.460 Okay, no problem. 01:30.460 --> 01:31.740 Hello everyone. 01:31.740 --> 01:35.420 So first of all, yes, you're right. 01:35.420 --> 01:38.680 This talk is highly technical. 01:38.680 --> 01:40.840 I tried to explain. 01:41.560 --> 01:48.540 First of all, we found, we discovered several vulnerabilities. 01:48.540 --> 02:00.020 And these vulnerabilities allow us to execute a custom malware code on a DSP processor of a mobile device. 02:00.020 --> 02:05.120 I mean, the DSP processor of a Qualcomm-based Android phone. 02:05.120 --> 02:14.400 This means it's about 50, I think, percent of all mobile phones. 02:14.400 --> 02:31.580 And it means that regularly, you know, there is an Android operating system, including Linux kernel, that is run on a CPU, actually. 02:31.580 --> 02:44.380 But there is another processor, DSP, on a mobile device, and we found a way to execute some codes on this processor. 02:44.380 --> 02:52.160 And through this, gain some privileges and denounce service capabilities. 02:52.160 --> 03:05.160 This means, actually, that I can, if you install my malware application, and I can just break your phone, for example. 03:05.160 --> 03:09.420 Or I can steal some information from your phone. 03:09.420 --> 03:22.820 And for this, I just need to use some API provided by Qualcomm that allows me to execute code on this processor. 03:23.040 --> 03:24.100 That's all. 03:24.100 --> 03:29.040 So, several vulnerabilities for big things. 03:29.040 --> 03:38.800 And actually, what I can get from this, I can hide my malicious code inside of the DSP processor. 03:38.800 --> 03:44.320 And antiviruses don't expect to see here something. 03:44.580 --> 03:53.640 And some execution, because all code that runs on the DSP processor is signed by Qualcomm. 03:53.640 --> 04:01.000 This means that any third-party application can do nothing inside of this processor. 04:01.000 --> 04:12.930 All other things, as I mentioned, denounce service, privilege escalation, and so on. 04:21.450 --> 04:23.970 So, okay. 04:24.170 --> 04:25.170 Let's begin. 04:25.990 --> 04:32.390 Actually, the major goal of the research was to execute the code in the kernel of the DSP processor. 04:32.390 --> 04:40.050 But I need to use several exploits, several vulnerabilities in the chain to do this thing. 04:40.050 --> 04:46.270 And the first thing, the first vulnerability, is to downgrade some code. 04:46.270 --> 04:54.250 Actually, I need to downgrade some library, pre-installed on a mobile device, and start from this. 04:54.250 --> 05:13.170 For example, I can pull some library from, I don't know, a Chinese Xiaomi or Sony device, and then use its library to execute on the newest Samsung S20. 05:13.860 --> 05:28.320 So it's some vulnerability that there is no version check inside of the operating system running in the DSP processor. 05:28.710 --> 05:42.850 But after that, I need to use several other vulnerabilities and exploits to transfer my execution to the kernel of the DSP processor. 05:42.850 --> 05:45.410 It means that downgrade is the first step. 05:45.410 --> 05:52.810 After that, I need to use a vulnerability and a full exploit to execute the code in the user mode of the DSP processor. 05:52.810 --> 05:57.170 And from the user mode, I can access to DSP drivers. 05:57.170 --> 06:07.230 And I discovered several vulnerabilities in DSP drivers that gain privileges of kernel. 06:07.230 --> 06:18.090 It gets the OS level of DSP operating system running on DSP. 06:22.070 --> 06:23.630 Great, thank you. 06:23.630 --> 06:32.730 So when I was reviewing the subject, I was wondering why you chose the DSP module. 06:32.730 --> 06:47.870 I mean, I think when you mentioned the Qualcomm system as a chip, as a black box, and the number of components and subcomponents built into it, I didn't know if there was something you found or you suspected was specifically risky about the subcomponent, 06:47.870 --> 06:50.590 or was it just a particular one you chose? 06:53.740 --> 07:06.880 So, actually, you need to know that, for example, LG company uses some components implemented by Qualcomm. 07:06.880 --> 07:19.900 And LG company, LG vendor, manufacturer, they know what is it, what is actually Qualcomm components. 07:22.060 --> 07:31.200 Because there are a lot of libraries, a lot of ports that are prepared by Qualcomm and pushed to your device. 07:33.660 --> 07:46.400 And one main thing that I mentioned in the talk was that the reason for a lot of security issues, which we discovered, was in Hexagon SDK. 07:46.400 --> 07:59.400 Actually, Qualcomm provided some SDK for development and compilation and debugging of code that could be run on a DSP processor. 07:59.400 --> 08:07.240 And this Hexagon SDK contains serious bugs. 08:07.240 --> 08:15.940 And these bugs lead to code execution, actually. 08:15.940 --> 08:29.300 Hexagon SDK invokes, injects some vulnerabilities inside of all libraries that could be compiled. 08:29.300 --> 08:32.080 So, for example, you are a developer, you are a vendor. 08:32.080 --> 08:39.300 You prepared your code, C++ code, and going to compile it using Hexagon SDK. 08:39.300 --> 08:47.200 And you don't know that SDK will generate some code to help you, actually. 08:47.200 --> 08:50.300 But this code contains bugs. 08:50.300 --> 09:00.080 And an attacker can use these bugs to crash your library and execute code through your library. 09:00.700 --> 09:05.060 Yeah, I'm actually glad you brought that up. 09:05.060 --> 09:13.660 There was a speaker yesterday talking about a vulnerable TCP IP tech that was used in IoT systems. 09:13.660 --> 09:19.600 And he mentioned how we don't think of these as supply chain risks, but they are. 09:19.600 --> 09:22.480 And it seems that very much the case in this, right? 09:22.680 --> 09:40.500 A company includes a library that gets put into a piece of hardware that gets wrappered into a phone, which gets deployed, which a third-party app can now load up another copy of that library and exploit it. 09:40.500 --> 09:52.540 So I didn't know if you wanted to talk about the supply chain impact on this and what phone manufacturers should take as a lesson from your analysis. 09:54.540 --> 09:56.820 Yeah, good question. 09:56.820 --> 10:02.920 Actually, I just want to say that Qualcomm is going to do well. 10:02.920 --> 10:14.680 As I know, it's impossible to fix all these vulnerabilities. 10:14.680 --> 10:20.860 Actually, I reported to Qualcomm 400 unique issues. 10:20.860 --> 10:25.520 And this means that the problem is not just in one piece of code. 10:25.520 --> 10:28.340 The problem is actually in the architecture. 10:28.340 --> 10:35.140 In the architecture of the operating system running in this processor. 10:35.140 --> 10:50.700 And as I know, Qualcomm now works on some new feature, Sandbox, actually, that will prevent execution out of Sandbox inside of these processors. 10:50.700 --> 11:15.980 So if you find a vulnerability and gain privileges to execute some unsigned code inside of processor on your phone, it can provide you some permissions to steal user data or to gain some special privileges or deny service. 11:15.980 --> 11:18.880 So it's an architecture issue. 11:18.880 --> 11:29.240 And I hope and I think that in the future, we will see a new architecture of Qualcomm DSP operating system. 11:31.580 --> 11:33.960 We had a question come into the chat. 11:33.960 --> 11:40.160 And it says, in the talk, you mentioned recompiling on the latest version of Hexagon SDK. 11:40.160 --> 11:46.060 Are there other steps app developers can take to lower the risk of bugs like this? 11:48.160 --> 11:49.100 Okay. 11:49.100 --> 12:09.040 First of all, I think that it should be mentioned that SDK bug that actually invoked vulnerabilities to dozens of libraries, it will be patched just in Hexagon SDK 4.0. 12:09.040 --> 12:17.940 But now third-party developers can't download this new version of SDK. 12:17.940 --> 12:30.140 As I know, just mobile vendors now can ask Qualcomm to provide this new version without vulnerability. 12:30.140 --> 12:48.390 But if we are talking about something general, no one can promise that the new version of SDK or any other SDK will be clear from bugs and from vulnerabilities. 12:49.160 --> 12:55.780 You always have a risk, but nothing we can do. 12:55.780 --> 13:18.280 So Hexagon SDK now is one in the world, actually, that can provide you ability to build your code, to write code of Hexagon architecture. 13:18.280 --> 13:24.560 So it means that you don't have a choice. 13:24.560 --> 13:30.680 You have to execute Hexagon SDK to build your code, to write code of Hexagon. 13:31.320 --> 13:37.440 So use it and I will try to find something new for you. 13:38.220 --> 13:49.280 We were talking earlier, though, you were mentioning that there was, I guess, a little bit more news coming out after you released your research and the patch was implemented. 13:49.280 --> 13:54.140 Could you go into a little bit of the other vulnerabilities that are kind of still out in the wild? 13:57.140 --> 14:10.240 For now, as I mentioned, we have a lot of issues and for now only maybe just several of them have been fixed. 14:10.240 --> 14:21.060 For example, issues in Hexagon SDK, but a lot of vulnerabilities have not been patched. 14:21.060 --> 14:51.040 We are waiting for this and for now, as I know, Qualcomm just asked software developers and vendors, actually, OEM vendors and mobile manufacturers to close an ability of a third-party Android application to ask something from these big processors. 14:52.500 --> 14:54.020 That's it. 14:54.020 --> 14:57.000 So we are waiting for the patch still. 14:57.000 --> 15:21.020 Therefore, I can't share technical information about those vulnerabilities and I can't open source a POC that I implemented to execute code in unsigned code. 15:21.020 --> 15:23.500 It's not in the kernel of the DSP. 15:24.720 --> 15:26.200 Sorry for this. 15:27.120 --> 15:33.180 The next question that we have come up is, you mentioned using older libraries with known security issues. 15:33.180 --> 15:39.520 Did you find during fuzzing exploitable bugs in the latest versions of some of these libraries? 15:41.180 --> 15:42.940 It's a good question. 15:42.940 --> 15:43.520 Thank you. 15:43.520 --> 15:45.760 And the answer is yes. 15:45.760 --> 16:09.260 So I tried to fuzz a lot of libraries, a lot of drivers from many devices and I can say that a lot of all of them contains vulnerabilities. 16:10.260 --> 16:43.080 It doesn't mean it's old or new, but I just use in my chain the really old library because to find something special that provides read-write permissions and read-write patterns to exploit exactly vulnerability, I just find in an old library. 16:43.080 --> 16:58.160 But it doesn't mean that we can use another library and newest one and to fuzz it and to find something inside this library. 16:58.160 --> 17:11.620 So as I mentioned, dozens of libraries in all mobile phones, news and old based on Snapdragon system on the chip contains libraries. 17:14.720 --> 17:25.560 And we have an interesting follow-up, I think, and that's what are the chances that the best version of the skeleton would be updated before the next Android release? 17:28.160 --> 17:29.460 I don't know. 17:29.460 --> 17:55.380 So it's a good question and I asked this question at Qualcomm and I don't know because you need to understand that the first page of the page, it will be some fix provided by Qualcomm. 17:55.380 --> 18:13.120 After that, mobile vendors like Samsung, LG and Xiaomi and many others need to adopt this page to the actual devices and maybe just after that, we will see this page on our phones. 18:13.120 --> 18:32.380 It means that maybe in the next month, we will see some page, for example, on Samsung devices, but it doesn't mean that all vendors and all mobile phones and manufacturers will update their phones in the same moment. 18:35.690 --> 18:46.410 Yeah, so you described a problem with the whole Android infrastructure in general and the update, the chain and the delays. 18:46.890 --> 19:00.630 So aside from making sure they buy the newest phone to get the latest patches, is there really anything an end user can do to detect that such an exploit would be on their phone? 19:03.590 --> 19:10.810 Okay, first of all, it's very difficult to detect such an attack and such an exploit. 19:10.930 --> 19:24.790 For example, in our company, I don't want to advertise, but you need to use some antivirals, actually, which expect to see code execution in this processor. 19:24.790 --> 19:46.530 Just in this case, this antivirus will try to analyze all your applications installed on your phone and try to find you using some signature or machine learning and some suspicious code which could be used to attack this processor. 19:46.530 --> 19:54.550 So for now, I see only one way to prevent attack your newest mobile phone is to use good antivirus. 19:54.550 --> 19:56.650 But I'm not sure. 19:56.650 --> 20:08.090 And I think that currently antiviruses expect to see some attacks like this on your phone. 20:08.090 --> 20:17.250 But maybe in the next release of the antivirus, we will see. 20:40.510 --> 20:46.010 My question was, did you find that they were attentive to that disclosure? 20:46.010 --> 20:55.110 And the question from the audience is, did you find vendors, did you find that the vendors didn't seem to care about the problems with the skeleton libraries? 20:57.550 --> 21:10.210 Actually, no, I think that all vendors are trying to patch their code, but now vendors can do that. 21:10.210 --> 21:23.910 So because we are waiting for the page from Qualcomm, because as I mentioned, the first stage of the page is to get a new page or a new SDK from Qualcomm. 21:23.910 --> 21:35.930 And just after that, you can... vendors will use it to inject this news and patch inside of their code. 21:35.930 --> 21:43.910 But the interesting thing that I would mention is that Samsung, for example, was very good with this. 21:43.910 --> 22:06.750 For example, Samsung sent to me a mail before this presentation and asked what I was talking about, how they can patch their phones from this type of attack. 22:06.750 --> 22:14.090 So Samsung is pretty good with this type of situation. 22:14.090 --> 22:16.430 But now we are waiting for the page. 22:18.610 --> 22:21.570 I think we are coming close to the end of time. 22:21.570 --> 22:25.450 Will you be hanging around Discord if people have follow-up questions? 22:31.390 --> 22:32.790 Slava, can you hear me? 22:33.550 --> 22:34.470 I'm sorry. 22:34.470 --> 22:39.870 I was asking if you will be sticking around Discord if people have follow-up questions for you? 22:42.010 --> 22:43.430 No problem. 22:43.430 --> 22:45.390 I can ask. 22:45.390 --> 22:51.650 So first of all, in the end of my presentation of my slides, you can find my email. 22:51.750 --> 22:55.190 You always can ask all your questions. 22:56.790 --> 23:04.050 Just send an email for me and I will try to explain and help you. 23:06.630 --> 23:14.490 But if you want to continue, I can answer to your questions here in the text form. 23:14.490 --> 23:17.870 Thanks guys for joining all of us, or should I say folks. 23:17.870 --> 23:21.090 And if you have any further questions, go ahead and reach out. 23:21.090 --> 23:26.310 Until then, join us in a bit for detecting 4G base stations in real time. 23:26.310 --> 23:27.210 Bye!