668
Jellyfin critical security update - This is not a joke (github.com)
submitted 7 months ago by to c/selfhosted@lemmy.world
183 comments fedilink hide all child comments

top 54 comments

sorted by: hot top controversial new old
[–] 54 points 7 months ago

I forgot that it's April first, and was wondering what catasthropic event had happend in order that it had to be stated in the title that its not a joke

  • permalink
  • fedilink
  • source
    •
    [–] 117 points 7 months ago

    Thank you for posting this. I tend to get a lot of my opensource project info from Lemmy so people who take the time to post it are awesome.

    Just updated my home instance. Can confirm that 10.11.7 is available in the Debian repos and the update went perfect. I got a new kernel in the same update : D

  • permalink
  • fedilink
  • source
    •
    [–] 38 points 7 months ago (11 children)

    Wonder if it's the Axios one. Sounds like it isn't from their description though hmm

  • permalink
  • fedilink
  • source
  • hideshow 11 child comments
    •
  • [–] 13 points 7 months ago (3 children)

    Diff agrees, not likely. Might be permisson related, elevation of privileges.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 14 points 7 months ago (2 children)

    From a cursory look at just the security commits. Looks like the following:

    • GHSA-j2hf-x4q5-47j3: Checks if a media shortcut is empty, and checks if it is remote and stores the remote protocol if so. Also prevent strm files (these are meant to contain links to a stream) from referencing local files. Indeed this might have been used to reference files jellyfin couldn't usually see?
    • GHSA-8fw7-f233-ffr8: Seems to be similar, except for M3U file link validation and limiting allowed protocols. It also changes the default permissions for live TV management to false.
    • GHSA-v2jv-54xj-h76w: When creating a structure there should be a limit of 200 characters for a string which was not enforced.
    • GHSA-jh22-fw8w-2v9x: Not really completely sure here. They change regex to regexstr in a lot of places and it looks like some extra validation around choosing transcoding settings.

    I'm not really sure how serious any of these are, or how they could be exploited however. Well aside from the local file in stream files one.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 7 points 7 months ago (1 child)

    Yeah, the key seems to be in the comments from one of the changes: https://github.com/jellyfin/jellyfin/commit/0581cd661021752e5063e338c718f211c8929310#diff-bcc2125e56d5738b4778802ac650ca47719845aeee582f3b5c9b46af82ea9979R1176-R1180

    It seems there was the potential risk that insufficient validation could allow reading arbitrary server files, which indeed poses a security risk.

    However, my understanding is that this could be exploited only by authenticated users with permission to add new media. Not like that's a risk to ignore, but it's not like it could be exploited by anyone on the Internet.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 5 points 7 months ago

    However, my understanding is that this could be exploited only by authenticated users with permission to add new media. Not like that's a risk to ignore, but it's not like it could be exploited by anyone on the Internet.

    I wonder if that's the reason for setting the default live TV management permission to false. Since that permission might well the the route to adding your own malicious m3u link for that second change.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 7 months ago (4 children)

    Axios is a Javascript library and Jellyfin is written in C#.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 8 points 7 months ago* (3 children)

    True, but there is a web frontend. Possible it could be using npm and axios somewhere in there.

    I still doubt it. But it could happen.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] -2 points 7 months ago (2 children)

    The web server is in C#. It's open source lol, I'm looking at the code and there's no JavaScript.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    • [–] 28 points 7 months ago (23 children)

    Is it standard practice to release the security updates on GitHub?

    I am a very amateur self hoster and wouldn't go on the github of projects on my own unless I wanted to read the "read me" for install instructions. I am realizing that I got aware I needed to update my Jellyfin container ASAP only thanks to this post. I would have never checked the GitHub.

  • permalink
  • fedilink
  • source
  • hideshow 23 child comments
    •
  • [–] 27 points 7 months ago

    Is it standard practice to release the security updates on GitHub?

    Yes.

    And then the maintainers of the package on the package repository you use will release the patch there. Completely standard operation.

    I recommend younto read up on package repositories on Linux and package maintainers etc.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 7 months ago (1 child)

    I am realizing that I got aware

    I don't run the arr stack, but this is key. You really should do your due diligence before you update anything. Personally, I wait unless it's a security issue, and use all the early adopters as beta testers.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 7 months ago (18 children)

    Not really.

    Depending on how you install things, the package maintainers usually deal with this, so your next apt update / pacman -Syuv or ... whatever Fedora does... would capture it.

    If you've installed this as a container... dunno.. whatever the container update process is (I don't use them)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 18 child comments
    •
  • [–] 4 points 7 months ago (12 children)

    I indeed use a container. Wasn’t familiar with the update process for containers but now know how to do it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] 5 points 7 months ago (1 child)

    There's a lot of good container management solutions out there that are worth investigating. They do things like monitor availability, resource management, as well as altering on versioning.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 7 months ago (1 child)

    If you haven't already, I recommend Watchtower (nickfedor fork—the original is unmaintained) which automatically pulls updates to Docker containers and restarts them. Make sure to track latest, although for security updates, these should be backported to any supported versions so it's fine to track an older supported version too.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [+] -7 points 7 months ago (7 children)

    Lol it's already insecure then. Don't bother.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 4 points 7 months ago* (5 children)

    Implying you have access to some major Docker 0-day exploit, or just talking out of your ass? Because a container is no more or less secure than the machine it runs on. At least if a container gets compromised, it only has access to the volumes you have specifically given it access to. It can’t just run rampant on your entire system, because you haven’t (or at least shouldn’t have) given it access to your entire system.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] -1 points 7 months ago (4 children)

    Docker is known insecure. It doesn't verify any layers it pulls cryptography. The devs are aware. The tickets remain open.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 0 points 7 months ago (1 child)

    If that is indeed true it would only mean that the docker container is vulnerable to a supply chain attack. You are not any more vulnerable to a vulnerability in the codebase.

    If you’re using the ghcr image, to post malicious code there, the attack would have already had to compromise their github infra … which would likely result in the attacker being able to push malicious code to git or publish malicious releases. Their linux distro packages are self published via a ppa/install script, which I would assume just pull from their github releases, so a bad github release would immediately be pulled as an update by users just as fast as a container.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 7 months ago (4 children)

    Unattended upgrades set to security only and never worry

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 6 points 7 months ago (3 children)

    It's difficult to do security-only updates when the fix is contained within a package update.

    Even Microsoft's security updates are a mix with secuirity updates containing feature changes and vice versa.

    I usually do an update on 1 random device / VM and if that was ok (inc. watching for any .pacnew files) and then kick Ansible into action for the rest.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 7 months ago (2 children)

    Why does unattended upgrades with security only setting not fix this?

    This is literally why Debian has distinct repos for security updates.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    • [+] 28 points 7 months ago (4 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 1 point 7 months ago (3 children)

    Yeah, I think what went wrong and now everything is installed through Docker.

    Docker feels like a huge security problem to me.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 7 months ago (2 children)

    Why?

    Docker makes everything so much easier

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 7 months ago (1 child)

    I know, but your security then depends on the package maintainer to keep the image up to date

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 7 months ago

    Am officially maintained Docker image is no less a security concern than an officially maintained apt repo. Depending on how you set up a container stack it can even be more secure. An attacker gaining root access to a container that you've given extremely selective access to the host machine is far better than them gaining root access to your actual system.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 16 points 7 months ago

    You can always tell who does real IT work in these threads lol

  • permalink
  • fedilink
  • source
    •
    [–] 26 points 7 months ago (5 children)

    There is a good reason I only have Jellyfin and other services accessible via valid Client Certificate.

  • permalink
  • fedilink
  • source
  • hideshow 5 child comments
    •
  • [–] 8 points 7 months ago (2 children)

    Does it work with android and TV apps?

    I tried long ago and failed.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 14 points 7 months ago* (1 child)

    No, we only use Jellyfin via browser. Unfortunately even with imported Client Cert, Android apps won't work.

    Edit: Client Certs need to be implemented per App. There is a feature request from 2022 https://features.jellyfin.org/posts/1461/capability-to-specify-client-certificate-for-android-client

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 7 months ago (1 child)

    Also interested how this works for mobile apps. I self host a number of services through caddy as my reverse proxy but each application is just dependent on it's own authentication. If I exposed all my services to the internet, that's a huge attack vector. If anyone else has some ideas I'd be happy to listen.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 7 months ago

    If you are the only user and don't need to use those apps in devices you don't own a vpn is the way to go.

    If not. Depending the number of users you could do some heavy ip geoblocking to at least reduce the exposed surface.

    There are a few services I have just like 3 IPs allowed to get a response from caddy, any other ip gets 403 error.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 10 points 7 months ago (1 child)

    In the raspian repos, just updated, thanks.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • [–] 9 points 7 months ago*

    Good thing my Jellyfin is behind Wireguard.

    Consider doing the same if your usecase permits.

  • permalink
  • fedilink
  • source
    •
    [–] 8 points 7 months ago

    Thanks for this post, i would have updated mine next semester...

  • permalink
  • fedilink
  • source
    •
    load more comments
    view more: next ›
    2 comments in c/piracy@lemmy.dbzer0.com view that post
    2 comments in c/jellyfin@lemmy.ml view that post