[FFmpeg-devel] [PATCH] avformat/hls: Disallow local file access by default

[wm4]

On Wed, 31 May 2017 11:29:56 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Wed, May 31, 2017 at 09:03:34AM +0200, Hendrik Leppkes wrote:
> > On Wed, May 31, 2017 at 2:09 AM, Michael Niedermayer
> > <michael at niedermayer.cc> wrote:  
> > > On Wed, May 31, 2017 at 01:14:58AM +0200, Hendrik Leppkes wrote:  
> > >> On Wed, May 31, 2017 at 12:52 AM, Michael Niedermayer
> > >> <michael at niedermayer.cc> wrote:  
> > >> > This prevents an exploit leading to an information leak
> > >> >
> > >> > The existing exploit depends on a specific decoder as well.
> > >> > It does appear though that the exploit should be possible with any decoder.
> > >> > The problem is that as long as sensitive information gets into the decoder,
> > >> > the output of the decoder becomes sensitive as well.
> > >> > The only obvious solution is to prevent access to sensitive information. Or to
> > >> > disable hls or possibly some of its feature. More complex solutions like
> > >> > checking the path to limit access to only subdirectories of the hls path may
> > >> > work as an alternative. But such solutions are fragile and tricky to implement
> > >> > portably and would not stop every possible attack nor would they work with all
> > >> > valid hls files.
> > >> >
> > >> > Found-by: Emil Lerner and Pavel Cheremushkin
> > >> > Reported-by: Thierry Foucu <tfoucu at google.com>
> > >> >
> > >> >  
> > >>  
> > >  
> > >> I don't particularly like this. Being able to dump a HLS stream (ie.
> > >> all its file) onto disk and simply open it again is a good thing.
> > >> Maybe it should just be smarter and only allow using the same protocol
> > >> for the segments then it already used for the m3u8 file, so that a
> > >> local m3u8 allows opening a local file (plus http(s), in case I only
> > >> saved the playlist), but a http HLS playlist only allows http
> > >> segments?  
> > >
> > > we already prevent every protocol except file and crypto for local
> > > hls files. We also already block http* in local hls files by default
> > > thorugh default whitelists (file,crypto for local files)
> > >
> > > This is not sufficient, the exploit there is successfully puts the
> > > content of a readable file choosen by the attacker into the output
> > > video, which if its given back to the attacker leaks this information.
> > >  
> >   
> 
> > Well, I want to be able to store a HLS playlist and its segments
> > locally and play it, without specifying some obscure flag. So how can
> > we make that work?  
> 
> What you ask for is to use vulnerable code (hls with local files is
> pretty much vulnerable by design).
> Enabling this by default is a bad idea and it would be also an
> exception to how its handled in other demuxers.
> For example mov has drefs disabled without the enable_drefs flag.
> 
> Other means than a flag could be used to let the user enable it.
> Would this be what you had in mind ? If so what did you had in mind
> exactly ?
> 
> 
> > 
> > In general, information disclosure is always a risk when you process
> > unvalidated HLS streams, even if you load a remote http playlist which
> > only contains HTTP links, it could reference something on your
> > intranet and get access to something otherwise unavailable to the
> > attacker.  
> 
> > I would put the responsibility of ensuring this doesn't happen on
> > people creating transcoding services, not making our protocols barely
> > usable.  
> 
> According to the authors of the exploit, which they kindly seem to
> have sent to every affected company but not to us.
> Most if not all the big names had hls enabled and were vulnerable.
> So "its the users responsibility" alone did clearly not lead to secure
> code.
> 
> Also users cannot review the ever growing feature set we have for
> security sensitive features and disable them, thats not practical nor
> would it be reasonable from us to ask them to do that.
> 
> If you see a better solution than to disable hls or local file use in
> hls by default then please explain what you suggest ?

How is this "vulnerable"? If it's via the completely useless and
annoying bullshit tty decoder, I'm going to throw a party.