Nope. I don’t talk about myself like that.

  • 0 Posts
  • 4 Comments
Joined 2 years ago
cake
Cake day: June 8th, 2023

help-circle
  • Well I don’t mean to harp on it… Plex in this instance is much better off. When provided proof of the problem they fixed it. Jellyfin has had issues about this going back to 2019… 6 years ago. Still no fix in sight. And the first ticket I linked proved the concept can be abused. With the issues getting hidden because “We’re closing this because we’re consolidating… oh wait… we’re closing it because we’re splitting the issues out.” I’ve legit had people tell me that the problems were fixed because they saw the issue closed.

    And now I hear that JF is even deprecating SSL and mandating proxy or esoteric custom config to implement SSL themselves again… Seems they’re going backwards?

    I had Jellyfin setup for just myself because I’d love to get away from the risk of Plex screwing shit up (and to get off their SSO). But the frustration of the dev responses to some of these issues and the fact that I’m literally the only person who’s able to deal with the restrictions needed to keep it secure… I just turned it off. I didn’t want to deal with managing two systems because my kids/wife/other family couldn’t figure out how to use it.


  • others are about media access

    Yup, and these are the biggest risks IMO. I find the well organized, big media companies with deep pockets and a few basic scripts that we know to work to be the biggest vector of liability.

    https://github.com/jellyfin/jellyfin/issues/1501
    https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2071798575 (and the following comments)
    https://github.com/jellyfin/jellyfin/issues/13984

    A person’s biggest threat running Jellyfin is going to be the media companies themselves. Sony (the company known for installing rootkits on people’s computers) can pre-hash a list of their movies with commonly config’d locations/name schemas for their content and enumerate your system for if you have their content. Since you don’t have any authentication on the endpoint, they’re likely not violating any law through circumvention. The “random UUID” is just the MD5 hash of the path/filename. So it’s actually highly guessable… especially for people using default docker configs and *arr stacks and you normalize names using these tools.

    Their response was “this attack isn’t in the wild”(as if they actually know… running a script and checking a few hundred thousand requests to go through a list of movies isn’t all that taxing and users won’t even notice it to report it… let alone have enough logging to notice it to begin with) and “it breaks compatability, so we don’t want to do it”. Which I find laughable. It turned me off from Jellyfin all together.

    Edit: And because every time I bring up the issue I get downvoted for “fear mongering”… There are answers to resolve it… you need to use non-standard naming schemes in your files/folder structure and fail2ban. But that expects users to do that… And I could do that… but it’s a security risk non-the-less and the developers response to the risk being what it is is what’s scary to me.

    Edit2: The LDAP one… I should clarify I don’t care about that one since well… requires you to additionally config stuff that most users won’t. But the media exposure issues are default and universal and require setting things “non-standard” to have any protection from, which users generally WON’T do.