VP8/VP9's libvpx 1.13.1 Released Due To A High Severity Vulnerability

[phoronix]

Phoronix: VP8/VP9's libvpx 1.13.1 Released Due To A High Severity Vulnerability

Google on Friday released libvpx 1.13.1 as the newest update to this open-source reference encoder for the VP8 and VP9 video codecs. This release is coming due to CVE-2023-5217, which is a "high" severity vulnerability that's been exploited within at least the Google Chrome web browser...

https://www.phoronix.com/news/libvpx-1.13.1-VP9

[peterdk]

I expect that in the long run people/companies will require that codecs are written in memory safe languages.

[cl333r]

I expect that in the long run people/companies will require that codecs are written in memory safe languages.

And then people will fight over what to consider a memory safe language and what are the requirements to qualify for a good language to write codecs in.

[juxuanu]

Easy: Rust.

[ssokolow]

And then people will fight over what to consider a memory safe language and what are the requirements to qualify for a good language to write codecs in.

I'm looking forward to seeing success on google/wuffs#38 so I can have the Wuffs transpiler generate Rust instead of C and have the best of both worlds. (The better-than-existing-Rust-solutions speed of existing examples of parsers written in Wuffs and the stronger safety of a DSL written specifically for safe parsing, without the cgo-esque annoyances and complications that show up as soon as C dependencies are added to a Rust project. (eg. it's much easier to cross-compile a Rust project with no C dependencies beyond libc.)

[Quackdoc]

Firefox was effected too, and man, their advisories really need to be touched up on. it certainly made is sound a lot more scary then it was with lots of people thinking that a maliciously encoded video file could trip it.

Specific handling of an attacker-controlled VP8 media stream could lead to a heap buffer overflow in the content process. We are aware of this issue being exploited in other products in the wild.

[pWe00Iri3e7Z9lHOX2Qx]

I'm surprised this Google lib story was covered but the absolute clusterf*ck around the libwebp vulnerability wasn't.

https://arstechnica.com/security/2023/09/google-quietly-corrects-previously-submitted-disclosure-for-critical-webp-0-day/

They originally said it was only a vulnerability in Google Chrome, but it was really in libwebp, and a crap ton of software was effected (Firefox, Thunderbird, LibreOffice, hell most apps that support webp because they all use that library). It was being actively exploited by a nation state to install NSO's Pegasus spyware on a targeted individual's iPhone. Distros were scrambling to patch things quickly.

There's an interesting write up about how the vulnerability works here:

https://blog.isosceles.com/the-webp-0day/

[cl333r]

I'm looking forward to seeing success on google/wuffs#38 so I can have the Wuffs transpiler generate Rust instead of C and have the best of both worlds. (The better-than-existing-Rust-solutions speed of existing examples of parsers written in Wuffs and the stronger safety of a DSL written specifically for safe parsing, without the cgo-esque annoyances and complications that show up as soon as C dependencies are added to a Rust project. (eg. it's much easier to cross-compile a Rust project with no C dependencies beyond libc.)

I did program in Rust for like a year and while initially a big fan, eventually I came to the conclusion that I'd much prefer a new successor to C++ which hopefully Carbon will be.

Though Rust in its own right is a good lang that easily gets out of control.

[M@yeulC]

pWe00Iri3e7Z9lHOX2Qx so you are telling me this is yet another vulnerability? Otherwise yeah, poorly disclosed and coordinated.

I did program in Rust for like a year and while initially a big fan, eventually I came to the conclusion that I'd much prefer a new successor to C++ which hopefully Carbon will be.

Though Rust in its own right is a good lang that easily gets out of control.

If you are looking for a C/C++ successor, Zig has gained quite a bit of traction in some fields like embedded.

I'm looking forward to seeing success on google/wuffs#38 so I can have the Wuffs transpiler generate Rust instead of C and have the best of both worlds. (The better-than-existing-Rust-solutions speed of existing examples of parsers written in Wuffs and the stronger safety of a DSL written specifically for safe parsing, without the cgo-esque annoyances and complications that show up as soon as C dependencies are added to a Rust project. (eg. it's much easier to cross-compile a Rust project with no C dependencies beyond libc.)

What's the advantage of generating Rust code? The original language needs to be memory-safe as well (unless it's leaning on the Rust compiler, bit in that case you're almost writing Rust already). If you have that, you can directly generate LLVI IR or whatnot (even the C code should be safe...).

[ssokolow]

I did program in Rust for like a year and while initially a big fan, eventually I came to the conclusion that I'd much prefer a new successor to C++ which hopefully Carbon will be.

Though Rust in its own right is a good lang that easily gets out of control.

I use Rust as "A replacement for Python with stronger compile-time type-safety guarantees, easier deployment, and an ecosystem more ideologically aligned with 'if it compiles/installs/works today, it'll continue to do so in five or ten years" (and I think of it as "Haskell without the bad parts"), I'm a liberal use of #![forbid(unsafe_code)] in my own projects, and I have high standards for what I consider acceptable use and responsible implementation of unsafe in dependencies I choose to add to my project.

I think C and assembly language are the only things further from what I'd want to use in my general day-to-day programming than C++ and Carbon. (Bear in mind that I say "in my general day-to-day programming". I do use Open Watcom C/C++ for DOS retro-hobby programming.)