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

Michael Niedermayer michael at niedermayer.cc
Sat May 12 15:23:40 EEST 2018

On Fri, May 11, 2018 at 12:14:47AM +0100, Derek Buitenhuis wrote:
> > 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
> It is "probed" as file extension mostly. .txt is one of these
> extensions, which 99.999999999999999%
> of the time, is not a multimedia file, for example.
> > 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
> Not removed. Disabled. As discussed in other replies, making it manual
> also seems
> fine to me. Rendering arbitrary text files as images (as in, rendering
> the text using
> a built in font, to an image with that text in it) isn't exactly a
> great and secure default
> behavior, especially for the world's most commont text file extension...

Do you think a document converter should by default not allow to open
multimedia files and embed them into documents ?
(not saying i think it should or should not)

What you suggest is similar, a multimedia converter by default
(not) supporting reading documents.

You later in the mail compare this to ASLR, i dont think this is at
the same level. ASLR provides broad protection, disabling
the .txt/.bin demuxers (which btw does not prevent other demuxers to open
.txt/.bin files) does not seem to be a comparable feature.

Of course every time you disable a feature the attack surface decreases,
in that sense it makes sense to disable all unneeded features whenever
security matters.
Iam not sure we know what is "unneeded" to the end user.

also where are security relevant *.txt files ? i looked at my /etc
and there where none.

> > 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.
> ffmpeg -i something.txt a.png
> But really, it is not necssarily an attack on its own (it could be),
> but it makes any
> other attack vastly easier to exploit. For example, that HLS stuff
> avformat had fixed
> last year could have pointed at various .txt files. I don't really
> understand why the
> concept of "rendering arbitrary text files as images" is not obviously bad?

as long as we support rawvideo input by default, disabling text input does
not gain much security. rawvideo is multimedia, noone suggested to disable
The probing / extension based detection, yes changes there should be able
to gain some security and we should possibly tighten this down where theres
an agreement.

as i was curious i looked at my /etc/ and /etc/*/ and from
3580 files there are 929 matches for 'Probing .* score:'

      1 mpeg
      3 svg_pipe
      9 png_pipe
     10 bin
     12 image2
     25 mpegts
     39 lrc
    830 mp3
and for 'probed with size|detected only with low score of'

      3 svg_pipe
      9 png_pipe
     24 mpegts
     29 lrc
    161 mp3
from the stuff above, the svg and png are correct detected

From this it appears to me that file extension while its an issue is not
the only and based on this, not the biggest


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- 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/20180512/104890b4/attachment.sig>

More information about the ffmpeg-devel mailing list