Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twenty One Zero-Days in FFmpeg

depthfirst.com

Post reply on HN
Print view View original

211–216 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#211

Post by akerl_ »

dspillett wrote: post #210
akerl_ wrote: post #199

Earlier quoted context omitted.

Nobody is obligating open source maintainers to accept or read these reports.

Plenty of people will loudly state that they are irresponsible for not looking into the reports that they send, so while that isn't a direct obligation it is certainly a punishment, via potential reputation damage¹, for not doing so. -------- [1] for example, see comments elsewhere in this thread saying things like "maintainers will if they care "

No matter what you do, there will be some group of people that thinks you’re wrong.

It’s up to each of us to decide which peoples’ opinions we actually care about.

Re: Twenty One Zero-Days in FFmpeg

#212

Post by hulitu »

nemothekid wrote: post #3

> The reach of this bug is what makes it serious. Any deployment that points FFmpeg at an attacker-influenced RTSP URL is exposed: media ingest pipelines fetching user-supplied stream URLs, surveillance and CCTV systems pulling RTSP feeds, and transcoding services processing remote AV1-over-RTP sources Wow this is actually pretty serious - I'm even surprised its being published. There are several services where I can…

> Wow this is actually pretty serious

Don't tranform your ffmpeg instance into a web browser.

Re: Twenty One Zero-Days in FFmpeg

#213

Post by pornel »

uecker wrote: post #169
pornel wrote: post #164

Earlier quoted context omitted.

Additionally, integer overflow is less immediately dangerous in Rust, because buffer access is bounds-checked after the arithmetic. You can still get some logic bugs that eventually lead to vulnerabilities, but it's not an arbitrary memory write gadget.

What convinced me that this is wishful thinking was CVE-2023-53156. Yes, it used "unsafe" but the wraparound in release defeated the manual check, and when you aim for performance comparable to C, Rust tends to be full of unsafe blocks. IMHO better C tooling would be a far better investment than rewriting in Rust.

Incremental/quantitative improvement isn't disproven by contradiction. Anecdote is not data. Look at a bigger dataset, e.g. https://github.com/rust-fuzz/trophy-case there's a ton of overflows that result in caught panics or OOMs, and not bypasses. It works to reduce defect rate and severity.

Note that C's tools for this like Valgrind, instrumented allocators and LLVM sanitizers work with Rust too. Investment in catching these in C generally helps unsafe Rust too, but Rust also has Miri, and a much better baseline for static analysis.

Re: Twenty One Zero-Days in FFmpeg

#214

Post by boomlinde »

duped wrote: post #191
boomlinde wrote: post #79

Earlier quoted context omitted.

I guess that the perceived problem from a security perspective is that they're there, not that they're necessarily hard to fix once found.

The main beef is the noise created around these disclosures instead of sending patches to fix the bugs.

If you quietly patch the vulnerable software it's unlikely that I will ever hear about the vulnerability. CVE disclosure is important because that's how I learn of security problems in software I critically depend on. It's not merely a service to the maintainers, but to the users who might otherwise critically depend on vulnerable software.

Re: Twenty One Zero-Days in FFmpeg

#215

Post by simjnd »

j1elo wrote: post #201
simjnd wrote: post #127

Earlier quoted context omitted.

FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.

Well this is nothing but an obvious expectation given the technical level required for doing good quality contributions, no? I felt this is kinda like there being a large number of people willing to send spam email, but a comparatively minuscule number of people willing to work on ML filters to block it.

You could assume that if someone has the technical level to identify a vulnerability and how to exploit it, they probably have the technical level to fix it.

In most cases researchers have no interest in actually "making the software better" and publishing vulns is just a way to increase their cred to land a better job.

FFMPEG's position as a well know very popular open source project means it's very interesting for this type of researcher to find a vuln and put their name on it.

It's an exhausting dynamic.

Re: Twenty One Zero-Days in FFmpeg

#216

Post by bybrooklyn »

IshKebab wrote: post #166
ivanjermakov wrote: post #139

Earlier quoted context omitted.

Memory safety and critical performance rarely go together. Big chunk of FFmpeg is written in assembly to sqweeze most hardware performance. https://news.ycombinator.com/item?id=43140614

Sure but it seems like most of these vulnerabilities are being found in the C code.

Rust could help with this!
Post reply on HN