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

[ssokolow]

But video conferencing would encode your local stream, not something crafted by a 3rd party...
But the CVE is not about browsers, it's about libvpx encoding something from an html element. Not sure why you'd enable that. At least not by default. Then again, I did not read the whole CVE, maybe it's all explained in there, somewhere.

I think they're talking about HTMLCanvasElement.captureStream() and the corresponding methods on the video and audio tags, which were likely intended for stuff like doing OBS-style "Twitch streamer composited into the corner of the footage" compositing in the browser.

[bug77]

That's what you get when you bake the building blocks for video conferencing into the browser.

But video conferencing would encode your local stream, not something crafted by a 3rd party...
But the CVE is not about browsers, it's about libvpx encoding something from an html element. Not sure why you'd enable that. At least not by default. Then again, I did not read the whole CVE, maybe it's all explained in there, somewhere.

[ssokolow]

Wait, what? A web page that tells my browser to encode things? Wth? I mean, it's possible, technically, but who really visits page that make them encode video?

That's what you get when you bake the building blocks for video conferencing into the browser.

[aviallon]

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

Or even better, formally proven to be safe (using Prustli for instance).

[cl333r]

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

Wow, thanks.
I heard of Zig, for some reason I thought it's a toy language for low level stuff. But now that I see that structs can have methods... it's very close to what I actually wanted (Rust without ownership). And from what I read it has plenty of (unexpected to me) cool stuff thanks to being a new modern language on top of modern compiler stacks.

[bug77]

CVE-2023-5217 is due to a heap buffer overflow within the VP8 encoding path in libvpx used by Google Chrome.

Ok, this makes sense. Send a malicious sequence to the encoder, it craps out, you get to where you're not supposed to.

ith prior Chrome versions and pre-1.13.1 for libvpx, a remote attacker could potentially exploit heap corruption via a specially crafted HTML page.

Wait, what? A web page that tells my browser to encode things? Wth? I mean, it's possible, technically, but who really visits page that make them encode video?

[ssokolow]

https://www.reddit.com/r/rust/commen..._windows_font/
The link in the article is from "learn.microsoft.com" and the code example is dissected well by the redditors. I'm sure MS is looking at Rust and if that's the right tool to help correct the issues (the fonts parser was 0-dayed 3 times) then good on them.

The source I'm remembering was a talk being given by a Microsoft employee.

[gavron]

...
Likewise, I can't remember if it's shipped yet, but Microsoft was rewriting Windows font parsing in Rust last year.

https://www.reddit.com/r/rust/comments/ydey12/microsoft_seems_to_ship_rust_code_in_windows_font/

The link in the article is from "learn.microsoft.com" and the code example is dissected well by the redditors. I'm sure MS is looking at Rust and if that's the right tool to help correct the issues (the fonts parser was 0-dayed 3 times) then good on them.

I'll save my criticism on how this ever passed code review (see reddit comments) or why MS chose to change the source language rather than just fire the coder and put someone competent on it. It's a simple iterative search and is done every day by everything from SQL queries to 'ls', 'dir', etc. without a 0-day hole. But then, the #1 attack vector target that has directly lead to the malware/ransomware industry is MS Windows.

[ssokolow]

What a tangled web of canned worms you weaved there ;-)

Tools are instruments we select and use to make our task "better" by some metric. "Better" could mean faster, more reliable, more replicable ("repeatable"), cheaper, documentable, etc. The selection of the tool and the method of its use is typically done by the person performing the task. That would mean that a programmer chooses his/her tools.

YOU have implied that YOU prioritize "memory-safe languages" [hyphen mine] and in so doing YOU prioritize that over other potential project goals such as, for example, codebase size, internal comments and documentation, supportability*, and price.

Fundamentally, good coding technique, rigor, and training are more important in all languages --computer or not-- --compiled or assembled or machined-- wihout regard for the choice of compiler or language used. There's nothing wrong with C, C++, C#, BCPL, Rust, etc. Some of these lend themselves to obfuscation. (See e.g. the annual obfuscated C contest). Some do not. Either way, it's the choice of the programmer just like it's the choice of the digging crew which earth excavating machine to use based on the specific project requirements.

Whatever tool (language, compiler, IDE) you choose, maintain a docuemtation cadence so everything is documented to the max. Just because you prefer a shovel doesn't mean the guy who comes behind you with a backhoe will know where not to dig up buried fiber-optic conduit...

E

* I'm sitting here at a lunch table with three other guys, all experienced coders all making very nice six-figures a year. Your comment (above) got a chuckle and some nods but nobody said "Oh yeah I'll switch all my coding to rust." There was no explicit "I won't use rust" but the concensus was that we'll use the right tool for the job.

Funny stance, given that we're already seeing browsers slowly migrating their parsers/codecs into memory-safe languages because they're one of the biggest attack surfaces. (What with being the boundary where you ingest and validate/sanitize untrusted input and all.)

One of the less talked-about things in Mozilla's Oxidation effort is that the very first Firefox component to be rewritten in Rust was the MP4 parser, back in 2017.

Likewise, I can't remember if it's shipped yet, but Microsoft was rewriting Windows font parsing in Rust last year.

[gavron]

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

What a tangled web of canned worms you weaved there ;-)

Tools are instruments we select and use to make our task "better" by some metric. "Better" could mean faster, more reliable, more replicable ("repeatable"), cheaper, documentable, etc. The selection of the tool and the method of its use is typically done by the person performing the task. That would mean that a programmer chooses his/her tools.

YOU have implied that YOU prioritize "memory-safe languages" [hyphen mine] and in so doing YOU prioritize that over other potential project goals such as, for example, codebase size, internal comments and documentation, supportability*, and price.

Fundamentally, good coding technique, rigor, and training are more important in all languages --computer or not-- --compiled or assembled or machined-- wihout regard for the choice of compiler or language used. There's nothing wrong with C, C++, C#, BCPL, Rust, etc. Some of these lend themselves to obfuscation. (See e.g. the annual obfuscated C contest). Some do not. Either way, it's the choice of the programmer just like it's the choice of the digging crew which earth excavating machine to use based on the specific project requirements.

Whatever tool (language, compiler, IDE) you choose, maintain a docuemtation cadence so everything is documented to the max. Just because you prefer a shovel doesn't mean the guy who comes behind you with a backhoe will know where not to dig up buried fiber-optic conduit...

E

* I'm sitting here at a lunch table with three other guys, all experienced coders all making very nice six-figures a year. Your comment (above) got a chuckle and some nods but nobody said "Oh yeah I'll switch all my coding to rust." There was no explicit "I won't use rust" but the concensus was that we'll use the right tool for the job.