[FFmpeg-user] FFMPEg security question

[Dani A]

Thank you Marton!
Now, how can I recompile ffmpeg again? Is there a specific program I can use to disable the non wanted functions?
Also, how can I use the codec_whitelist and the format_whitelist, are those switches to use with the ffmpeg command just as the -moveflags? 
If yes, where can I place them in the below long command
ffmpeg-i iphone.mov -vf scale=640x360,setdar=16:9 -c:v libx264 -profile:v main-crf 23 -preset veryfast -movflags faststart iphone-converted-fastpreset.MP4

 


     On Thursday, July 2, 2015 6:33 PM, Marton Balint <cus at passwd.hu> wrote:
   

 
On Thu, 2 Jul 2015, Dani A wrote:

> My website allows users to upload video files so they can publish them, 
> and I use ffmpeg to convert the files and move atom to the beginning, 
> can someone upload a malicious file as if it is a video file and ffmpeg 
> can execute that malicious file? If yes, any one knows how to prevent 
> that from happening? Can the Ffprobe help with that?

Not really, no. FFprobe also opens the files and does a tiny bit of 
decoding as well when probing the streams, so running ffprobe on user 
files is almost the same as runnig ffmpeg on them.

There will always be a chance that user videos can exploit a yet unfixed 
issue of ffmpeg, however you can do a lot of things to limit the attack 
surface to a reasonable size.

I would suggest you to recompile ffmpeg and disable everything except the 
demuxers and decoders which your users actually use.

Alternatively you can use the codec_whitelist and the format_whitelist 
feature of ffmpeg as well, but not enabling the unused features is the 
safer way.

Keep a close look on decoders/demuxers/protocols which can open 
reference files and disable them or cripple the reference opening parts in 
their code. Altough ffmpeg usually checks these references if they are 
safe (e.g. if they do not point out of the directory of the original 
file), but better safe than sorry.

Also beware of formats which magically finds additional files in their 
directory (e.g. most image formats automatically searches for image 
sequences) and disable them or make them not do that by default.

Because of the reference file issues it is probably better to create a 
seperate directory for each input file, before you start transcoding them.

Keep your ffmpeg compilation up-to-date with git master to include the 
security fixes as soon as possible.

And of course there's a lot you can do limit the abilities of a malicous 
user if ffmpeg is exploited despite the precautions above. For example 
chroot, like Carl suggested.

Regards,
Marton
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user