Re: CVE-2023-5217: Heap buffer overflow in vp8 encoding in libvpx

[Jeffrey Walton <noloader () gmail com>]

On Thu, Sep 28, 2023 at 5:10 PM Demi Marie Obenour
<demi () invisiblethingslab com> wrote:
> On Thu, Sep 28, 2023 at 11:37:23AM -0700, Alan Coopersmith wrote:
> > Google has announced another media parsing bug, this time correctly documenting
> > both the base library and Chrome versions affected in the CVE.
> >
> > https://www.cve.org/CVERecord?id=CVE-2023-5217 states:
> >
> >    Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to
> >    117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially
> >    exploit heap corruption via a crafted HTML page.
> >    (Chromium security severity: High)
> >
> > Unfortunately, the bug report it points to is restricted access still:
> > https://crbug.com/1486441
> >
> > But the Chrome release notes state:
> >    Google is aware that an exploit for CVE-2023-5217 exists in the wild.
> > https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_27.html
> >
> > Mozilla has put out their own security advisory at
> > https://www.mozilla.org/en-US/security/advisories/mfsa2023-44/
> > and delivered fixes in Firefox 118.0.1, Firefox ESR 115.3.1,
> > Firefox Focus for Android 118.1, and Firefox for Android 118.1.
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1855550 is also still
> > restricted access.
> >
> > It does not appear that libvpx 1.13.1 has been released yet, but there
> > are two commits in its git repo with the 1486441 bug id listed:
> >
> > https://github.com/webmproject/libvpx/commit/3fbd1dca6a4d2dad332a2110d646e4ffef36d590
> > https://github.com/webmproject/libvpx/commit/af6dedd715f4307669366944cca6e0417b290282
> >
> > Mozilla's commit references these two libvpx commit ids as well:
> > https://hg.mozilla.org/mozilla-central/rev/c53f5ef77b62b79af86951a7f9130e1896b695d2
>
> How long will it take for corporations to accept that writing media
> codecs in C, C++, or any other memory-unsafe language is a fundamentally
> bad idea, and that it is better to rewrite the codecs in a safe language
> (such as Wuffs or Rust) than to try to secure the existing ones?

Small nit... Folks would lose a lot of platforms by selecting Rust.
Rust is only guaranteed to work on a handful of platforms. At this
time, it looks like it is i686 and x86_64. Confer,
<https://doc.rust-lang.org/nightly/rustc/platform-support.html>.

And that's been my experience with Rust. For a new project I worked
on, Rust only worked on x86_64. It could not compile its own cargos on
armv7, aarch64 or powerpc. We had to (re)start a project from scratch
after that. And it got written in C, though we should have done it in
C++. We lost so much time due to Rust we did not have the cycles to
move from C to C++.

Jeff