On 26.01.2016 09:52, Luca Barbato wrote: > On 26/01/16 01:02, Andreas Cadhalpun wrote: >> On 22.01.2016 00:34, Luca Barbato wrote: >>> 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. > > As long the solution is not brittle I guess there will be agreement on > it, in the mean time I'd disable concat.
I think that at the very least the hls demuxer should always reject protocols internal to libavformat, like concat, as those simply do not belong into a hls playlist. >>> - 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. > > I'd say that is a prerequisite =) Not necessarily. This could also be implemented in the URLContext layer, accessible via AVOptions. >>> - 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. > > Hopefully not. Both the hls/applehttp demuxer and the concat protocol existed since 2010, but only now the problem was realized. That does not make me confident that problems with future protocols would be realized early on. >>> avconv itself may stay compatible with scripts by implementing it in >>> program itself >> >> That sounds like a giant hack. > > Not that much, it is sort of a little hack to begin with and its main > use-case was to take files split in chunks and not have to cat them again. It still doesn't sound appealing to handle the concat protocol separately, while all other protocols are handled by libavformat. >>> or providing a better interface for it while at it. >> >> Isn't the concat demuxer such a better interface? > > It is something different (the concat protocol is _that_ kind of fringe). > > I meant that having | in the command line is annoying. OK, but changing the semantics would also break backwards compatibility. So if you want to replace the concat protocol with something better, there should be a reasonable transition period so that people could adapt to the change over time. >>> 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. > > it is inherently what hls does, Which is inherently insecure as it is prone to cause information leaks. > you cannot even restrict to same-source and not break normal deploys of it =/ Maybe we should break those by default to make people aware of the potential problems. If they want to do that anyway, they can set the appropriate options. Best regards, Andreas _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
