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

141–150 of 274 posts

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

#142

Post by _jackdk_ »

inigyou wrote: post #117
nh2 wrote: post #105

Earlier quoted context omitted.

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' `NonEmptyS…

The blog link I mentioned avoids this cost with literals, by providing using a required type argument to check the string length at compile time without TH. It requires a relatively recent GHC:

    make :: forall symbol -> (IsNonEmptySymbol symbol) => NonEmptyText

    type family IsNonEmptySymbol symbol :: Constraint where
      IsNonEmptySymbol "" = Unsatisfiable (Text "Expected a non-empty string")
      IsNonEmptySymbol _ = (()::Constraint) -- empty constraint is always satisfied

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

#143

Post by timpera »

its-summertime wrote: post #140
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

For those with difficulty accessing: - - - From: Anthony Hurtado vpk_read_packet() divides vpk->last_block_size and (par->block_align - vpk->last_block_size) by par->ch_layout.nb_channels without checking for zero. While vpk_read_header() validates nb_channels > 0, the codec parameters may become zero through format probing misidentification (VPK probe score is 2/3 of AVPROBE_SCORE_MAX) or codec parameter reset, caus…

Thank you! I gave up after more than 2 whole minutes of waiting on a high-end smartphone. I'm not sure this keeps bots out, but it definitely keeps users out…

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

#144

Post by hnlmorg »

justonenote wrote: post #95
hnlmorg wrote: post #92

Earlier quoted context omitted.

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

the point is tmux is being used by many developers working in high value targets to automate long running unsupervised agent tasks. you don't need the user to execute code, you need _their agent_ to stumble on the wrong search result or github repo and it wont be noticed for hours that they loaded a persistent threat into your environment.

That seems even harder to do because an agent wouldnt be output text verbatim, which means you cant make use of a rendering bug (eg parsing escape codes).

So you’re back to depending on the agent to execute code locally. at which point you’ve already compromised the system so don’t need a tmux bug.

I’ve spent a lot of time in tmux. Including writing a frontend for it. So I’m probably more familiar than most. And I hear a lot of people say tmux (specifically) is a vulnerability because it’s written in C. But I struggle to see how it’s any more of a vulnerability than (for example) coreutils. Or any other piece of software for that matter.

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

#145

Post by [deleted] »

rogerrogerr wrote: post #39
evenhash wrote: post #20

Earlier quoted context omitted.

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

Often rounds to free compared to human costs.

[deleted]

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

#146

Post by dclavijo »

Zebfross wrote: post #141

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.

OP here: A bug report just needs a proof of existence for the condition while a bug fix needs a proof of correctness. Sometimes is the best to let the developers who are day to day in the codebase to choose the best fix and if they what to fix it.

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

#147

Post by [deleted] »

bartread wrote: post #113
semiquaver wrote: post #108

Earlier quoted context omitted.

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]

[deleted]

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

#148

Post by hnlmorg »

justonenote wrote: post #120
jonhohle wrote: post #98

Earlier quoted context omitted.

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…

Agent harnesses aren’t going to output ansi escape sequences verbatim to the terminal.

If you wanted to booby trap a repository then you’re far better off with a prompt injection attack.

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

#149

Post by nonethewiser »

adamddev1 wrote: post #79
nonethewiser wrote: post #34

Earlier quoted context omitted.

No one can keep up with the volume of code AI produces. We wont stop using AI. We will use AI to check AI. Of course this is crazy, but it will also unlock pretty insane scaling and productivity and ultimately we will manage it on either end via requirements and tests.

> it will also unlock pretty insane scaling and productivity Insane scaling of bloat, bugs, and technical debt I'd say. > We will manage it on either end via requirements and tests It is so crazy that this is being touted as a sane strategy. When I was a much worse programmer, I tried to write a big complicated string manipulation function to take two types of scripts in a language and add diacritics. I had the requi…

>Insane scaling of bloat, bugs, and technical debt I'd say.

You just described every legacy codebase. Many of which are widely used and do a lot of sales. You dont need a clean codebase to have a valuable product.

>It is so crazy that this is being touted as a sane strategy.

Re-read what I said. I literally called it crazy.

It is the same dynamic that gave us customer service from some call center in India. Why would companies do this? Customer service got worse. Are they stupid? No, it's just worth it. The quality goes down but the business can scale more so it doesnt matter.

AI will absolutely be good enough at doing things that we'll happily accept some jankiness at times so that we can devote an extra 3000 hours per year per person to other things.

Im not even suggesting its a good thing. I just think the incentive structure dictates it. You're not going to have time to maintain a small slice of some service by hand.

Post reply on HN