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 <c...@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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
