The Qualcomm DSP Driver – Unexpectedly excavating an exploit(googleprojectzero.blogspot.com)
googleprojectzero.blogspot.com
The Qualcomm DSP Driver – Unexpectedly excavating an exploit
https://googleprojectzero.blogspot.com/2024/12/qualcomm-dsp-driver-unexpectedly-excavating-exploit.html
27 comments
I also read between the lines something like "don't be surprised if we start to make our own chipsets and drivers, because current vendors can't be trusted to do a good job".
For compute offload, Google has indeed done that - the Tensor chips have Google's TPUs instead of Qualcomm DSPs.
Both on these TPUs as well as on pre-Tensor hardware that had Qualcomm DSPs, Pixels would not allow apps access to the kernel interfaces. Access would be blocked or mediated via a separate service process ('binderized HAL').
(Some) OEMs have repeatedly opened access to these kernel interfaces in order to trade security for performance.
(I used to work on compute offload at Google).
Both on these TPUs as well as on pre-Tensor hardware that had Qualcomm DSPs, Pixels would not allow apps access to the kernel interfaces. Access would be blocked or mediated via a separate service process ('binderized HAL').
(Some) OEMs have repeatedly opened access to these kernel interfaces in order to trade security for performance.
(I used to work on compute offload at Google).
Even Apple failed at that, despite having bought out Intel's modem division and there being no other company coming even close to Apple's demand of hoarding knowledge in-house.
The problem is multifold:
- RF of any kind is extremely complex
- RF of any kind that is to be certified in virtually all countries on this rock, with providers with infrastructure from 2G shit that never got upgraded since the 90s to hyper-modern OpenRAN is even more complex simply due to all the cert and testing effort required
- making that RF stuff power efficient is the utter end game
- mobile communications standards on their own are a horrid, horrid mess to implement, not made easier by some of the specs being decades old and never intended to coexist in a world where a single device can run 30 gigabit a second...
- patents, so many patents, because of course it's a global standard that a) isn't open and b) everyone and their dog wants to profit off of
- on top of that come legal aspects: not just the certification requirements, but also lawful intercept and stealth ping stuff, or having to secure the device so that enterprising hackers can't readily turn it into an SDR, jammer or sniffer...
[1] https://www.eand.com/en/news/13-may-eand-uae-sets-new-record...
The problem is multifold:
- RF of any kind is extremely complex
- RF of any kind that is to be certified in virtually all countries on this rock, with providers with infrastructure from 2G shit that never got upgraded since the 90s to hyper-modern OpenRAN is even more complex simply due to all the cert and testing effort required
- making that RF stuff power efficient is the utter end game
- mobile communications standards on their own are a horrid, horrid mess to implement, not made easier by some of the specs being decades old and never intended to coexist in a world where a single device can run 30 gigabit a second...
- patents, so many patents, because of course it's a global standard that a) isn't open and b) everyone and their dog wants to profit off of
- on top of that come legal aspects: not just the certification requirements, but also lawful intercept and stealth ping stuff, or having to secure the device so that enterprising hackers can't readily turn it into an SDR, jammer or sniffer...
[1] https://www.eand.com/en/news/13-may-eand-uae-sets-new-record...
> - patents, so many patents, because of course it's a global standard that a) isn't open and b) everyone and their dog wants to profit off of
This is the only real problem. The other problems are challenging but surmountable engineering issues (which Apple already had solutions to, thanks to their Intel-modem acquisition).
There are plenty of Chinese basebands that work (code quality and security aside), because the CCP told Qualcomm to get bent in 2015.
This is the only real problem. The other problems are challenging but surmountable engineering issues (which Apple already had solutions to, thanks to their Intel-modem acquisition).
There are plenty of Chinese basebands that work (code quality and security aside), because the CCP told Qualcomm to get bent in 2015.
All of the issue you described are specific to basebands, not all "chipsets and drivers", and this article is talking about exploits in DSPs, not basebands. Moreover, AFAIK the baseband (or more specifically the modem) is separated from the application processor on both iPhones and Pixels, so a baseband 0day allowing you to take over the entire phone is already unlikely.
> exploits in DSPs, not basebands
For what it's worth, the DSP this driver talks to is the same type of DSP used in Qualcomm basebands.
However, there's actually no strong relevance to DSPs at all here; it's just a broken DMA/ION-shared-memory driver that happens to be the one that talks to a DSP. There are lots of these in most Android board support packages.
> separated from the application processor on both iPhones and Pixels
Across an interface with drivers! Quite a few baseband drivers are exploitable from both sides of the interface.
For what it's worth, the DSP this driver talks to is the same type of DSP used in Qualcomm basebands.
However, there's actually no strong relevance to DSPs at all here; it's just a broken DMA/ION-shared-memory driver that happens to be the one that talks to a DSP. There are lots of these in most Android board support packages.
> separated from the application processor on both iPhones and Pixels
Across an interface with drivers! Quite a few baseband drivers are exploitable from both sides of the interface.
> so a baseband 0day allowing you to take over the entire phone is already unlikely.
The baseband has to talk with the main SoC though by some way, and wherever there are interfaces, so are drivers and associated bugs. And usually you get the baseband and main SoC from the same company, so same engineering culture. It's not like shoddy development isn't just happening on the baseband BSP side.
> All of the issue you described are specific to basebands, not all "chipsets and drivers", and this article is talking about exploits in DSPs, not basebands.
Power efficiency, patents and legal compliance crap also impact the main SoC/chipset side.
The baseband has to talk with the main SoC though by some way, and wherever there are interfaces, so are drivers and associated bugs. And usually you get the baseband and main SoC from the same company, so same engineering culture. It's not like shoddy development isn't just happening on the baseband BSP side.
> All of the issue you described are specific to basebands, not all "chipsets and drivers", and this article is talking about exploits in DSPs, not basebands.
Power efficiency, patents and legal compliance crap also impact the main SoC/chipset side.
> Even Apple failed at that, despite having bought out Intel's modem division and there being no other company coming even close to Apple's demand of hoarding knowledge in-house.
The upcoming SE going on sale in 2025 is set to have the Apple modem.
The upcoming SE going on sale in 2025 is set to have the Apple modem.
I highly doubt that the person writing this was hinting on anything remotely like that.
> Does this mean the vast majority of Android users (who are on Qualcomm chipsets) are vulnerable to these zero day attacks?
If not these precise ones, related ones yes. Certain chip vendors are notorious for not providing fixes of this kind to the manufacturers to roll out (maybe doing so selectively based on who they're extra special buddies with), if they ever even made them at all before moving on to the next shiny SoC.
The other side of this is Google never met a security problem that isn't solved by further coupling the system to their cloud, especially for updates. Coincidence?
If not these precise ones, related ones yes. Certain chip vendors are notorious for not providing fixes of this kind to the manufacturers to roll out (maybe doing so selectively based on who they're extra special buddies with), if they ever even made them at all before moving on to the next shiny SoC.
The other side of this is Google never met a security problem that isn't solved by further coupling the system to their cloud, especially for updates. Coincidence?
> Certain chip vendors are notorious for not providing fixes of this kind to the manufacturers to roll out (maybe doing so selectively based on who they're extra special buddies with), if they ever even made them at all before moving on to the next shiny SoC.
Never heard that before. Chipset vendors are under maintenance contracts with their customers, so they are actually PAID to provide fixes especially for CVE's. Manufacturers on the other hand have little to no recurring revenue from a device which could finance to implement, test and rollout each patch.
Care to provide a concrete example for your claim?, especially for this "extra special buddies" suggestion which insinuates that a chipset vendor developed a patch and still doesn't provide it to all its customers...?
Never heard that before. Chipset vendors are under maintenance contracts with their customers, so they are actually PAID to provide fixes especially for CVE's. Manufacturers on the other hand have little to no recurring revenue from a device which could finance to implement, test and rollout each patch.
Care to provide a concrete example for your claim?, especially for this "extra special buddies" suggestion which insinuates that a chipset vendor developed a patch and still doesn't provide it to all its customers...?
If the chipset vendors never provide fixes except to customers that ask, and the customers never ask because it costs reimbursed money to do something with them, from the point of view of the end consumer, the chipset vendors haven't provided the fixes.
In PC hardware, the expectation is that most drivers are available both from the manufacturer of the device, and directly from the chipset vendors. Some chipset vendors don't play that way, but most do. In mobile, the expectation is that drivers only come from the device manufacturer and if there's no updates, it's hard to figure out who's at fault because there's no transparency.
In PC hardware, the expectation is that most drivers are available both from the manufacturer of the device, and directly from the chipset vendors. Some chipset vendors don't play that way, but most do. In mobile, the expectation is that drivers only come from the device manufacturer and if there's no updates, it's hard to figure out who's at fault because there's no transparency.
For like 2 years per chipset. That's not very long. Also since every customer has its own kernel branch, not all of them get the fix just because it was made in one branch.
This is somewhere between scarily naive and horrific bait.
The full report describing the use of the exploits is published at https://securitylab.amnesty.org/latest/2024/12/serbia-a-digi...
Qualcomm being Qualcomm, again and again and again.
I don't understand why would they not ack or fix this, such as shame that google has to do all the hard work to keep all their ecosystems shit together
Qualcomm has fixed all but one issue.
> I don't understand why would they not ack or fix this
Because they have (tree letters) customers. /s
Because they have (tree letters) customers. /s
It is not that. It is just the managers of the particular groups do not care about their code quality.
I made the simple mistake of running code thru some simple linters and things like valgrind/boundschecker/purify. Apparently not wanting my code to crash was some sort of political nightmare. I had to involve several higher level managers for anyone to care. The other groups got seriously mad at me for daring to look at their code. Learned my lesson. Do not do that, just fix their crap and dont say anything and work with your own branch of their borked stuff.. I even had the issue on my own team sometimes. People would 'take ownership' of something and you better not dare touch their code. It usually was not too hard to find the same mistake hundreds of times in a particular code base. As they made the mistake once they then copy and pasted it everywhere.
There are teams in qcom that 'get it'. There are also golden calf teams where you just do not even think about looking at their code.
It is not TLA's, it is built in kingdom problem systemic to the way qcom runs itself.
I made the simple mistake of running code thru some simple linters and things like valgrind/boundschecker/purify. Apparently not wanting my code to crash was some sort of political nightmare. I had to involve several higher level managers for anyone to care. The other groups got seriously mad at me for daring to look at their code. Learned my lesson. Do not do that, just fix their crap and dont say anything and work with your own branch of their borked stuff.. I even had the issue on my own team sometimes. People would 'take ownership' of something and you better not dare touch their code. It usually was not too hard to find the same mistake hundreds of times in a particular code base. As they made the mistake once they then copy and pasted it everywhere.
There are teams in qcom that 'get it'. There are also golden calf teams where you just do not even think about looking at their code.
It is not TLA's, it is built in kingdom problem systemic to the way qcom runs itself.
I heard about strcpys (secure strcpy) #defined again as strcpy
Well at least it compiles again. sigh....
I can just imagine the person writing that saying “Hah, think you made strcpy secure? Hold my beer…”
> It is not TLA's, it is built in kingdom problem systemic to the way qcom runs itself
Yeah, it was one of the reasons I left. Because the chip is divided into many different processors, and broadly speaking the more area your processor takes the more your organization matters, there is this constant infighting for expanding the domain of your processor to capture an ever increasing piece of the pie.
This is of course an oversimplification. There are plenty of people just trying to build the best product they can and cooperating with other teams, but at the VP level and above it's a dog eats dog world.
At NVidia my role was much smaller, but what I saw was much more cooperative, and I think a big part of it is that the GPU is at the end of the day one giant chip that does everything and all the pieces work together like an orchestra. I even saw better communication between the software and hardware folks, which is always a challenge in the semiconductor industry.
Yeah, it was one of the reasons I left. Because the chip is divided into many different processors, and broadly speaking the more area your processor takes the more your organization matters, there is this constant infighting for expanding the domain of your processor to capture an ever increasing piece of the pie.
This is of course an oversimplification. There are plenty of people just trying to build the best product they can and cooperating with other teams, but at the VP level and above it's a dog eats dog world.
At NVidia my role was much smaller, but what I saw was much more cooperative, and I think a big part of it is that the GPU is at the end of the day one giant chip that does everything and all the pieces work together like an orchestra. I even saw better communication between the software and hardware folks, which is always a challenge in the semiconductor industry.
C doing C things
> It took less than 3 months of research to discover 6 separate bugs in the adsprpc driver, two of which (CVE-2024-49848 and CVE-2024-21455) were not fixed by Qualcomm under the industry standard 90-day deadline. Furthermore, at the time of writing, CVE-2024-49848 remains unfixed 145 days after it was reported. Past research has shown that chipset drivers for Android are a promising target for attackers, and this ITW exploit represents a meaningful real-world example of the negative ramifications that the current third-party vendor driver security posture poses to end-users. A system’s cybersecurity is only as strong as its weakest link, and chipset/GPU drivers represent one of the weakest links for privilege separation on Android in 2024. Improving both the consistency and quality of code and the efficiency of the third-party vendor driver patch dissemination process are crucial next steps in order to increase the difficulty of privilege escalation on Android devices.
Does this mean the vast majority of Android users (who are on Qualcomm chipsets) are vulnerable to these zero day attacks?