[FFmpeg-devel] [RFC][PATCH] configure: Disable unsafe demuxers by default

[Michael Niedermayer]

On Thu, May 10, 2018 at 04:44:59PM +0100, Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exactly a good security practice, an only
> makes it easier for potential attackers to gain the contents of
> system files.
> 
> Disable building these by default.
> 
> Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
> ---
> I've been hard disabling these at $dayjob for a long time, after some
> "interesting" upload attempts, but it should probably be done for
> everyone.
> 
> I'm not overly attached implementaion details like the option name
> or whether it's done at build time ot runtime, but I think the concept
> of "don't render arbitrary system text files" is an important one.
> ---
>  Changelog     | 1 +
>  configure     | 7 +++++++
>  tests/fate.sh | 1 +
>  3 files changed, 9 insertions(+)
> 
> diff --git a/Changelog b/Changelog
> index d442ced..e3f8e83 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -6,6 +6,7 @@ version <next>:
>  - tmix filter
>  - amplify filter
>  - fftdnoiz filter
> +- unsafe demuxers that render text files now disabled by default

The problem and the suggested solution seem only somewhat overlapping

please correct me if iam wrong, theres quite a bit iam guessing here
IIUC the problem is that in your usecase 
1. ffmpeg has access to sensitive files
2. one of these files can be opened by an attacker with ffmpeg
2b. This involves the file being probed as a supported format
3. The file is then demuxed, decoded, encoded, muxed
4. the result is given back to the attacker

This patchset removes one of the demuxers involved in the attack

The first problem of this patchset is that it does not provide any
evidence of how the other demuxers probe functions can trigger on
random text files.
for example idf_probe() requires, the first 12 bytes of the file  to
match exactly and some of these are not text. So a attack which depends
on the probing of sensitive text data to succeed should not work with it

The second problem i see is that the patch disables the demuxers, while
disabling the probe functions affected should have the same effect
security wise but is a smaller step in respect to disabling.

The third problem i see is that really once you read sensitive data
and pass something back to the user you already lost.
A text demuxer and decoder makes it easier and it makes it much easier
to demonstrate the attack in a flashy way. But having the probe code
access the sensitive data even if none succeeds already makes quite
a bit of internal state (caches, branch prediction, deallocated memory, ...)
be contaminated with sensitive information. Its hard to ensure that
none of this can be recovered by the attacker.

I think first ffmpeg should not be able to access sensitive data.
Then none of our probe functions should succeed on the average
sensitive text file. If one does, we should look into making it not
detect that.

Also it may seem counter-intuitive but adding a probe function which
is designed to succeed on sensitive text files may be more reliable
to stop their detection than to disable probe functions.
The probe system is basically doing differential probing. That is
the one of 2 that has the higher score wins.
So it may be more effective to add a function that that returns a
high score intentionally for a null demuxer than to try to stop
every function that returns more than 0
if such probe code is added, it also could maybe warn the admin about a
potential misconfiguration that allows probing to reach to sensitive
data.


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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180510/985e9f62/attachment.sig>