3 ms·
https://x.com/FFmpeg/status/2006773495066464580 https://x.com/FFmpeg/status/2006773495066464580 > Seeing as this has made the orange site, let it be known this
by helge9210 9mo ago
https://x.com/FFmpeg/status/2006773495066464580 https://x.com/FFmpeg/status/2006773495066464580
> Seeing as this has made the orange site, let it be known this person is a model security researcher.
> The issue was not in any FFmpeg release, and a report was sent three days after a new code was added to FFmpeg Git.
> There was no big CVE ADVISORY "MUH SECURITEH" "you need to fix this now or you will be hacked and the world will end" associated with the report.
- bgwalter 9mo agoThis is another drawback of security research, but one that had already existed before "AI" with ossfuzz. You basically cannot commit in public to the main branch and audit and test everything 3 months before a release, because any error can be picked up, will be publicized and go into the official statistics.
- nospice 9mo ago> ... go into the official statistics. There are no "official" statistics. None of this matters. If we judged projects by the number of security holes they had, then no one would be using ffmpeg, which had hundreds of serious vulns. Vulnerability research is useful insofar that the bad guys are using the same techniques (e.g., the same fuzzing tools), so any bugs you squash make it harder for others to attack you. If your enemy is a nation state, they might still pack your laptop / phone / pager with explosives, but the bar for that is higher than popping your phone with a 0-day. Vulnerability research is demonstrably not useful for improving the security of the ecosystem in the long haul. That's where sandboxing, hardening, and good engineering hygiene come into play. If you're writing a browser or a video decoder in C/C++, you're going to have exploitable bugs.
- toast0 9mo ago> Vulnerability research is demonstrably not useful for improving the security of the ecosystem in the long haul. That's where sandboxing, hardening, and good engineering hygiene come into play. If you're writing a browser or a video decoder in C/C++, you're going to have exploitable bugs. IMHO, vulnerability research is the stick that drives the ecosystem towards all those things. Reports of vulnerabilities in the codec for Rebel Assult videos (or whatever) leads one to disable codecs other than those they need. Reports of vulnerabilities in playlist support leads one to disable playlist support where it's unnecessary and run transcodes in a chroot sandbox with no network access. Reports of buffer oveflows leads one to prefer implementation in memory safe languages where available with sufficient performance and also to sandbox when possible.
- tptacek 9mo agoI mostly agree, and further would say that this doesn't really conflict with the preceding comment.
- BobbyTables2 9mo agoIt’s the projects without CVEs that scare me. Because nobody’s even looking…
- viraptor 9mo agoDid you prefer this bug to go unnoticed until it's released to everyone, and only then fixed in a hurry, requiring another release? Why?
- GaryBluto 9mo agoIs the FFmpeg Twitter account managed by a developer's teenage son? No matter what point that they try convey, it's always stated in an obnoxious manner.
- bgwalter 9mo agoMaybe they should hire Mario Nawfal for their announcements: """ BREAKING: AI FOUND VULNERABILITY IN FFMPEG! After decades of human struggle, humans no longer call the shots. Pwno decided to take the leap. They did not just find a vulnerability---they found a BOMBSHELL! What took developers weeks to write, AI analyzed in SECONDS! """
- throawayonthe 9mo agoit's kinda charming