On 26/01/16 01:02, Andreas Cadhalpun wrote:
> 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.

As long the solution is not brittle I guess there will be agreement on
it, in the mean time I'd disable concat.

>> 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.

I'd say that is a prerequisite =)

>> - 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.

>> 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.

>> 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.

>> 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, you cannot even restrict to same-source
and not break normal deploys of it =/

_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to