Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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

  • it's widely used but in "industry" applications. so ffmpeg is probably being used in a lot of offices (studios) and maybe even being included in end user software.
  • Why are people upvoting a unexploitable bug? How is this interesting? There are thounds of these, no one even reports them unless they are exploitable, DoS only.
  • Because the fuzzer was vibe coded and stolen by Claude! They only need the headline for celebrating another "AI victory" on Twitter, even though the issue was found in 2024 by OSSFuzz:

    https://ffmpeg.org/pipermail/ffmpeg-devel/2024-November/3355...

    by 21wa
  • 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.
  • It is interesting that FFmpeg has its own Git server. Maybe we should move there too?
  • You can add several remotes to your git, and I'd recommend you do so.
    by sva_
  • Lots of projects run their own git or forgejo or similar. I run my own private forge, and it has a higher uptime than GitHub. (A shockingly low bar, tbh)

    It’s surprisingly simple to setup, and the hardware requirements are pretty small for a private or small forge, as it’s usually a relatively small number of users/repos/etc.

  • > It is interesting that FFmpeg has its own Git server. Maybe we should move there too?

    Git is a DVCS. I know many people only ever used Git through Github and forgot what the 'D' in DVCS means but whether or not they remember what the 'D' stands for, running your own Git server is trivial. Especially in this day and age of LLMs were you can just ask: "Clone this repo and convert it to base Git repo and serve it on the LAN PLZ KTHX".

    The result is going to be more stable than Github and, arguably, more secure too.

  • 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.

  • 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

    It seems like this would have been pure fantasy not that long ago though. So why isn’t it noteworthy again? I don’t really follow what you’re complaining about.

  • Not that it doesn’t have issues, but I’m not sure why you’d choose tmux of all things. It runs as a user and has no privileges to escalate. It was written for and is part of OpenBSD and follows their security hardening practices.

    (There actually was one privilege escalation bug in tmux, but it actually seems like a distro packaging error. The distro setgid the executable so the resulting shell inherited the additional group. This didn’t require any exploit, that’s just how child process inheritance works.)

  • I don’t think tmux is the most worthwhile target because you’d need the user to either execute code locally (thus negating any point in targeting tmux) or rely on the user curl or cat some compromised document (in which case you’re better off targeting curl or cat).
  • I am sure the fuzzer is interesting.

    But this bug feels like something an LLM would flag as a major finding but turns out to be completely benign.

    Update: I tried to look into the fuzzer but it is hard to get past the AI blabb. Can someone please explain to me what it does beside being structure aware?

  • It crashes because of input that should have been rejected for being invalid. How could that be construed as being benign?
  • 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.
  • Not custom. It's an existing module for a format called VPK. It's a quite trivial bug though, not exploitable apart from DOS and won't ever happen in a real file.
  • 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.

  • I mean there could be a guard clause? But yeah, seems like this could be statically evaluated like how some IDEs see a null check and don’t complain about nullability within the same scope.
  • If it's possible for program execution with some particular input to lead to a divide-by-zero, that's a bug, especially if the program is expected to be able to handle malformed inputs, or perhaps even deliberately malicious ones. It's not trivial to determine whether a program does this correctly. If it was, program analysis would be easy.

    Division can 'go wrong' for certain inputs, but it's not just division. In C, signed integer addition, subtraction, and multiplication, all give undefined behaviour on overflow.

    As 'Someone' already pointed out, it's not helpful to just flag all uses of the division operator, or of other potentially dangerous operators. Minimising false positives is one of the core challenges of program analysis.

  • What are you suggesting and how would it be different than how SIGFPE already works?
  • Fuzzers find inputs, not just "potential" errors that aren't triggerable.
  • > but can't you just mark all "/" as potential divide by zero errors?

    If you’re accepting large false positives rates: yes.

    If you want users to take your warnings serious: no.

    (Nitpick: you certainly don’t want to flag _all_ of them. Divisions by non-zero constants definitely should be excluded, for example (integer division by -1 can lead to overflow, but that would be a different warning))

  • Am I missing something? Who cares? This isn't a security issue, it's just an unexploitable crash on bad data.
  • everyone knows HN only accepts security write-ups /s
  • No, you're not. It's a minor bug, probably with an easy fix, that deserves to be fixed. It's not worthy of front page HN...
  • that’s the issue with these newer models. they are able to string together a sequence of “not-serious” bugs in a system that ultimately results in some serious vulnerabilities.

    it may not be an issue for ffmpeg, but it might be for an application that bundles ffmpeg.

  • Two months and 1100+ commits to rediscover a bug that was already found in 2024 is probably the funniest possible ending to a "vibecoded fuzzer" story.
  • No, the funny thing is that this comment is comming from an account with 1 karma, no submisions and only 1 comment, I wonder if this is your only account and you just came to spill hate or you are using multiple accounts to discredit other peoples work.
  • 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.