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

[Jeffrey Walton <noloader () gmail com>]

On Tue, Sep 26, 2023 at 11:37 AM Solar Designer <solar () openwall com> wrote:
> 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.

Crypto++ caught a CVE because use of -DNDEBUG was not documented. The
library's build system used -DNDEBUG (like libwebp), but folks who
ported to other build systems did not use it. In my mind's eye, others
who did not use the -DNDEBUG flag should have caught a CVE, not
Crypto++. Also see CVE-2016-7420 and
<http://seclists.org/oss-sec/2016/q3/520>.

Crypto++ eventually took away the footgun by supplying its own
CRYPTOPP_ASSERT that required a user to supply a switch to engage
asserts. Asserts were no longer enabled by default when someone
omitted -DNDEBUG. Also see
<https://github.com/weidai11/cryptopp/blob/master/trap.h>.

I've never seen a CVE for documentation before or since.

Jeff