oss-security - Re: CVE-2023-4863: libwebp: Heap buffer overflow in WebP Codec

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230926153454.GA12511@openwall.com>
Date: Tue, 26 Sep 2023 17:34:54 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2023-4863: libwebp: Heap buffer overflow in WebP Codec

Hi,

It was great to hear from Vincent that the newer libwebp changes are
just "Clean-ups, no security issues there."  Yet I think it would also
be great if someone in here double-checks that.

Regarding the assert failure detected by oss-fuzz, "A release build
would not be negatively affected."  libwebp does specify -DNDEBUG by
default in:

$ fgrep -rl DNDEBUG .
./Makefile.vc
./xcframeworkbuild.sh
./iosbuild.sh
./configure.ac
./makefile.unix

and there's also cmake support, but apparently cmake sets -DNDEBUG for
release builds by default.  So at least this statement does appear to be
true for libwebp itself as built via the above means.

However, there's also Gradle support, and the gradle* files do not
mention NDEBUG.

Also, I wonder if there are other projects building code from libwebp
via different build environments.

So there might be (a small minority of) uses of libwebp where the assert
exists in a release build of some project.

On Tue, Sep 26, 2023 at 11:43:45AM +0200, Salvatore Bonaccorso wrote:
> Maybe related to this question in todays CVEs updates there appeared 
> 
> https://www.cve.org/CVERecord?id=CVE-2023-5129
> 
> vs.
> 
> https://www.cve.org/CVERecord?id=CVE-2023-4863
> 
> FWIW, I contacted the assigning CNAs so this can be clarified (e.g. if
> one of those needs to be rejected).

CVE-2023-5129 description looks like what the original's should have been:

> Assigner: Google LLC
> Published: 2023-09-25Updated: 2023-09-25
> 
> With a specially crafted WebP lossless file, libwebp may write data out
> of bounds to the heap. The ReadHuffmanCodes() function allocates the
> HuffmanCode buffer with a size that comes from an array of precomputed
> sizes: kTableSize. The color_cache_bits value defines which size to use.
> The kTableSize array only takes into account sizes for 8-bit first-level
> table lookups but not second-level table lookups. libwebp allows codes
> that are up to 15-bit (MAX_ALLOWED_CODE_LENGTH). When
> BuildHuffmanTable() attempts to fill the second-level tables it may
> write data out-of-bounds. The OOB write to the undersized array happens
> in ReplicateValue.
> 
> Vendor
> libwebp
> 
> Product
> libwebp
> 
> Versions
> affected from 0.5.0 before 1.3.2
> 
> Credits
> 
>     Apple Security Engineering and Architecture (SEAR) finder
>     The Citizen Lab at The University of Toronto's Munk School finder
> 
> References
> 
>     https://chromium.googlesource.com/webm/libwebp/+/902bc9190331343b2017211debcec8d2ab87e17a
>     https://chromium.googlesource.com/webm/libwebp/+/2af26267cdfcb63a88e5c74a85927a12d6ca1d76

Alexander

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.