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

[Michael Niedermayer]

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 ?

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170531/774bcf7e/attachment.sig>