libffmpegthumbnailer/moviedecoder.cpp:70 calls avformat_open_input with a nullptr options dict, so FFmpeg accepts any top-level protocol it was built with: http://, rtsp://, concat:, subfile:, data:, etc.
When ffmpegthumbnailer is wrapped by something that thumbnails user-supplied URIs (preview servers, file managers handling untrusted user content), the input string reaches avformat_open_input directly. So an attacker who controls that string gets:
- SSRF — outbound HTTP/RTSP/etc. to any host:port the FFmpeg build allows. Cloud metadata endpoints, internal services, the usual.
- Local-file disclosure —
concat:/etc/passwd or subfile: byte-range reads of arbitrary local paths.
Same vulnerability class FFmpeg's own protocol_whitelist was created for (CVE-2016-1897, CVE-2017-9993). The mtn thumbnailer hit this and fixed it the same way.
The patch sets the whitelist to file,crypto,data,pipe by default (covers local files, encrypted Matroska streams, data: URIs from cover art, and stdin via -i -), and adds:
MovieDecoder::setAllowedProtocols and VideoThumbnailer::setAllowedProtocolsvideo_thumbnailer_set_allowed_protocols in the C ABI- a
-P <protocols> CLI flag, e.g. -P "file,crypto,data,pipe,http,https,tcp,tls" for users who actually need network input. Documented in -h.
So rtsp://.../http://... from the CLI still works for users who pass -P, but isn't enabled by default any more.
Suggested patch:
01-protocol-whitelist.patch
libffmpegthumbnailer/moviedecoder.cpp:70callsavformat_open_inputwith anullptroptions dict, so FFmpeg accepts any top-level protocol it was built with:http://,rtsp://,concat:,subfile:,data:, etc.When ffmpegthumbnailer is wrapped by something that thumbnails user-supplied URIs (preview servers, file managers handling untrusted user content), the input string reaches
avformat_open_inputdirectly. So an attacker who controls that string gets:concat:/etc/passwdorsubfile:byte-range reads of arbitrary local paths.Same vulnerability class FFmpeg's own
protocol_whitelistwas created for (CVE-2016-1897, CVE-2017-9993). Themtnthumbnailer hit this and fixed it the same way.The patch sets the whitelist to
file,crypto,data,pipeby default (covers local files, encrypted Matroska streams,data:URIs from cover art, and stdin via-i -), and adds:MovieDecoder::setAllowedProtocolsandVideoThumbnailer::setAllowedProtocolsvideo_thumbnailer_set_allowed_protocolsin the C ABI-P <protocols>CLI flag, e.g.-P "file,crypto,data,pipe,http,https,tcp,tls"for users who actually need network input. Documented in-h.So
rtsp://.../http://...from the CLI still works for users who pass-P, but isn't enabled by default any more.Suggested patch:
01-protocol-whitelist.patch