Corrupting memory without memory corruption(github.blog)
github.blog
Corrupting memory without memory corruption
https://github.blog/2022-07-27-corrupting-memory-without-memory-corruption/
5 comments
Android is not the only mobile ecosystem around, and not every ecosystem is a train wreck.
In theory I agree, but in practice...
The exploit given here works on any device with the given driver, regardless of OS. Android is just the primary example since it is the 800lb gorilla.
And as the article mentions, just 2 hardware stacks make up nearly the whole ecosystem.
The exploit given here works on any device with the given driver, regardless of OS. Android is just the primary example since it is the 800lb gorilla.
And as the article mentions, just 2 hardware stacks make up nearly the whole ecosystem.
I believe your parent comment is referring to iOS
It is interesting to see a GitHub employee (team) working on Android vulnerability. Is it Google's Project Zero-like pure research?
His writing is interesting anyways. Until I read this one [1] I didn't even know Snapdragon NPU has an open source driver. It's scary to see such a complex logic like NN graph execution running in the kernel space.
* [1] https://securitylab.github.com/research/qualcomm_npu/
His writing is interesting anyways. Until I read this one [1] I didn't even know Snapdragon NPU has an open source driver. It's scary to see such a complex logic like NN graph execution running in the kernel space.
* [1] https://securitylab.github.com/research/qualcomm_npu/
I wonder if there are similar bugs in the Panfrost drivers in Linux mainline...
TL;DR: an unchecked multiply operation can result in an overflow.
I see this often enough that if I was a bad guy, I'd just review every multiply in the code.
Which suggests that QA should do this, too.
Which suggests that QA should do this, too.
Maintaining security is impossible if it requires millions of lines of driver code from countless vendors to be correct. Which is why Redox has drivers in user-space: https://www.redox-os.org/
I checked my own device, and despite owning it just about a year, security updates have likely already stopped (although the manufacturer website hasn't exactly confirmed that, just yet) and even if the security updates were still coming, the gap between when they are released and then reach the devices are measured in months, not days, making these exploits worse than zero-days. I have seen no movement in correcting these issues from any of the manufacturers.
You too can check for yourself at source.android.com/security/bulletin