Quoting Andreas Cadhalpun (2016-01-27 01:18:23) > On 26.01.2016 19:42, Anton Khirnov wrote: > > Quoting Andreas Cadhalpun (2016-01-26 01:02:04) > >> 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. > > > > That was my first idea as well. Turns out, it's rather nontrivial to > > implement, due to the fact that protocols allow nesting (e.g. http over > > tcp). > > Could you explain in more detail what problem that would cause? > The whitelist should simply be passed from http to tcp in that case.
You have to go over all the (de)muxers that call the protocol layer directly and all the protocols and ensure that those restrictions are passed through correctly. That is a somewhat nontrivial amount of work. Not to mention that we first have to design those restrictions. That's also a not completely obvious step, especially if, as you're suggesting below, they should somehow be format-dependent. Frankly, I don't have that much free time on my hands to do all that quickly. Or do you volunteer? > > > It would also require the calling programs to have quite a lot of > > knowledge about the libav protocol layer internals. > > Most programs should be able to work with the default. > > >>> 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. > >> > > > > Opening a local playlist that references remote streams is quite common, > > Though it is a lot less common than simply opening a local file. > > > so making this behaviour forbidden by default is likely to break many > > applications. > > I think that applications wanting this behavior should explicitly enable > it. To ease the transition period, one could set the protocol_whitelist > to something sensible for this case, e.g. 'file,http,https,tcp', when the > filename has the extension of a playlist. That implies the whitelist is format-dependent, which is already rather nontrivial. > > > So while I fully agree that the concat protocol is not the root problem, > > it is the source of its most significat symptom and removing it will > > prevent the worst leaks. > > That could also be done by disabling it by default, i.e. unless an option > to enable it is given. That way people using it could at least continue > to do so after setting said option. > > > Meanwhile, we will have time to introduce the > > infrastructure to fix this properly (which I think I already started, > > but finishing it is, as said above, nontrivial). > > And I'd really rather not design new APIs at gunpoint from pressing > > security bugs. > > Then just add quick hacks preventing the worst problems. > I'd rather not have functionality hastily removed due to security > concerns, that could be easily worked around until a proper solution > is found. I don't really understand your position -- on one hand you don't want to remove "useful" functionality, even though the concat protocol is IMO borderline-useless. OTOH you are quite fine with breaking applications by adding restrictive defaults. -- Anton Khirnov _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
