I remember when they were arguing that you don't need a VPN or proxy basic authentication in front of it because their team knows how to write secure code...
this post was submitted on 02 Apr 2025
158 points (100.0% liked)
Technology
38432 readers
590 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 3 years ago
MODERATORS
For those unaware, it's a good idea to be using a service like tailscale (self hosted=headscale if you don't want to make your login credentials tied to apple, google, or Microsoft). It's a VPN but a lot simpler to use.
If my server is already open to everyone, what kind of potential attacks do i need to be worried a about? I dont keep personal files on my streaming server, its just videos, music and isos/roms. I dont restrict sign ups, so the idea of an unauthorized user doing something like download a video is a non issue for me really.
I do see where there could be problems for folks running jfin on the same server they keep private photos or for people who charge users for acess, but thats not me.
Am i missing something or is the main result of most of these that a "malicious" actor could dowload files jellyfin has access to without authentication?
With unrestricted signups, they can obtain their own account easily. With their own account they can enumerate all your other users.
If they have their own account they can just find your instance, make a login, collect all the proof they need that you're hosting content you don't own (illegally own) then serve you a court summons and ruin your life.
I wouldn't worry about the vulnerability in the link since your already wide open. But I wouldn't leave Jellyfin wide open either. Movie and TV studios are quite litigious.
I hope you're at least gatekeeping behind a vpn or something.
Edit: typo
Well it's hosted in The Netherlands and I did take some steps to protect my own identity in regards to registration info, but if the studios did take an interest i'd probably have some fun with it by decaliring bankrupcy and dragging out the appeals.
I mean, sure... but you'd actually have to reasonably liquidate most of your assets at that point. You can't just "claim" bankruptcy and do literally nothing to sate your debts. Of course this is different on a jurisdictional basis... but overall, you have to sell a lot of your stuff in order to do a proper bankruptcy.
It can decimate any savings you have for retirement.
What assets?🤣
Fair enough if you don't actually have any... but the courts will still make that decision for you. Some things might count that you don't expect.
I'm not sure who needs to hear this, but unless you work as a security engineer or in another security-focused tech field, you really shouldn't be exposing your homelab to the open internet anyway
Most people access their homelabs via VPN - i don't see anything here that's a problem for that use-case.
Many people host websites ;)
And I would hope those websites are extremely low-risk and not anywhere near essential infrastructure or data ;)
Can someone ELI5 this for me? I have a jellyfin docker stack set up through dockstarter and managed through portainer. I also own a domain that uses cloudflare to access my Jellyfin server. Since everything is set up through docker, the containers volumes are globally set to only have access to my media storage. Assuming that my setup is insecure, wouldn't that just mean that "hackers" would only be able to stream free media from my server?
If you use normalized paths/file names (through *Arr stacks or docker mounts or otherwise common tools), then the hash that jellyfin sets up when it imports that media can be guessable. If someone was to go and precompile a list of hashes for content that they're looking for at common paths that people store their files at, they can ask your server for those hashes, and if their list is sufficiently large enough to include the path that you used, your jellyfin instance WILL RESPOND WITHOUT AUTHENTICATION.
I've been using this example because it shows how silly this is.
In the context of Sony’s top 1000 movies, they can pre-compile the top 100 likely paths for the file (/movies, /mnt/movies, etc) then run the 100000 hash check through scripts against your instance. How long does it take to let a crawler collect http statuses on 100000 page loads? Now put that to a bot that gets jellyfin instances from a tool like shodan and add more hashes. If you flag, now onus is on you to prove you have license for content and they would have a case that you distributing (albeit weak) since your server was open to the public. This is child’s play level abuse-able. Risking that something easy like this isn’t being abused by Sony and others (you know… willing to install a rootkit on your computer types…) is a very silly stance to take.
The answer to some of this is that you can just hide the content on a more complicated and less likely to guess path. That will sufficiently change the MD5 hashes enough that you should be more or less unguessable... Instead of using /mnt/media/movies (or /media/movies, or /movies/, etc...) make the path /mnt/k9RKiQvUwLVCjSqhb2gWTwstgKuDJx59S3J35eFzW2dgSSp84EG7PPAhf2MwCySt/media/movies. (obviously don't use this one... use a random generator. Make your own.)
The real answer should be that Jellyfin requires that all those endpoint need authorization/login. But their answer is "We don't want to break backwards compatibility. So we won't." Which is a bit silly of an answer. Those who use the default installation and organize their content with *arr suites (or with default docker settings/guide settings), are most likely to have guessable MD5 hashes and are most at risk.
Edit: Oh and the other point... if the "response" against this is "well that would take too long, or be too hard. You'd need a lot of money to find all these instances and test them...". We're talking about the likes of Sony... The ones that installed rootkits on peoples computers for daring to put a CD into a CD-ROM drive. They're litigious folk, and will bury you in paper and sue you to oblivion. It's not a lot of machine time to test a single server. Setting up a couple dozen scanners and just letting it go to find content on it's own isn't that bad from a computational standpoint.
And another argument I've seen here... "Well if they hack your server then that's illegal too, can't make a lawsuit out of that"... Except this is normal web operations. Bots and site scanners aren't illegal. Nor do they break any authentication mechanism (which is illegal) to do this. Specifically putting this behind authentication would make you correct. But Jellyfin didn't do that (yet). So guess what. It's perfectly possible for them to setup a few scanners across a few servers and do this 100% legally.
Security through obscurity isn't security.
Edit2: Clarification on not using the path I just gave... make up your own random gibberish.
I think I understand now. Thank you! I will be changing my paths then. It's kind of a moot point since I'll change my paths anyway, but for the sake of my own curiosity, i have a follow up question. Feel free to disregard it if you don't feel like taking the time to answer.
Hypothetically, my docker setup only allows jellyfin to see /mnt/user as /storage. So jellyfin would report the path to Morbius as being:
/storage/hdd1/media/movies/Morbius_all_morbed_up.mkv
when in all actuality it would be:
/mnt/user/hdd1/media/movies/Morbius_all_morbed_up.mkv
My intuition tells me that the file path that jellyfin "sees" would be the security risk. So "/storage/hdd1/...." Is that correct?
My intuition tells me that the file path that jellyfin “sees” would be the security risk.
Your intuition is correct. JF will generate the MD5 hash based on the path that it's accessing with. So if it's normally a unique path then you mount it into the docker container as /movies/ or /mnt/movies or what have you... Then you lost the uniqueness, all that's seen is the internal docker path. This is why I also lumped "using docker" into the party side by side with "using *arr stack". Most people will find a compose file and just modify the left side of the volume declaration to point at their media. And most dockers are going to have simple internal mounts in their example compose files.
Both Arr and Docker will end up pushing people to standardize the path, then the filename. Using both together compounds the issue and they tend to standardize different parts of the path.
Use a VPN
view more: next ›