On 22.01.2016 00:34, Luca Barbato wrote: > Let's try to make sure we are talking about the same problem here. > > by using hls you might craft a playlist containing a concat of a > playlist w/out a final new line. > > So you would send the initial part of the file together with the url. > > This is an information leak.
Yes. > It is moderate since the url has a maximum size that is sort of small > and libav's concat does not have a mean to send a file in chunks. > > So you cannot send /etc/shadow as whole anyway. > > The ways to fix the specific problem problem: > > - provide a blacklist/whitelist option in hls (from me, first > solution)-> Anton disliked it since it is too specific, However, the hls demuxer should somehow validate the URLs it's reading. Your suggestion would be one way to do that, others are possible as well. > courmish pointed out you can feed such line over any playlist some > application using avformat supports. Likewise such applications should check URLs before passing them to libavformat. Though, in practice, there will always be some that don't. > - have a pluggable avio-wide infrastructure to policy protocols and > paths (from Anton) -> It isn't simple to complete it. It's certainly a nice feature for applications to be able to implement their IO policy, but this still leaves the question of what should happen by default open. So this patch set is rather orthogonal to finding a solution for preventing these kind of information leaks. > - drop concat (agreed by me, Anton and Rémi) -> It is radical, but the > feature itself is quite fringe and I would rather drop it. That's more like admitting defeat. It's also no real solution as other protocols possibly added in the future could be used for similar exploits. > avconv itself may stay compatible with scripts by implementing it in > program itself That sounds like a giant hack. > or providing a better interface for it while at it. Isn't the concat demuxer such a better interface? On 22.01.2016 13:37, Anton Khirnov wrote: > Just so it's clear what we're talking about, what is "properly" for you? That would be a more or less general mechanism, which would have prevented the information leak in the hls demuxer by default. It should also prevent any such possible problems in other demuxers. This could be done by implementing a protocol_whitelist with sensible defaults. > And what do you see as "the underlying problem"? I think that is libavformat mixing local and remote data. If it wouldn't to do that by default, such information leaks shouldn't be possible. Best regards, Andreas _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
