[HN Gopher] The Qualcomm DSP Driver - Unexpectedly excavating an...
___________________________________________________________________
The Qualcomm DSP Driver - Unexpectedly excavating an exploit
Author : todsacerdoti
Score : 86 points
Date : 2024-12-16 12:01 UTC (10 hours ago)
(HTM) web link (googleprojectzero.blogspot.com)
(TXT) w3m dump (googleprojectzero.blogspot.com)
| intsunny wrote:
| In the conclusion Google writes:
|
| > 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?
| Rygian wrote:
| 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".
| mschuster91 wrote:
| 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...
| gruez wrote:
| 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.
| mschuster91 wrote:
| > 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.
| bri3d wrote:
| > 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.
| bri3d wrote:
| > - 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.
| maeil wrote:
| > 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.
| rickdeckard wrote:
| I highly doubt that the person writing this was hinting on
| anything remotely like that.
| mikaraento wrote:
| 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).
| fidotron wrote:
| > 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?
| rickdeckard wrote:
| > 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...?
| fidotron wrote:
| This is somewhere between scarily naive and horrific bait.
| surajrmal wrote:
| 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.
| toast0 wrote:
| 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.
| ram_rattle wrote:
| 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
| hulitu wrote:
| > I don't understand why would they not ack or fix this
|
| Because they have (tree letters) customers. /s
| sumtechguy wrote:
| 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.
| david-gpu wrote:
| _> 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.
| skirge wrote:
| I heard about strcpys (secure strcpy) #defined again as
| strcpy
| Moral_ wrote:
| Qualcomm has fixed all but one issue.
| biosboiii wrote:
| Qualcomm being Qualcomm, again and again and again.
| DonnchaOC wrote:
| The full report describing the use of the exploits is published
| at https://securitylab.amnesty.org/latest/2024/12/serbia-a-
| digi...
___________________________________________________________________
(page generated 2024-12-16 23:01 UTC)