[FFmpeg-devel] [PATCH] avformat/hls: Disallow local file access by default
michael at niedermayer.cc
Wed May 31 19:33:17 EEST 2017
On Wed, May 31, 2017 at 05:18:57PM +0200, Tobias Rapp wrote:
> On 31.05.2017 15:42, wm4 wrote:
> >On Wed, 31 May 2017 14:49:19 +0200
> >Michael Niedermayer <michael at niedermayer.cc> wrote:
> >> [...]
> >>Security fixes should be as simple as
> >> possible.
> >Well, your fix isn't simple. It adds yet another exception with
> >questionable effect. It makes it more complex and harder to predict
> >what will actually happen, not simpler.
> >>If people want, I can limit the local file check to the case where
> >>the io_open callback is not set?
> >>That way user applications which do their own sanitation would not be
> >>affected by the check or error message and stay in full control of
> >>what access is allowed.
> >That would have little value and would make it more complex too.
> >I'd say a good way to make this secure would be disabling the hls
> >protocol in builds which are security sensitive.
> We already have "protocol_whitelist", --disable-protocol and
> application sandboxing as supported and generic options. I agree
> with wm4 that some special case-handling here just adds complexity.
"--disable-protocol" does not allow fixing this, the vulnerability
only needs the file protocol ultimatly.
similarly protocol_whitelist only helps if "file" is not on it,
no other protocol is really required for this.
I just confirmed the exploit works with
sandboxing is the awnser for automated transcoding services but
the average joe end user cannot use sandboxing
What do you suggest ?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel