Le keskiviikkona 3. toukokuuta 2023, 16.33.59 EEST Michael Niedermayer a écrit : > This patch was inspired by a report on ffmpeg-security about SSRF > (for which custom io_open() callback or soem sort of sandboxing/VM can be > used to avoid it) > The patch here was intended to explore if we can provide something thats > better tahn currently by default
I am not sure how a dodgy HLS manifest would be any different from the user clicking an hyperlink from a dodgy website - or opening a dodgy playlist file in their FFmpeg-based media player application for that matter. Either way, it can open any URL. It is obviously not an ideal situation, but any restriction here will most definitely break existing use cases (and likely be abused by server operators to lock FFmpeg out). Even the "obvious" blocking of secure (HTTPS) to nonsecure (HTTP) references is likely to break stuff. If the end result is that everybody just turns origin checking off, it's pretty pointless. > But the same issue with roles flipped occurs for the end user and the user > cannot be expected to setup a custom io_open() callback for his player > The current code can be also used to poke > around the local network of the user. Which is unexpected by the user > for example a avi file could be probed as a m3u8 playlist and then > poke around on the local net while mixing that with remote urls > from the timing of the remote accesses the remote party should be able > to infer what happened with the local poking. I agree, but it is unrealistic to change anything here. People make playlists mixed with local files and network file systems or cloud storage services. Yes, there is a slight information leakage. For instance, you can probe if a local file exists by interleaving local and remote URLs in a playlist. In practice, this is a well-known issue and has been for two at least decades, and the "solution" is to limit what the open file can do. To state the obvious extreme, one wouldn't want to execute a shell script or an executable from a playlist. -- Rémi Denis-Courmont http://www.remlab.net/ _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
