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

[Salvatore Bonaccorso <carnil () debian org>]

Hi,

On Tue, Sep 26, 2023 at 05:34:54PM +0200, Solar Designer wrote:
> 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

An update on this: CVE-2023-5129 has now been rejected.

> Rejected Reason: This CVE ID has been rejected or withdrawn by its CVE
> Numbering Authority. Duplicate of CVE-2023-4863. 

Regards,
Salvatore