[ANN] libwebp 1.3.2

James Zern

unread,

Sep 13, 2023, 10:00:37 PM9/13/23

to WebP Discussion

This release has been tagged. Archives are available [1].

This release contains only one change, an important security fix for lossless decoding. All users should upgrade. In case upgrading to 1.3.2 is not an option, the fix has been backported to the 1.0.3, 1.1.0, 1.2.0, 1.2.2, 1.2.4 and 1.3.0 branches.

From the NEWS file:

- 9/13/2023: version 1.3.2
This is a binary compatible release.
* security fix for lossless decoder (chromium: #1479274, CVE-2023-4863)

[1] https://storage.googleapis.com/downloads.webmproject.org/releases/webp/libwebp-1.3.2-ios-framework.tar.gz

James Zern

unread,

Sep 27, 2023, 3:44:23 PM9/27/23

to WebP Discussion

Hi,

On Wed, Sep 27, 2023 at 9:21 AM Randy _ <randy...@gmail.com> wrote:

Does running the new `huffman_fuzzer` on the vulnerable versions eventually discover the security issue?

I haven't had a chance to backport it. Some initial evidence from https://blog.isosceles.com/the-webp-0day/ suggests no. Using a broader corpus [2] with the existing fuzzers may.

[2] https://github.com/blendin/mecorpi

On Thursday, September 14, 2023 at 5:00:37 AM UTC+3 James Zern wrote:
This release has been tagged. Archives are available [1].

This release contains only one change, an important security fix for lossless decoding. All users should upgrade. In case upgrading to 1.3.2 is not an option, the fix has been backported to the 1.0.3, 1.1.0, 1.2.0, 1.2.2, 1.2.4 and 1.3.0 branches.

From the NEWS file:
- 9/13/2023: version 1.3.2
This is a binary compatible release.
* security fix for lossless decoder (chromium: #1479274, CVE-2023-4863)

A libwebp specific CVE was in progress while I was making this release. It is tracked as CVE-2023-5129.

keng deng

unread,

Oct 6, 2023, 6:41:07 AM10/6/23

to WebP Discussion, James Zern

Hi，

https://blog.isosceles.com/the-webp-0day/ The trigger call stack entry described in it is WebPDecode.

Some other third-party open source software(such as GlideWebpDecoder) will rely on libwebp,

they will decide whether to use the system's decoding function or their own libwebp based on the Android version.

public static Bitmap decodeStream(InputStream is, Rect outPadding, BitmapFactory.Options opts) {
// we don't throw in this case, thus allowing the caller to only check
// the cache, and not force the image to be decoded.
if (is == null) {
return null;
}

is = wrapToMarkSupportedStream(is);
Bitmap bm;
byte[] header = getImageHeader(is);
if (webpSupportRequired(header, 0, MAX_WEBP_HEADER_SIZE)) {
bm = nativeDecodeStream(
is,
opts,
getScaleFromOptions(opts),
getInTempStorageFromOptions(opts));
setWebpBitmapOptions(bm, opts);
setDefaultPadding(outPadding);
} else {
// system decode method used
bm = BitmapFactory.decodeStream(is, outPadding, opts);
}

return bm;
}

I found that the WebPFrame nativeRenderFrame function also calls WebPDecode in its code. Is this function also likely to be affected by the vulnerability?

James Zern

unread,

Oct 6, 2023, 10:23:09 PM10/6/23

to WebP Discussion

Hi,

On Fri, Oct 6, 2023 at 3:41 AM keng deng <deng...@gmail.com> wrote:

Hi，

https://blog.isosceles.com/the-webp-0day/ The trigger call stack entry described in it is WebPDecode.

Some other third-party open source software(such as GlideWebpDecoder) will rely on libwebp,
they will decide whether to use the system's decoding function or their own libwebp based on the Android version.

Yes, any library or application that depends on libwebp < 1.3.2, either directly or indirectly, and decodes untrusted lossless webp images would be vulnerable. Individual projects should be encouraged to update to 1.3.2 if possible or one of the patched release branches mentioned later in this thread.

Reply all

Reply to author

Forward