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) Does anyone know how far back libvpx is affected ? Asking because seamonkey-2.53.17.1 is apparently shipping a version of libvpx-1.7.0 from 2020 and I'm told it no longer builds against system libvpx-1.13.1, although a recent version apparently built against libvpx-1.11.0.
ĸen -- Men marched away, Vimes. And men marched back. How glorious the battles would have been that they never had to fight! -- Jingo
On 9/28/23 11:37, Alan Coopersmith wrote: It does not appear that libvpx 1.13.1 has been released yet, It was released yesterday, with the note:
"This release contains two security related fixes. One each for VP8 and VP9."
https://github.com/webmproject/libvpx/releases/tag/v1.13.1
CVE-2023-44488 has been assigned to the VP9 bug:
"VP9 in libvpx before 1.13.1 mishandles widths, leading to a crash related to encoding."
https://www.cve.org/CVERecord?id=CVE-2023-44488
It points to this commit for the fix:
https://github.com/webmproject/libvpx/commit/263682c9a29395055f3b3afe2d97be1828a6223f
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Last updated 24 July 2024
On Thu, Sep 28, 2023 at 05:10:09PM -0700, nightmare.yeah27 () aceecat org wrote: On Thu, Sep 28, 2023 at 04:42:33PM -0400, Demi Marie Obenour wrote: 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? Wouldn't the low-level code have to ultimately depend on unsafe Rust modules, or similar feature in other safe language? In Wuffs, every memory access is checked for safety at compile-time, and that includes being in-bounds. If the compiler cannot prove that every access is safe, the code will not compile. There are no bounds checks at runtime.
Interfacing with hardware accelerators obviously will need unsafe code, but my understanding is that most vulnerabilities are in various parsers or in the code the accelerators replace, not in the code that interfaces with the accelerators. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
On Thu, 2023-09-28 at 16:42 -0400, Demi Marie Obenour wrote: 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? How long will it take for rust to quit changing the language, standardize itself, and enforce some notion of API/ABI stability? The thing we've already had with C and C++ for decades? As a result of the language's instability (and their attempt to hide it with a "package manager"), every rust package wants to install a gigabyte of bundled dependencies that are all pinned to old versions.
Software engineering is a fractal. Memory safety inside a language is obviously desirable, but not if other design choices force everyone to go back to bundled libraries and static linking. The state of rust is that it's fun to write, but awful to use. If you want me to switch from C to another language, then projects written in that language can't be a nightmare to distribute and maintain.
The situation is identical to how, ten years ago, we were going to rewrite everything in Haskell. Haskell has the same pro/con list as rust. But they never figured it out either. Every new release broke a ton of code, and so version constraints became so tight that you couldn't install more than a few programs at once without bundling. The resulting treadmill was never-ending. Once "this is cool!" wore off, everyone was left with "this is a waste of time."
Maybe someone at $corporation has figured out that rust is wasting their time.
On Thu, Sep 28, 2023 at 04:42:33PM -0400, Demi Marie Obenour wrote: 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? Wouldn't the low-level code have to ultimately depend on unsafe Rust modules, or similar feature in other safe language?
-- Ian