6 ms·
It crashes because of input that should have been rejected for being invalid. How could that be construed as being benign?
by boomlinde 20d ago
It crashes because of input that should have been rejected for being invalid. How could that be construed as being benign?
- j16sdiz 20d agoafaict, decoder bugs like these are treated with lowest priority possible. 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.
- throwa356262 20d agoBecause an attacker would not gain anything he not already has. This is basically local self-DOS.
- boomlinde 19d agoThat'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.
- throwa356262 19d agoEven then it will be a self-dos: the video you uploaded won't be processed.
- boomlinde 19d agoAgain, 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.