Le tridi 13 prairial, an CCXXV, Michael Niedermayer a écrit : > This prevents an exploit leading to an information leak > > The existing exploit depends on a specific decoder as well. > It does appear though that the exploit should be possible with any decoder. > The problem is that as long as sensitive information gets into the decoder, > the output of the decoder becomes sensitive as well. > The only obvious solution is to prevent access to sensitive information. Or to > disable hls or possibly some of its feature. More complex solutions like > checking the path to limit access to only subdirectories of the hls path may > work as an alternative. But such solutions are fragile and tricky to implement > portably and would not stop every possible attack nor would they work with all > valid hls files.
When you first introduced this protocol white-list to fix a problem with the concat protocol, I warned that it was not a good fix, it was only hiding the tip of the iceberg, and in a disruptive way, we would get other similar issues and trouble brought by the white-list itself. I told that we should start thinking how to design a proper data compartmentalization mechanism. Now, one year and a half after the feature was introduced, the protocol white-list broke the output of dvd2concat, possibly other features, we have other security vulnerabilities that it does not fix, and we are about to disable a feature that, judging by the number of users questions, many people use. And we are nowhere near designing a proper data compartmentalization mechanism. Notice a pattern? Regards, -- Nicolas George _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
