Or will updating the SMS App, Chrome, WhatsApp, Signal etc be sufficient to cover all the likely input routes?
Or will updating the SMS App, Chrome, WhatsApp, Signal etc be sufficient to cover all the likely input routes?
Updating Chrome on an unsupported device would fix the issue, but you would still need an Android OS upgrade to fix the issue for apps like Signal and WhatsApp. Chrome bundles its own version of libwebp, but messaging apps and other highly exposed stuff like Gmail all use the OS provided interfaces for displaying images. Hopefully we'll start getting updates for security-supported Android devices in early October.
Nice of Google to drop security support for the Pixel 4a just before this bug drops.
It’s just icing on the proverbial cake that a month after they drop security support for the 4a a 0-click remote exploit is found.
Or the app could bundle the library, they can push updates faster but then again they could just use an old version and never update like most 3rd party dependencies these days.
The argument of a $1000 Androd phone vs a $1500 iPhone falls over if you have to replace that Android phone 2 more times in the same period.
If the target is an Android, definitely an advanced exploit like this isn’t needed, so even if it will work, an easier ones most likely to be used.
Considering there are over 3 billion active Android users according to Google [2], that's at least 834 million people who are potentially vulnerable to this exploit that will likely never receive a patch. That's awful enough by itself, but particularly terrible since the exploit could be as simple as having someone view an image. Chrome may be fixed, but there are over 2 billion WhatsApp users. [3]
1. https://www.androidauthority.com/wp-content/uploads/2023/06/...
2. https://www.theverge.com/2021/5/18/22440813/android-devices-...
“Native image decoder - New NDK APIs let apps decode and encode images (such as JPEG, PNG, WebP) from native code for graphics or post processing, while retaining a smaller APK size since you don’t need to bundle an external library. The native decoder also takes advantage of Android’s process for ongoing platform security updates. See the NDK sample code for examples.”
However, poking about in the Android mainline module docs I can find no evidence that the image decoder libraries are included in the system updates that get pushed through Google Play. I’ve unpacked the obvious modules & found the video codecs, but no sign whatsoever of the image decoder libraries,
It would be helpful to be able to tell whether a given phone has received such an update, especially in the case of 0-click exploits like this one! Are all Android 11+ phones guaranteed to receive it? (it would seem so, if this is a core security component) Is there anyway to tell whether you’ve received it? This aspect of Android updates seems to be entirely opaque to the end user - updates get pushed through Google Play services & that’s it.
After some investigation, I found https://support.google.com/product-documentation/answer/1141...
which gives some details of Android system updates pushed through Google Play. This changelog does not list CVEs or specific bugfixes, so it’s impossible to tell which bugs have been closed via this route, but it is at least slightly better than nothing at all.
It is possible to map those updates to actual CVEs mentioned in the AOSP sources via a circuitous route involving adb & running a bunch of commands on your phone, according to this blog post: https://www.esper.io/blog/building-a-google-play-system-upda...
Looking at the current AOSP wepb sources, no module tags have been attached to the current release, so it doesn’t look like it’s been pushed out yet, if it’s possible for Google to do so at all outside the monthly security updates for in-support phones.
Not doing so is a disservice to their customers frankly.
They're currently bugging me about updating a 9 year old ipad I just use as a kindle. They flatly blow Google away on device updates, and will continue to do so even if Google isn't lying about their new / supposed 5 year update plan (and NB: that's 5 years from the release date, not 5 years from the last sale date, which could be reasonable.)
It sounds like the exploit was triggered in another process by iMessage forwarding the post-parse attachment content to that process - the blog post says this is passkit related so I assume any app that has passkit interaction could do this. iMessage is simply universally available so why use a different medium.