> Just yesterday there was a story on here about how Google found [a security vulnerability that anyone running `ffmpeg -i <untrusted file> ...` was vulnerable to] in FFMPEG, and told [the world about it so that everyone could take appropriate action before hackers found the same thing and exploited it, having first told the ffmpeg developers about it in case they wanted to fix it before it was announced publicly]

Fixed that for you. Google's public service was both entirely appropriate and highly appreciated.

▲

hekkle 3 hours ago | parent [-]

> and highly appreciated.

Not by the maintainers it wasn't Mr. Google.

▲

gpm 3 hours ago | parent [-]

Yes, but it was a public service not a service for the maintainers, and as a member of the public who like anyone who had run `ffmpeg -i <thing I downloaded from the internet>` was previously exposed to the vulnerability I highly appreciate their service.

I'd highly appreciate even if the maintainers never did anything with the report, because in that case I would know to stop using ffmpeg on untrusted files.

▲

hekkle 3 hours ago | parent [-]

So you were using untrusted video files that required the LucasArts Smush codec?

Again, if YOU highly appreciate their service, that's great, but FFMPEG isn't fixing a codec for a decades old game studio, so all Google has done is tell cyber criminals how to infect your Rebel Assault 2. I'm glad you find that useful.

	▲	gpm 2 hours ago \| parent [-]
		No, I was running on normal untrusted video files. The standard ffmpeg command line would happily attempt to parse those with the LucasArts Smush codec even though I'd never heard of it before. See the POC in the report by google, the command they run is just `./ffmpeg -i crash.anim -f null /dev/null -loglevel repeat+trace -threads 1` and the only relevant part of that for being vulnerable is that crash.anim is untrusted. Edit: And to be clear, it doesn't care about the extension. You can name it kittens.mp4 instead of crash.anim and the vulnerability works the same way.