It looks like there's actually an ad on Twitch right now.
We're on.
All right.
Hi everyone, thanks for joining us today in the Q&A for Pwn2Own, QAM's compute DSP for fun and profit.
Talk about a mouthful, right?
Hi everyone, thanks for joining us today in the Q&A for Pwn2Own.
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.
So I was wondering, one, can you introduce yourself to everyone?
And two, can you give me a explain it like I'm five overview of the research that you did?
Okay, no problem.
Hello everyone.
So first of all, yes, you're right.
This talk is highly technical.
I tried to explain.
First of all, we found, we discovered several vulnerabilities.
And these vulnerabilities allow us to execute a custom malware code on a DSP processor of a mobile device.
I mean, the DSP processor of a Qualcomm-based Android phone.
This means it's about 50, I think, percent of all mobile phones.
And it means that regularly, you know, there is an Android operating system, including Linux kernel, that is run on a CPU, actually.
But there is another processor, DSP, on a mobile device, and we found a way to execute some codes on this processor.
And through this, gain some privileges and denounce service capabilities.
This means, actually, that I can, if you install my malware application, and I can just break your phone, for example.
Or I can steal some information from your phone.
And for this, I just need to use some API provided by Qualcomm that allows me to execute code on this processor.
That's all. So, several vulnerabilities for big things.
And actually, what I can get from this, I can hide my malicious code inside of the DSP processor.
And antiviruses don't expect to see here something.
And some execution, because all code that runs on the DSP processor is signed by Qualcomm.
This means that any third-party application can do nothing inside of this processor.
All other things, as I mentioned, denounce service, privilege escalation, and so on.
So, okay. Let's begin.
Actually, the major goal of the research was to execute the code in the kernel of the DSP processor.
But I need to use several exploits, several vulnerabilities in the chain to do this thing.
And the first thing, the first vulnerability, is to downgrade some code.
Actually, I need to downgrade some library, pre-installed on a mobile device, and start from this.
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.
So it's some vulnerability that there is no version check inside of the operating system running in the DSP processor.
But after that, I need to use several other vulnerabilities and exploits to transfer my execution to the kernel of the DSP processor.
It means that downgrade is the first step.
After that, I need to use a vulnerability and a full exploit to execute the code in the user mode of the DSP processor.
And from the user mode, I can access to DSP drivers.
And I discovered several vulnerabilities in DSP drivers that gain privileges of kernel.
It gets the OS level of DSP operating system running on DSP.
Great, thank you.
So when I was reviewing the subject, I was wondering why you chose the DSP module.
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,
or was it just a particular one you chose?
So, actually, you need to know that, for example, LG company uses some components implemented by Qualcomm.
And LG company, LG vendor, manufacturer, they know what is it, what is actually Qualcomm components.
Because there are a lot of libraries, a lot of ports that are prepared by Qualcomm and pushed to your device.
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.
Actually, Qualcomm provided some SDK for development and compilation and debugging of code that could be run on a DSP processor.
And this Hexagon SDK contains serious bugs.
And these bugs lead to code execution, actually.
Hexagon SDK invokes, injects some vulnerabilities inside of all libraries that could be compiled.
So, for example, you are a developer, you are a vendor.
You prepared your code, C++ code, and going to compile it using Hexagon SDK.
And you don't know that SDK will generate some code to help you, actually.
But this code contains bugs.
And an attacker can use these bugs to crash your library and execute code through your library.
Yeah, I'm actually glad you brought that up.
There was a speaker yesterday talking about a vulnerable TCP IP tech that was used in IoT systems.
And he mentioned how we don't think of these as supply chain risks, but they are.
And it seems that very much the case in this, right?
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.
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.
Yeah, good question.
Actually, I just want to say that Qualcomm is going to do well.
As I know, it's impossible to fix all these vulnerabilities.
Actually, I reported to Qualcomm 400 unique issues.
And this means that the problem is not just in one piece of code.
The problem is actually in the architecture.
In the architecture of the operating system running in this processor.
And as I know, Qualcomm now works on some new feature, Sandbox, actually,
that will prevent execution out of Sandbox inside of these processors.
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.
So it's an architecture issue.
And I hope and I think that in the future, we will see a new architecture of Qualcomm DSP operating system.
We had a question come into the chat.
And it says, in the talk, you mentioned recompiling on the latest version of Hexagon SDK.
Are there other steps app developers can take to lower the risk of bugs like this?
Okay. 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.
But now third-party developers can't download this new version of SDK.
As I know, just mobile vendors now can ask Qualcomm to provide this new version without vulnerability.
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.
You always have a risk, but nothing we can do.
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.
So it means that you don't have a choice. You have to execute Hexagon SDK to build your code, to write code of Hexagon.
So use it and I will try to find something new for you.
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.
Could you go into a little bit of the other vulnerabilities that are kind of still out in the wild?
For now, as I mentioned, we have a lot of issues and for now only maybe just several of them have been fixed.
For example, issues in Hexagon SDK, but a lot of vulnerabilities have not been patched.
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.
That's it. So we are waiting for the patch still.
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.
It's not in the kernel of the DSP.
Sorry for this.
The next question that we have come up is, you mentioned using older libraries with known security issues.
Did you find during fuzzing exploitable bugs in the latest versions of some of these libraries?
It's a good question. Thank you.
And the answer is yes.
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.
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.
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.
So as I mentioned, dozens of libraries in all mobile phones, news and old based on Snapdragon system on the chip contains libraries.
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?
I don't know. 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.
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.
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.
Yeah, so you described a problem with the whole Android infrastructure in general and the update, the chain and the delays. 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?
Okay, first of all, it's very difficult to detect such an attack and such an exploit. 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.
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.
So for now, I see only one way to prevent attack your newest mobile phone is to use good antivirus. But I'm not sure. And I think that currently antiviruses expect to see some attacks like this on your phone.
But maybe in the next release of the antivirus, we will see.
My question was, did you find that they were attentive to that disclosure? 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?
Actually, no, I think that all vendors are trying to patch their code, but now vendors can do that.
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. And just after that, you can... vendors will use it to inject this news and patch inside of their code.
But the interesting thing that I would mention is that Samsung, for example, was very good with this.
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.
So Samsung is pretty good with this type of situation. But now we are waiting for the page.
I think we are coming close to the end of time. Will you be hanging around Discord if people have follow-up questions? Slava, can you hear me?
I'm sorry.
I was asking if you will be sticking around Discord if people have follow-up questions for you?
No problem. I can ask. So first of all, in the end of my presentation of my slides, you can find my email. You always can ask all your questions.
Just send an email for me and I will try to explain and help you.
But if you want to continue, I can answer to your questions here in the text form.
Thanks guys for joining all of us, or should I say folks. And if you have any further questions, go ahead and reach out.
Until then, join us in a bit for detecting 4G base stations in real time. Bye!