New Server/Web Hotfix Release: 10.8.13

[joshuaboniface]

The new Jellyfin 10.8.13 update is good for keeping things safe, especially with security fixes. But, stopping the edit of the FFmpeg thing might make it tricky for some people who like to change things. It'd be helpful to explain more about why this change happened and how it affects people who manage things. Adding tips or guides for those affected could make it easier to handle. It's good to see a focus on safety, but it'd be great to understand this change better.

The change really is exactly what it sounds like. Previously, there were 3 ways to set your FFmpeg binary path: in the UI (via the API), in the encoding.xml configuration file, or via the CLI flag --ffmpeg. We've removed the first one because it's possible for a malicious administrator to use it to set any arbitrary binary path on the system as the FFmpeg binary, including a malicious one. Further using that API endpoint, Jellyfin will immediately *execute* the binary to test if it's FFmpeg. It's hopefully easy to see how a malicious administrator (either explicitly granted or privilege escalated from another user) could abuse that to execute arbitrary code on the host Jellyfin system.

From the blog article, this feature comes from the very old days of Emby 3.x and Jellyfin 10.0 (our first release). Back in those days, every system (and version, for Debian/Ubuntu/other distro packages) used its own FFmpeg, and changing them was something administrators did frequently to get new features, hardware encoding, etc. These days, since at least 10.6.0, we've published our own FFmpeg binary along with the server, to provide full hardware encoding support and the latest features, which means that ultimately most people shouldn't need to be changing this with so much frequency that a UI option is really worth it. You still can of course, but doing so just requires the extra steps of SSH/shell login and a restart.

We ultimately decided, after close to 3 months of discussion, that the risk of this endpoint massively outweighs its potential benefits. Effectively, it was an endstage for multiple other vulnerabilities, and was its own risk from malicious Administrators. An administrator can still change their FFmpeg binary if they want using the other 2 options, but it requires (existing) shell access and a server restart to apply, providing some additional safety against malicious remote attackers.