[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8mV5LGBhbFHo+u7j7xWGbKS5_tOPiGA=1XhwCg65-Dj3A@mail.gmail.com>
Date: Fri, 29 Sep 2023 14:29:17 -0400
From: Jeffrey Walton <noloader@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2023-5217: Heap buffer overflow in vp8
encoding in libvpx
On Thu, Sep 28, 2023 at 5:10 PM Demi Marie Obenour
<demi@...isiblethingslab.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
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.
