4 ms·

From TFA: > The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,

by xethos 11mo ago

From TFA: > The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,” which the FFmpeg developers did patch, is “an issue with decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.” This doesn't feel like a medium-severity bug, and I think "Perhaps reconsider the severity" is a polite reading. I get that it's a bug either way, but this leaves me with a vague feeling of the ffmpeg maintainer's time being abused.

bragr 11mo ago
If it causes a crash, that's denial of service, so medium would be appropriate. But it's true that medium CVEs aren't that bad in most situations.
- javier2 11mo ago
  If you need this kind of security, build ffmpeg with only decoders you find acceptable
- walletdrainer 11mo ago
  This bug can most likely lead to RCE, proving that it can’t is generally a very difficult problem. There’s absolutely no reason to assume that it does not lead to RCE, and certainly no reason whatsoever to invest significant time to prove that one way or the other unless you make a living selling exploits.
tpmoney 11mo ago
On the other hand, if the bug doesn't get filed, it doesn't get fixed. Sure Google could spend some resources on fixing it themselves, but even if they did would we not likely see a complaint about google flooding the maintainers with PR requests for obscure 30 year old codec bugs? And isn't a PR even more of a demand on the maintainer's time because now there's actual code that needs to be reviewed, tests that need to be run and another person waiting for a response on the other end? "Given enough eyeballs, every bug is shallow" right? Well, Google just contributed some eyeballs, and now a bug has been made shallow. So what's the actual problem here? If some retro game enthusiast had filed the same but report would that be "abusing" the maintainer's time? I would think not, but then we're saying that a bug report can be "abusive" simply by the virtue of who submits it. And I'm really not sure "don't assign employees to research bugs in your open source dependencies and if you do certainly don't submit bug reports on what you find because that's abusive" is the message we want to be sending to corporations that are using these projects.
woodruffw 11mo ago
I think it’s exceedingly reasonable for a maintainer to dispute the severity of a vulnerability, and to ultimately decide the severity.
- ikiris 11mo ago
  Maintainers rarely understand or agree with the severity of a bug until an exploit beats them over the head publicly in a way they are unable to sweep under the rug.
  - woodruffw 11mo ago
    Yes, I think a defining aspect of vulnerability disclosure is how perverted the incentives structure is for all parties, including maintainers.
  - Orygin 11mo ago
    On the other hand, reporters giving a CVE a 10 for a bug in an obscure configuration option that is disabled by default in most deployments is bit over the top. I've seen security issues being reported as world ending, being there for years, without anyone being able to make an exploit PoC.
iscoelho 11mo ago
The vulnerability in question is being severely underestimated. There are many other comments in this thread going into detail. UAF = RCE.
- kragen 11mo ago
  Use-after-free bugs (such as the vulnerability in question, https://issuetracker.google.com/issues/440183164 https://issuetracker.google.com/issues/440183164) usually can be exploited to result in remote code execution, but not always. It wouldn't be prudent to bet that this case is one of the exceptions, of course.
CGamesPlay 11mo ago
That quote felt pretty disingenuous. OK, so the proof of concept was found in some minor asset of an old video game. But is it an exploitable vulnerability? If so, you will quickly find it on modern-day scummy advertising networks. Will it still be "medium severity"? Not clear either way to me, from the quote.
xign 11mo ago
Whether the codec is from 1995 or 2025 does not matter. What matters is that the codec is compiled in and working by default on ffmpeg as they intend to bundle all codecs for the user. You can just craft a file, send it to a user pretending to be a regular mp4 file, and trigger the bug. It literally wouldn't matter if the codec was this Lucas Arts one of HEVC. An attacker wouldn't care if they walk in the front door or a random broken window in the back.

by xethos 11mo ago

bragr 11mo ago

If it causes a crash, that's denial of service, so medium would be appropriate. But it's true that medium CVEs aren't that bad in most situations.

javier2 11mo ago
If you need this kind of security, build ffmpeg with only decoders you find acceptable
walletdrainer 11mo ago
This bug can most likely lead to RCE, proving that it can’t is generally a very difficult problem. There’s absolutely no reason to assume that it does not lead to RCE, and certainly no reason whatsoever to invest significant time to prove that one way or the other unless you make a living selling exploits.

tpmoney 11mo ago

On the other hand, if the bug doesn't get filed, it doesn't get fixed. Sure Google could spend some resources on fixing it themselves, but even if they did would we not likely see a complaint about google flooding the maintainers with PR requests for obscure 30 year old codec bugs? And isn't a PR even more of a demand on the maintainer's time because now there's actual code that needs to be reviewed, tests that need to be run and another person waiting for a response on the other end? "Given enough eyeballs, every bug is shallow" right? Well, Google just contributed some eyeballs, and now a bug has been made shallow. So what's the actual problem here? If some retro game enthusiast had filed the same but report would that be "abusing" the maintainer's time? I would think not, but then we're saying that a bug report can be "abusive" simply by the virtue of who submits it. And I'm really not sure "don't assign employees to research bugs in your open source dependencies and if you do certainly don't submit bug reports on what you find because that's abusive" is the message we want to be sending to corporations that are using these projects.

woodruffw 11mo ago

I think it’s exceedingly reasonable for a maintainer to dispute the severity of a vulnerability, and to ultimately decide the severity.

ikiris 11mo ago
Maintainers rarely understand or agree with the severity of a bug until an exploit beats them over the head publicly in a way they are unable to sweep under the rug.
- woodruffw 11mo ago
  Yes, I think a defining aspect of vulnerability disclosure is how perverted the incentives structure is for all parties, including maintainers.
- Orygin 11mo ago
  On the other hand, reporters giving a CVE a 10 for a bug in an obscure configuration option that is disabled by default in most deployments is bit over the top. I've seen security issues being reported as world ending, being there for years, without anyone being able to make an exploit PoC.

iscoelho 11mo ago

The vulnerability in question is being severely underestimated. There are many other comments in this thread going into detail. UAF = RCE.

kragen 11mo ago
Use-after-free bugs (such as the vulnerability in question, https://issuetracker.google.com/issues/440183164 https://issuetracker.google.com/issues/440183164) usually can be exploited to result in remote code execution, but not always. It wouldn't be prudent to bet that this case is one of the exceptions, of course.

CGamesPlay 11mo ago

That quote felt pretty disingenuous. OK, so the proof of concept was found in some minor asset of an old video game. But is it an exploitable vulnerability? If so, you will quickly find it on modern-day scummy advertising networks. Will it still be "medium severity"? Not clear either way to me, from the quote.

xign 11mo ago

Whether the codec is from 1995 or 2025 does not matter. What matters is that the codec is compiled in and working by default on ffmpeg as they intend to bundle all codecs for the user. You can just craft a file, send it to a user pretending to be a regular mp4 file, and trigger the bug. It literally wouldn't matter if the codec was this Lucas Arts one of HEVC. An attacker wouldn't care if they walk in the front door or a random broken window in the back.