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.
I dislike AI, but if AI finds real bugs then this is in my opinion objectively a positive thing. Of course the question is what constitutes a real bug.
From a security perspective, panic at runtime is not that bad for security. Much better than continuing to run with undefined behavior. If someone sends a malformed video in and it crashes the ffmpeg process you can just log it and restart it. Vs potentially exploiting the system.
I racked up estimated 1k worth of fable costs in a single day on a well defined side project budgeting app. Our third party QA testers are spending hundreds of thousands a month just on playwright tests. I can't imagine what your average corpdev throwing it at everything with loosely defined everything, from product requirements to stories in JIRA is costing the company.
At some point, it may just be cheaper to hire a few juniors and mids again.
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.
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.
I had the same knee-jerk reaction. "Did I read that correctly?"
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.
The fruits of using LLMs to code.
You'll waste far more time finding what it quietly and subtly wrecked than you would have if you just coded it yourself.
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.
The open ended bug hunt is the best use case for these agents. Finding nothing costs a few dollars, finding a division by zero in ffmpeg pays for itself.
Unrelated to the submitted link -- just checked your comment history and all of your comments are AI-generated like this one. What's the motivation for this?
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.
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.
It would be more flexible for a compiler to reuse the range analysis logic used in optimizations for statically verifiable divide by zeros. That way you could extend it to other things like statically verifiable overflows.
For stuff like niche value optimization sure. For practical arithmetic code, nah. Like with this bug, all that changed is that garbage data in gives the user an error that they tried to process garbage data. Adding a new type doesn't make the code better, it just moves the error around. And you really don't want an infix division operator to fail to type check if the right hand side isn't a nonzero type, do you?
And the type signatures of those possible return values can drive validation checks upstream of the calculation, so you're not actually ever going to return DivisionByZeroError. You're making sure through validation checks or case logic that that can never be returned.
The only way to achieve this is to either put a runtime software check on a variable whenever it's assigned/used, or to literally add hardware support in processors themselves which literally throws an interrupt when a "neverShallBeZero" variable is assigned to zero.
There'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.
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
> 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.
If you have SSH access to a server and Git is installed on that server, you can use it as a Git server. No additional setup is required. The Git client knows how to log in and invoke the Git server over SSH.
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.
Nice find. The interesting part isn't "AI wrote the fuzzer." It's that a cheap random harness still hits classical bugs in ancient parsers. Keep the corpus; throw away the hype.
But guys... AI is bad. It might have done good stuff today, but we should be anti data. The Chinese propagandists on United States social media told me to.
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.
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.
I even question if it is a DOS vector. So the thread crashes and then the system that controls the threads cleans it up and opens a new thread. Seems to be a trivial impact, unless it locks up the thread somehow.
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.
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).
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.)
since I'm getting a bit of pushback on how great tmux is (and it is nice) , just imagine the scenario of you scrolling back through your claude code cli to check some hour old message and you get a flash of ascii. normal right? even without claude code, it could be any tui, but the one thing that every dev uses... tmux.
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.
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.
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.
Difficulty 6 which some parts of FFmpeg use, is about the highest difficulty you can assign with the default Anubis config. For me personally I only serve that difficulty if I'm near certain the user is a bot. Serving it to everyone sure is a choice.
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?
> 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.
Unfortunately, if you let all the bots in, they overwhelm your servers, and then nobody can access the website.
Not if you use a decentralized peer-to-peer Git forge like https://radicle.network. If one node goes down, users can still access the same issues/PRs from another endpoint.
I assume you're offering to pay for the increased server costs?
I had some git hosting up for a while, and was serving hundreds of qps and several terabytes per month for very little data to scrape. I can only imagine want significant sites are serving.
> I assume you're offering to pay for the increased server costs?
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.
It's puzzling how mild the reactions are to Anubis compared to the people reacting to seeing one singular Cloudflare captcha checkbox. I'd much rather a checkbox than a brief CPU-intensive hashing session.
I think when people are complaining about Captcha they're complaining about yet another "pick 6-20 pictures of traffic lights/school busses/stairs/stop signs/bicycles."
> If they want to train an AI they should pay for it like everyone else.
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.
Does the bot include the rider when identifying bicycles? When is an ebike a motorcycle/no longer a bicycle? The support structure for a traffic light or just the coloured light bits?
Not in this case. I wish I could find the actual post, but I recall reading a post on HN recently where a majority of the commenters were claiming that when they even see a Cloudflare verification checkbox that they leave the website.
This makes no sense to me as in my experience, you click the checkbox and then it verifies you without extra steps.
Usually but not always. The challenge is after clicking the checkbox, if it can't manage to verify automatically. So those users have learned not to bother.
HN users love to inflict some pain on themselves and use non-standard OSes, browsers, browser settings, network / blocking configs etc. They then blame the results on Cloudflare instead of themselves.
For me it's very strange: I'd say about 7 times out of 10 it loads the checkbox for five to ten seconds, then I check it, then it loads for another five to ten seconds, refreshes the page, shows me a second checkbox, we go through the whole song and dance again, and then it lets me in.
Anubis is usually less obtrusive than that, though. This is the longest anubis challenge I've ever had, to the point of being absurd. Hopefully they have a genuine reason for having set the difficulty so high.
I expect the complaints would be fewer if it was a smaller thing, or if everyone had their own version rather than it feeling like one company deciding if you should be able to use a large fraction of the internet.
Cloudflare doesn't even let my browser (qutebrowser) through. Anubis will sometimes sit and ask for ridiculous amounts of work, but at least it's never outright denied access.
Solving one captcha is mildly annoying. Being trapped in an infinite captcha loop will really grind your gears and eat away at your spirit.
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.
The proof-of-work approach is much better privacy-wise than what the usual CAPTCHA services are doing.
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.
Well, Anubis actually lets me through eventually and most are very fast. Even this one is minimal compared to Cloudflare, which before I had to block its scripts entirely would just max out one CPU indefinitely (or at least a few hours, I found by accident, with no indication of stopping).
The Cloudflare captcha checkbox fingerprints the crap out of your browser. It's an opaque risk-based thing, which is the worst. Anubis just makes your browser brute force hashes, that's it.
It's a pity about the web, because it's becoming less accessible over time. Regardless, I (and some others) archive many of the things we browse to, so here you go:
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.
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.
Signed-off-by: Anthony Hurtado <[redacted since hn has no scrape protection]>
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…
Damn, I've never seen Anubis set up that aggressively, I wonder what kind of attack their web servers must be under to set their bot filters up this strictly.
It's Anubis and it's actually cool and loved project here. It's an open-source Captcha that filters out bots, and it doesn't track you around the web, unlike Google or cloudflare captcha.
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.
The thing about testing is that each time you produce a new kind of tester you have a chance to find bugs in the blind spots of the previous testing approaches. Diversity makes sense, more so than in software construction.
That's not a quality of ffmpeg or this bug, but of the application you use it for. If you only expose your ffmpeg-based application to your own input then yes, of course it's a self-DOS. But if you, say, expose it as a web service passing arbitrary user input to ffmpeg, that no longer holds.
Again, this is a crash bug, and again, whether it's a "self-dos" isn't a quality of the bug or ffmpeg.
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.
188 comments
[ 0.24 ms ] story [ 11.3 ms ] threadThere are also non security bugs that don't have exploits but just make the user experience worse.
A.I. could also be used to port C/C++ codebases to Rust, which isn't economically feasible at the moment.
I wonder why this wasn't found by OSS Fuzz.
No big deal? It’s not like it’s free… tokens cost money.
At some point, it may just be cheaper to hire a few juniors and mids again.
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.
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.
https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/8eda3c7f91e1a5b...
Generating correct input to get deep into the call stack and then finding something is the hard part.
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.
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.
There'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
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.
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.
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
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.
(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 may not be an issue for ffmpeg, but it might be for an application that bundles ffmpeg.
Edit: And there was discussion about this back in 2024 as well
I doubt the real bots have any trouble bypassing it.
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 for very little data to scrape. 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.
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.
HN users love to inflict some pain on themselves and use non-standard OSes, browsers, browser settings, network / blocking configs etc. They then blame the results on Cloudflare instead of themselves.
oh is that why my raspberry pi 5 can't browse websites anymore without freezing for a minute.
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.
Seems like it. It loaded near instantly as well from my Android smartphone using Firefox.
And contrary to the directions, refreshing the page DOES help.
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.
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.
cloudflare requires me to work for them
https://amber.agentic.church/web/lists.ffmpeg.org/2026082807...
Apparently, not the fonts they use for icons.
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.
- - -
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.
Signed-off-by: Anthony Hurtado <[redacted since hn has no scrape protection]>
[patch redacted for brevity]
Maybe it uses other heuristics like detecting if someone lives in the AI agent world
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.)
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.
But this bug feels like something an LLM would flag as a major finding but turns out to be completely benign.
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.
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.