While they are still withholding info about how to exploit the bugs, there is more technical detail in their Defcon talk, "Pwn2Own Qualcomm Compute DSP for Fun and Profit" https://www.youtube.com/watch?v=CrLJ29quZY8
Also discussed here
https://news.ycombinator.com/item?id=24081581 https://news.ycombinator.com/item?id=24092545
Seriously I'm beyond pissed at the state of Android, patches and open-source compliance. If we are lucky 10% of current phone models will get any form of update. The rest will be vulnerable for years until the devices finally break.
And that's only the Qualcomm stuff. There is another CPU vendor beginning with M who is big in el-cheapo hardware - look at their Android kernel leaks, wherever you dig you find horrid, HORRID code.
Google should mandate full open source disclosure of all GPL'd components as part of the Play Store certification and unlockable bootloaders, otherwise this shit is never going to change.
“A single SoC (Software on Chip) may include features to enable daily mobile usage such as image processing, computer vision, neural network-related calculations, camera streaming, audio and voice data.“
Should be SoC (System on Chip)
Here's a link to the DEF CON talk: https://www.youtube.com/watch?v=CrLJ29quZY8
There seems to be some confusion on the authors' behalf about what a DSP is, and what an SoC is ("software" on chip, as they call it...) I'm just nitpicking, of course.
I wonder if Apple/others knew about such vulnerabilities, and passed up on using the chip as a risk? Or, was it just dumb luck that they avoided this?
Time to switch to open source:
I guess this makes "national security" as an argument a bad joke.
Hardware vulnerability and issues are hard to address at times as it can be connected to other vendor hardware or softwares. I always wonder if these flaws are left in the design intentionally or its just a sneaky bad bugs.
Is there any related data for Apple?
I wonder how would it be like to fill application forms for over 400 CVE numbers, or reading a security advisory with the first page exclusively occupied by CVE numbers. Well, seriously speaking, they'll probably group these vulnerabilities and apply a big one.
Would having an open source chip with a rolling release be more secure? Like as soon as the vulnerability is discovered you would push the fix and the next generations would already be fixed. Or would such frequent changes to the chip design be to difficult to mass produce, due to having to modify the production process?
This is coming from a point of view that Linux is quite a success and thus maybe the same philosophy could be used for hardware?
Shouldn't proper IOMMU usage prevent this?
In theory when properly configured the DSP or GPU should be unable to touch system RAM outside of buffers that are specifically assigned to them.
I'm not very familiar with the status of IOMMU on Android devices.
Google has pushed the patch for this back to October. I wonder what will happen to downstream vendors (Samsung, CopperheadOS)?
You say vulnerability, we say feature.
insecure by design
If the US government hadn't sanctioned Huawei, we could have an alternative to these chips.
SpaceX designed custom SoCs for their isolated offshore/offworld network of Starlink satellites, https://spacenews.com/spacex-accused-of-poaching-chipmakers-...
> Broadcom filed suit ... claiming SpaceX hired a number of Broadcom’s top engineers to develop “a family of sophisticated, customized computer chips.” The two companies had been working together on the development of advanced computer chips for an undisclosed project, but SpaceX ultimately ended the collaboration.
Do any of these vulnerabilities let us unlock the bootloader?