Design issue affecting security

[Paul Ch]

Overview:

Attacker can create file with special name and bypass protocol white/black lists and achieve SSRF, if filename is passed to ffmpeg as an argument like ffmpeg -i <controlled_filename> output

How to reproduce:

$ nc -lvvp 1337 # listen of the local server to confirm the bug
$ touch "http:localhost:1337.mov" # create file that will be pass as an argument
$ ffmpeg -i "http:localhost:1337.mov" output.mov # trigger the bug

Execution of these shell commands confirms that if attacker controls the filename, he could control the protocol and workflow of FFmpeg.

Final words:

FFmpeg is software commonly used by large companies and other projects which use it as third-party software to process video on their own servers. This report shows that if name of file has not been changed before it is passed to FFmpeg, it could cause very harmful consequences. It was confirmed that issue exists in modern services and it is highly recommended to fix it.

Contact me if you need more details about this issue.

[Michael Niedermayer]

URLs for accessing files start with "file:" not with "http:" thus to open a local file with the name "http:localhost:1337.mov" would be done by

ffmpeg -i "file:http:localhost:1337.mov" output.mov

This is documented in libavformat/avformat.h

...
 * URL strings in libavformat are made of a scheme/protocol, a ':', and a
 * scheme specific string. URLs without a scheme and ':' used for local files
 * are supported but deprecated. "file:" should be used for local files.
 *
 * It is important that the scheme string is not taken from untrusted
 * sources without checks.
...

I think the issue you describe depends on incorrect use of the APIs or command line tools.

Also security issues should be discussed on ​ffmpeg-security@ffmpeg.org not on the public bug tracker.

[Carl Eugen Hoyos]

I don't think this is a valid ticket, the API requires you to check the source of the url if it comes from an untrusted source.