Edit: And there was discussion about this back in 2024 as well
- - -
From: Anthony Hurtado <[redacted since hn has no scrape protection]>
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, causing SIGFPE.
Fix by:
- Checking nb_channels != 0 before division in vpk_read_packet
- Returning EOF for empty last blocks (last_block_size == 0)
- Validating block_count > 0 in vpk_read_header
- Validating last_block_size <= block_align in vpk_read_header
Found by fuzzing with libFuzzer + AddressSanitizer. Reproduces with 10 distinct inputs.
[patch redacted for brevity]
Maybe it uses other heuristics like detecting if someone lives in the AI agent world
I doubt the real bots have any trouble bypassing it.
My ungrounded speakers have a tendency to pop and make noise when they come out of sleep (sleep? on a speaker? fuck you logitec) and every time these "simple" CAPTCHAs come up, even if I pass without solving their logic puzzles, I hear the speakers activate as the Javascript on the page is figuring out what kind of audio setup I have by playing a silent sound file.
The default Anubis config isn't really a problem for any devices I've tried, but the FFMPEG Anubis setup is quite extreme. I seem to be served the extra-difficult Javascript challenge, as well as a high-difficulty challenge, that takes even powerful computers quite a long time to complete.
Could just be countermeasures to the hug of death every website gets when they get linked on HN, though, but someone would need to set up auto-scaling for that.
It's near instant on desktop (Windows/FF/7950X3D) and I wouldn't expect the delta to be that large against a modern mobile device.
They're paying for electricity and taking data without paying for it. It seems to me that they're paying for it exactly the same way everyone else in AI did.
This makes no sense to me as in my experience, you click the checkbox and then it verifies you without extra steps.
Having my CPU go up for a while is nearly frictionless on the other hand. Worst case I'm stuck in a loop and the site isn't loaded when I get back to it, which is better than being stuck in a captcha loop and then not getting to the site.
Of course, not having to do any of that would be even better. I wish the concept of ZeroNet had caught on, where everything is hosted and served peer-to-peer. This gives you basically zero hosting costs and you are immune to DDOS.
oh is that why my raspberry pi 5 can't browse websites anymore without freezing for a minute.
> how mild the reactions are to Anubis compared to the people reacting to seeing one singular Cloudflare captcha checkbox
cloudflare requires me to work for them
https://amber.agentic.church/web/lists.ffmpeg.org/2026082807...
Apparently, not the fonts they use for icons.
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.
Unfortunately, if you let all the bots in, they overwhelm your servers, and then nobody can access the website.
I had some git hosting up for a while, and was serving hundreds of qps and several terabytes per month. I can only imagine want significant sites are serving.
Such a non-argument.
I'm expecting people to create better, more effective, and less intrusive anti-bot measures. Measures that accurately detect bots but don't exclude real people from the web simply because of the browser they're using, or the country they either appear to be in or are in fact in, for example.
I've only seen 1 or 2 that know what they're doing. One's at lemmy.world ... just hovering over it is verified ...
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.
I understand why people choose it, but if I see the catgirl I close the tab - same is I get the test from cloudflare.
I was startled by the girl the first time as well, but once I learned what it is, I accepted it. Like a garden gnome on someone's front yard.
Isn't it easier to just .. start loving it instead?
You may want to check upthread how loved it is :)
I, for one, don't hate it, but I hate what it represents and see its existence (rather, the reason for its existence) as a defeat for the web.
(By the way: Jackal, not cat.)
this isnt reddit
Two months and 1.1k+ commits to rediscover an already known bug IS funny. That doesn't mean I hate the person or want to discredit their work. You're reading way too much into a comment :)
The big problem preventing this approach from working for numbers is that it's just so cumbersome there. Most of this is because all the arithmetic operators are bundled into a single Num typeclass, and `fromInteger :: Num a => Integer -> a` has a type that's impossible for a "non-zero number" wrapper to satisfy.
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 satisfiedAgda is the most mature dependently typed programming languae (having been around since the 90s – it is basically Haskell on steroids), but has a more proof-assistant flavor than an actual programming language flavor. Opus & Fable write Agda quite well, so LLMs can understand dependent types.
You need range proofs to be 100% safe, and then you can as well use the regular type because invalid values will not occur.
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.
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.
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 requirements very clear. I had the tests very clearly with all the edge cases. But I didn't have a good and clear picture of how to attack the problem which was quite novel for me. As I got closer to passing all the tests it got exponentially more unruly and confusing. And nearing the end I was frantically changing little bits here and there wincing and praying and hoping the tests would pass. "Please work! Come on!" Then when I got close enough, I could never ever think about touching that mess again.
I was a below average programmer then throwing myself at some novel problem I didn't understand. Throwing LLMs that produce below average code at novel problems and relying on tests and requirements is not where we want to go to make real progress.
(Years later after much learning and coding myself I was able to redo the function in a totally different way. This time I actually understood how to attack the strange problem and made something clean, clear, and robust that just worked. The tests then become a secondary guardrail, not the main force of correction.)
We are seeing such a massive regression from what we've learned over the years of CS.
Generating code automatically when you're not even quite sure what it is or even should be doing is insanity.
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.
From that standpoint, it's not a crazy setup security-wise. Maybe still crazy for development.
I had Fable add a new subcommand to our internal CLI tool. I reviewed and tested it locally and had to suggest several fixes that I feel like I wouldn't have had to tell a human senior engineer to do. When it finally submitted the PR, I had it on a loop waiting a few minutes for comments on the PR, then assessing/addressing/replying-to/resolving them, and then repeating again until all AI reviewers were okay with it. It ended up going through dozens of revisions and ended up with 160 comments left on the PR.
Are you implying that all code writing by LLMs atm is bug-free?
But, to the underlying question, obviously as we automate more and more of our work, of course we provide less and less value. We're heading towards a future where selling thought for money isn't going to work so well.
It used to be considered a quality of good code that there would be less code, not more.
Some people always tryin to get the highscore on golf.
We didn't stop using syntactic programming languages we used code to check code.
Not sure it's really crazy at all. It's been an abstraction for programmers probably since we stopped soldering transistors to each other.
They find bugs but whether they save time is nowhere near as clear as you try to insinuate here.
Generate multiple solutions- they do not to work 100% correctly. And than I check which I would prefer. Which is more to our applications taste.
And than I would take the vibe output as a kind of a ‚plan‘ which I use to implement but not follow 100% and at the end I take my solution and review it. I gain speed with that because I often can quickly see the pros and cons of a solution way better than when I would manually do it and hang on a major roadblock and also I even see such roadblocks in the vibe output - it’s mostly the part with an unnecessary amount of new code that looks nonsensical.
No big deal? It’s not like it’s free… tokens cost money.
But yeah, I guess it can be used to increase certain aspects of quality by letting them go wild. But I think I mostly hear about security or crash issues. In my experience they don't outweigh the number of other issues they cause. Like UI bugs. I've seen more than one service constantly rolling out features that are completely broken, just to have a completely new, still broken, solution available the next day.
A.I. could also be used to port C/C++ codebases to Rust, which isn't economically feasible at the moment.
let foo = NonZero::new(unvalidated_input).unwrap();
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?
The implications of the crash depends entirely on the implementation of the process it crashes. If I use ffmpeg as a library it'll crash my process upon processing the offending file. How is my process designed? How is every process that uses ffmpeg designed? You don't know, therefore you can't say that it's a "self-dos" in every case even if you know that it is in some cases.
Maybe I am clever enough to have read up on the history of ffmpeg vulnerabilities before deployment to an attacker-facing service and have designed a solution where a crash has minimal implications, but maybe I'm not, and haven't. It's beside the point.
It is not enabled by default. It is used only in video games, which input files are fixed set of asset that came with the game.
It can be a crash, yes. but the typical user of this codec won't care.
it may not be an issue for ffmpeg, but it might be for an application that bundles ffmpeg.
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.
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))
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.
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-November/3355...
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.
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.
(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.)
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.
If you wanted to booby trap a repository then you’re far better off with a prompt injection attack.
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.
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.
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.
I understand the utility of this though, I just don't see this particular bug and something that would be particularly difficult o find pre LLM era.
The fuzzer found the bug before any humans did, so there is a mismatch of developers who could find this bug and those who did (without an LLM-coded fuzzer).
The value of the fuzzer continues long after it found this one bug.
It's worth nothing that in the bug discussion thread, the bug fix author pointed out that it's not easy to set up the config then call the functions in the right order. Your comment assumes that the reader has enough context to read the code and build the finite state automata in their mind. The bug fix reporter's comments suggest that you are assuming things which you shouldn't assume.
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
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.
val (/) : int -> (divisor:int { divisor <> 0 }) -> intThere's no viable way to statically prove at compile-time that these variables will never become zero at runtime, ultimately forcing a system of endless runtime checks (be it software or hardware)... which is why processors already throw exception interrupts when division by zero is attempted.
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
They only suggested a basic guard, chich can be useless if this case never happens
Generating correct input to get deep into the call stack and then finding something is the hard part.
https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/8eda3c7f91e1a5b...
> This is a bug found with our fuzzer: https://github.com/daedalus/fuzzer/