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

We found a division by zero bug in FFmpeg with a vibecoded fuzzer

code.ffmpeg.org

Post reply on HN
Print view View original

111–120 of 274 posts

Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer

#111

Post by UltraSane »

simonjuk wrote: post #78
dabinat wrote: post #2

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.

In my experience, there are two ways to use AI: speed or quality. Speed is where you give the AI a task to do and you review it; quality is where you write the code yourself and you get AI to review it. Both are valid for different situations.

Using a LLM whose output is slowed to the rate of a human programmer as a pair programming partner is a very interesting experience.

Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer

#112

Post by BikiniPrince »

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.

Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer

#113

Post by bartread »

semiquaver wrote: post #108
aeyes wrote: post #91

A patch for this was submitted in April: https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.o... Edit: And there was discussion about this back in 2024 as well

Oddly enough I can’t access that site, it just heats up my phone solving hashes. Gave up after about a minute and anubis had only made it less than halfway through. I doubt the real bots have any trouble bypassing it.

[flagged]

Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer

#114

Post by UltraSane »

evenhash wrote: post #20
dabinat wrote: post #2

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.

> 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. No big deal? It’s not like it’s free… tokens cost money.

When talking about LLM tokens the cost is almost always being implicitly compared to very expensive human developer time.

Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer

#115

Post by yorwba »

aeyes wrote: post #91

A patch for this was submitted in April: https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.o... Edit: And there was discussion about this back in 2024 as well

A patch was submitted, but apparently not merged. That was also my experience trying to submit a patch for https://trac.ffmpeg.org/ticket/8738 . Somebody on the bug tracker took note, but was apparently unable to effect a merge in the intervening years.

Maybe now that ffmpeg is using Forgejo, the ball won't be dropped like this as often. Or there'll just be a five-digit number of open pull requests instead.

Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer

#116

Post by inigyou »

skupig wrote: post #89

Am I missing something? Who cares? This isn't a security issue, it's just an unexploitable crash on bad data.

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

Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer

#117

Post by inigyou »

nh2 wrote: post #105
inigyou wrote: post #94

Earlier quoted context omitted.

OOP has those too, and they're very annoying.

In Haskell they are a little less annoying. It is just easier to reason about (including proving) pure functions.

I meant the constrained types by hiding the constructors. Super annoying, not automatically convertible, in Haskell you have to remember what the fake constructor is called, and write it every time you use it, but at least it's efficiently implemented with newtype, unlike the Java OOP version. Think about writing a value with several nested constrained types, like NonEmptyListOne (makeNonZeroNumber 42, 'h' `NonEmptyString` "ello world"). It's just really annoying.

Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer

#118

Post by post-it »

semiquaver wrote: post #108
aeyes wrote: post #91

A patch for this was submitted in April: https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.o... Edit: And there was discussion about this back in 2024 as well

Oddly enough I can’t access that site, it just heats up my phone solving hashes. Gave up after about a minute and anubis had only made it less than halfway through. I doubt the real bots have any trouble bypassing it.

It also took insanely long on my iPhone 16. "Made with heart in Canada" but configured poorly.

Re: We found a division by zero bug in FFmpeg with a vibecoded fuzzer

#120

Post by justonenote »

jonhohle wrote: post #98
justonenote wrote: post #88

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 stu…

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 additiona…

as I mentioned in another sibling, its because it's a very common denominator in high value targets. I didn't know its legacy was from OpenBSD but I really doubt that that helps it much in this scenario, when I say LPE I'm not talking about user to root elevation, I'm talking parsed text/control sequences to arb code execution in the user context. These will slip past llm classifiers as safe and I'm fairly sure that they are extremely common in codebases like tmux, despite them having strong security posture its just a threat that was previously a bit outlandish and not accounted for.

persisted malicious code running in your tmux process that you don't know about is probably not where you want to be, for obvious reasons.

Post reply on HN