Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So if your Android device is out of support, there’s now a 0-click exploit floating about in the wild?

Or will updating the SMS App, Chrome, WhatsApp, Signal etc be sufficient to cover all the likely input routes?



Well, we don't know for sure that an exploit exists for this bug on Android yet (the original exploit was for iOS via iMessage), but there's a reasonably high chance that one has been developed already. These types of exploits are in very high demand for Android right now, I've heard some eye-watering prices being mentioned recently.

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.


This is honestly pretty bad. You either wait a month (or more) for the OS security update, if you are lucky enough that your device is supported.

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.


This is the primary reason why I push the the non technically inclined (grandparents, older friends, etc) in my life to use iPhones. The latest Pixel I believe is now offering 6 years security patched (which makes it an Android leader), but 7+ years is already the standard on the cheapest iPhone option.

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.


I have iOS devices from 2015 that still get security updates and already patched for this issue. It's really just straight up irresponsible at this point that Android can't actually do this.


So there’s a webp system library as well as the one in Chrome?

Nice of Google to drop security support for the Pixel 4a just before this bug drops.


You’re saying that Google knew about the bug and purposely dropped security support for the pixel 4a right before? Support didn’t age out, like it typically does (age of device)? Google just pulled security support for this one device?


No, I’m saying it’s extremely frustrating that Google just drops security support entirely for devices like this, when they could continue to at least patch egregious platform bugs like this one, even if they can’t fix everything.

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.


> Well, we don't know for sure that an exploit exists for this bug on Android yet

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.


Can you give me a real number on that? Are we talking over a million? Over 5?


The only publicly posted price list that I know of is zerodium’s (evil people). http://zerodium.com/program.html They currently offer 2.5 million for an android zero click with persistence. This doesn’t give you the persistence piece without another bug so maybe 2m. Of course, they are only willing to offer that price if they could sell it for much more.


The platform image decoding libraries really ought to be one of the system modules that are updated through the Play Store, can anyone confirm whether they are or not?


I certainly hope it is, but even still Project Mainline only came out with Android 10, and as of May 30, 2023, 27.8% of Android users are on Android 9 or lower, according to Google's stats listed in Android Studio. [1]

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

3. https://about.fb.com/news/2020/02/two-billion-users/


https://android-developers.googleblog.com/2020/02/Android-11... says:

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


I'd really rather it was possible for me to update vulnerable image decoding libraries than having to install a Play service and give it root access to do that for me


Some messaging apps have options to not automatically download/preview images that are sent, so that might be a good step to take. I know that Google Messages has this feature.


If your android is out of security updates, this won’t be the only thing to worry about, I would probably worry about the easier to exploit ones first.


Yes, and Google should be supporting these old devices as far as possible.

Not doing so is a disservice to their customers frankly.


Agreed, I found infuriating that after 2ish years your android is no longer secure and you are on your own, and you have two options here, throw it away and get a new one that will be thrown away soon, or go in the efforts to find a hacky way to install a custom ROM that hopefully the maintainers will keep it secure. It’s that reason why I switched to iOS years ago.


It seems that GrapheneOS is making releases for Pixel phones, including the 4a which include patches for the webp exploit: https://grapheneos.org/releases#2023091800


Just buy Apple hardware.

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's an especially big problem on iOS because iMessage has elevated permissions. On Android, all of those apps are sandboxed.


iMessage is sandboxed, and does attachment processing in yet another sandbox (the exploit is named BLASTpass as it circumvents this). These days iMessage itself is probably more tightly sandboxed than other apps.

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.


iMessage is a sandboxed app.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: