141–150 of 216 posts
> A victim only has to run ffmpeg -i rtsp://attacker/stream, the most ordinary command imaginable What about "ls"?
Again there is another vulnerability caused by unchecked addition, and still modern languages like Rust or Go do not raise exception on overflow, and modern CPU architectures like RISC-V provide no overflow traps. And older languages like C or C++ do not have overflow checks also.
Ridiculous. It is obvious that humans cannot be trusted with writing correct arithmetics code.
Earlier quoted context omitted.
If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?
No. They tried that with coreutils and look what happened. More CVEs. 99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.
Earlier quoted context omitted.
If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?
No. They tried that with coreutils and look what happened. More CVEs. 99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.
In contrast, ffmpeg is exactly the sweet spot for a memory-safe language with those complex decoders operating on data which is often untrusted. I wouldn’t suggest a project of that scale lightly but it’s at least a near-perfect fit on the problem domain.
> DFVULN-123 (Integer Overflow): In the RTP LATM depacketizer (rtpdec_latm.c), latm_parse_packet() performs a signed 32-bit addition that overflows and bypasses its bounds check Again there is another vulnerability caused by unchecked addition, and still modern languages like Rust or Go do not raise exception on overflow, and modern CPU architectures like RISC-V provide no overflow traps. And older languages like C o…
Rust doesn't raise overflow by default. But you can just 123.checked_add(321). Now your code is unreadable, but it's overflow safe.
Honestly, based on the way I write code I'd rather something like an end of line comment. Like:
var x = y + z; # wrapped
Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... So, while it's a demo of the capabilities of LLMs, this should not be at all surprising.…
Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... So, while it's a demo of the capabilities of LLMs, this should not be at all surprising.…
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.
Now, personally, when I file a bug report for a FOSS project I like to suggest an underlying cause and fix if I can figure it out, but I more rarely just submit a PR outright.
Earlier quoted context omitted.
Explain what it means along with your statement. Maybe I have the wrong definition too.
(not op) If a security bug is exploited in the wild, it's an n-day if it's been first exploited n days after the publication of the bug, and a zero-day if it's been exploited before or on the day of the publication. When a bug is not yet exploited in the wild, it's just a discovery of a bug, not a zero-day.
Earlier quoted context omitted.
No. They tried that with coreutils and look what happened. More CVEs. 99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.
coreutils was a category error: they took a set of tools which were not very exposed to memory safety errors and rewrote them in a language which does nothing to prevent the kind of logic errors coreutils has suffered from (mostly races around file operations). It’s like complaining that an airbag didn’t save you after driving into a lake. In contrast, ffmpeg is exactly the sweet spot for a memory-safe language with…
Earlier quoted context omitted.
> … hostile to security researchers who report these issues. Do you have an example?
I don't have an example, but I know the pattern. You are working on your software, security researcher finds a bug, it's in your project, for you it's just another bug, but for them it's a point on their CV, so they make a theater about it, and expect priority in dealing with it. It must get tiring if you get many of these.