On 24.01.2016 21:32, Nicolas George wrote: > Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit : >> No. It would have prevented the issue with hls. > > Reacting to known attacks by ad-hoc hole-plugging is no way of building > proper security.
The ad-hoc fix was the change done in the hls demuxer. The protocol_whitelist approach would prevent this class of issues, while being a rather simple mechanism that could be implemented in a backwards compatible way for almost all usecases. >> But it's usually only used with local files. > > I do not know that. Do you? I suspect it. For instance that's the example in the documentation. And it should less dangerous restricting the concat protocol to handling of local files by default. >> Why not? > > Because remote files can be more sensitive than local ones. It's not possible for libavformat to know what is sensitive and what not. But sending local files to remote is definitely problematic, when it happens unintentionally. Even just accessing a remote site when opening a local file can be considered a privacy breach. > Because some environment may download files, turning remote to local. I don't see how that is a problem. >> How? > > I do not know, Then you shouldn't have claimed it would be insecure. > but you can assume that someone knows and is selling that > information to the highest bidder. That can be said about any approach and it's not possible to prove it right or wrong. Thus stating this is completely pointless. > We know that playlists can be abused to leak information. Reimar was warning > about it years ago. People implemented them nonetheless, and guess what, it > did cause information leak. > > Now, your reaction is among the lines "the burglar left a footprint in front > of that window, let us wall it". Using this metaphor I would describe the situation differently: "The burglar knocked on the window and an unsuspecting person, let's call him Henry Louis Simplex, opened it for him. The quick fix for preventing this from happening again is to tell H.L.S. not to open that window. A better fix is to lock all windows so that people can only open windows they have a key for (i.e. which are on the whitelist)." > I say no, walling is overkill, and walling only that particular window is > useless. I don't know why you say 'walling', which would mean it's impossible to ever get through. However, with the right keys/whitelist one could still open any desired combination of windows/protocols. > We need to properly lock all the windows. That's exactly what the protocol_whitelist approach would do. You seem to be aiming for a complex mechanism of enforcing a security policy, which would require fundamental API changes. But there haven't been many details about how you envision the security policy, or how it could be implemented. Maybe you can add some more about this? In any case, the more complex a solution is, the more likely is it to contain bugs. Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
