[FFmpeg-devel] [PATCH 3/3] avformat: set the default whitelist to disable hls

[Michael Niedermayer]

On Fri, Jun 02, 2017 at 09:15:25AM +0200, Nicolas George wrote:
> Le tridi 13 prairial, an CCXXV, Michael Niedermayer a écrit :
> > 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.
> 
> When you first introduced this protocol white-list to fix a problem with
> the concat protocol, I warned that it was not a good fix, it was only
> hiding the tip of the iceberg, and in a disruptive way, we would get
> other similar issues and trouble brought by the white-list itself. I
> told that we should start thinking how to design a proper data
> compartmentalization mechanism.
> 
> Now, one year and a half after the feature was introduced, the protocol
> white-list broke the output of dvd2concat, possibly other features, we
> have other security vulnerabilities that it does not fix, and we are
> about to disable a feature that, judging by the number of users
> questions, many people use.
> 
> And we are nowhere near designing a proper data compartmentalization
> mechanism.
> 
> Notice a pattern?

yes
Security issues are found, i post a fix and people complain,
I ask what solution is prefered and if they want to provide an
alternative fix and get no reply. I post a different fix and other
people complain.

If you knew a year and a half ago about a security issue and about a
great solution to it.
How far is it from completion ?
does this cover the hls vulnerability we discussed in
the last 2 days and Can you post a patch ?

If your solution is just an idea and not implemented after 1 and a half
years then iam not sure its a viable solution, given that security
issues should be fixed quickly.

But the real question still is, how do people prefer us to deal with
this security issue here?

Disable hls by default via whitelist (as in this patch)?
Disable local files in hls by default (as in the previous patch)
Do you or someone else want to submit an alternative fix ?

I of course will only push a patch if people agree to it, thats how
our patch reviews work.
ATM both patches have replies of people complaining with few or
no replies supporting them. And no alternative fixes posted.

thanks

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri
-------------- 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/20170602/810d7a90/attachment.sig>