alt Hacker NewsWe found a division by zero bug in FFmpeg with a vibecoded fuzzer
Comments
It’s interesting how AI may both raise and lower the quality of software. It’s very easy to send an AI agent on an open-ended bug hunt, and if it wastes a bunch of time and effort and finds nothing, no big deal. Time is much more important for a human developer with a salary.
Whatever about the specifics of this bug and whether its a useful vector, this is not surprising even in the slightest?
My current opinion on LLMs is that they are superhuman in that they lack fatigue, they have close to full knowledge across all subjects which are known to humans at least publicly, and the fact that you can vibe code a harness to look for bugs in a famously complicated C codebase is intern level stuff and hardly news.
Smart aspiring blackhats will be targeting tmux next, both with light llm jailbreaks, light supply chain attacks (web search results) and LPEs within certain environments which weren't particularly useful before but with agents running on auto mode for hours become a very valuable springboard. I'm not sure on the quality of tmux code but I know its written in C and is very complex and was not at all designed to defend against this type of threat.
This is not a real bug in FFmpeg. This is a demonstration that if you control a custom AVIO module it is possible to crash FFmpeg by giving it bad data.
No doubt fuzzers (vibecoded or otherwise) can be powerful, but can't you just mark all "/" as potential divide by zero errors?
I guess sometimes developers think they "know" some variable won't be zero, but unless it checked explicitly or by the compiler, that shouldn't be trusted.
Am I missing something? Who cares? This isn't a security issue, it's just an unexploitable crash on bad data.
It is interesting that FFmpeg has its own Git server. Maybe we should move there too?
Funny thing, I know I'm brushing up against something in gStreamer developer, but Fable flips out. I have only a loose idea where the issue might be lurking.
Next week, I'll apply for the cyber and I suspect I'll find something similar.
Right now, it's just annoying and thanks the OpenAI cyber was much easier to get access to.
Why submit an issue rather than just making the fix and adding the tests in PR? Seems like they're just making work for the maintainers.
What we need is a numeric type that cannot be zero.
note that this seems to be a bug in what i expect (feel free to correct me) is a code path for a little-used codec
maybe we'll just see them remove support for these long-tail formats the way linux has been removing drivers for similar reasons https://www.phoronix.com/news/Linux-Retiring-Moxa-Driver
I find it pretty cool that a fuzzer thrown together this way actually found a bug in ffmpeg
The README for the fuzzer is an AI slop mess. https://github.com/daedalus/fuzzer/
I imagine the discussion will center around this application of AI, but to me this is just the Nth proof of the proven fact that you must build ffmpeg, if you insist on using it, with only an allow-list of file formats that you expect to encounter, and not with the kitchen sink of stuff you are never going to need.
Generating an incorrect input file seems to be the easiest task of all for any fuzzer.
Generating correct input to get deep into the call stack and then finding something is the hard part.
[dead]
But guys... AI is bad. It might have done good stuff today, but we should be anti data. The Chinese propagandists on United States social media told me to.
Nice find. The interesting part isn't "AI wrote the fuzzer." It's that a cheap random harness still hits classical bugs in ancient parsers. Keep the corpus; throw away the hype.
The fruits of using LLMs to code. You'll waste far more time finding what it quietly and subtly wrecked than you would have if you just coded it yourself.
A patch for this was submitted in April: https://lists.ffmpeg.org/archives/list/[email protected]...
Edit: And there was discussion about this back in 2024 as well