[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZRU5efsKAQYM874Z@eldamar.lan>
Date: Thu, 28 Sep 2023 10:29:45 +0200
From: Salvatore Bonaccorso <carnil@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2023-4863: libwebp: Heap buffer overflow in
WebP Codec
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
Powered by blists - more mailing lists
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.
