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

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

Yeah, is it trying to mine bitcoin or something? Anubis usually takes a second but here I waited a minute and got 20% through on a modern phone.

happy to report my bots have no trouble with anubis or any other pow mechanism, little bit of deno and i'm right through.

Took less than a minute in my 5 year old xiaomi phone. It did take way longer than other Anubis sites I've seen.

Yeah, it's painful.

I get this crap when browsing on desktop a lot as well, principally because I stubbornly use Firefox as my main browser, and I habitually use a VPN when I connect my laptop to unsecured or even secured-but-accessible-to-large-numbers-of-people WiFi networks.

Like, seriously, bot detection "specialists", fuck off: I'm not a bot but your bot detection software IS shit, and I DO resent your shit software draining my battery and getting in my way. Learn to do your jobs properly, will you?

And don't come crying to me about how the problem you're trying to solve is "hard". I don't care: you chose it, you chose to considerably worsen the web browsing experience of millions of people globally, nobody made you. So go and find a different job if you're incapable of doing the one you have.

And if it's so "hard" why does your entire solution seem to be predicated on anyone's a bot if they're not running Chrome, or they are running an adblocker, or they appear to be from an unusual country that doesn't match their system language? Seriously, is this the level of sophistication you hacks operate at? To solve your "hard" problem?

You are extremely lame. Get out of my way.

This is where I believe strong typing (like, Haskell-strong or stronger) and functional programming in general will be a win. The confidence I have that my fixes are localised when fixing Haskell code is infinitely stronger than fixing even Java, not speak about C, code.

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.

The missing part of this is that verifying the bug with LLMs is also easy, and so is adversarially reviewing the proposed fix with LLMs.

The only thing left for you to do should be directional decisions. The LLMs should pause and rope you in if the fix involves directional/invariant changes.

Often rounds to free compared to human costs.

It's not even like fuzzers are valuable because of the process they use specifically either; the value is that they produce a concrete input that you can use as a reproducible test case at that point. The value could be produced by gazing into a crystal ball for all I care, as long as I can use what it gives me to reproduce a bug.

A.I. is useful for this. But it would be even more useful if all new code were written in Rust or some other memory-safe language.

A.I. could also be used to port C/C++ codebases to Rust, which isn't economically feasible at the moment.

Unfiltered models will help build exploits for the bugs they find, so there is some means of measuring their efficacy.

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.

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.

It's possible, just extremely difficult.

You're kind of saying the only way to do it is in software or hardware :)

An alternative https://en.wikipedia.org/wiki/Projectively_extended_real_lin...

The projectively extended real line defines division by zero, no reason you couldn't have a floating point type that implemented it.

>There's no viable way to statically prove at compile-time that these variables will never become zero at runtime

strongly typed programming languages like Ada allow for types which have ranges such as disallowing zero -- but also any arbitrary thing like you can create a floating point "degrees" type which is [0.0, 360.0] or any other ranged type

Understatement of the year. Almost everything that processes video uses ffmpeg.

Where?

They only suggested a basic guard, chich can be useless if this case never happens

It’s obviously Claude 69 with time travel functionality, that’s too dangerous to release to public. They’re working on space-time limiting sandbox to prevent these issues.

I wonder from where Claude stole this fuzzer.