[intsunny]

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]

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]

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...

[mikaraento]

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).

[rickdeckard]

I highly doubt that the person writing this was hinting on anything remotely like that.

[fidotron]

> 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]

> 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...?