I don't know who needs to hear this, but DO NOT EVER expose Jellyfin to the internet
(github.com)
from Scary_le_Poo@beehaw.org to technology@beehaw.org on 02 Apr 2025 20:31
https://beehaw.org/post/19228632
from Scary_le_Poo@beehaw.org to technology@beehaw.org on 02 Apr 2025 20:31
https://beehaw.org/post/19228632
Collection of potential security issues in Jellyfin This is a non exhaustive list of potential security issues found in Jellyfin. Some of these might cause controversy. Some of these are design fla…
threaded - newest
I’m not smart, can you tell me if having it behind a reverse proxy with certs and everything fixes any of these flaws?
@walden @Scary_le_Poo Only if the reverse proxy has its own login on top of Jellyfin's, and even that only mitigates some of them.
Many of the issues are related to unauthenticated requests. Even though your reverse proxy provides SSL, Jellyfin still won’t know the difference between you and a random internet user. So, no, your setup doesn’t mitigate the security risks much at all.
Not really, no. These are application flaws. Caddy will happily do its job and just let bad actors abuse them. (Unless you mean mTLS certs, then Caddy would only respond to those having a client certificate, which hopefully reduces the number of bad actors to your users😉)
I’m also an absolute dumbfuck. And I can confidently tell you, as a matter of fact, that I don’t know.
I’m running SWAG reverse proxy, my DNS is not tunneled, I share my Jellyfin with others outside my network.
My primary concern is my server gets hacked, or I get charged with distributing ‘public domain movies’
Hacking, even on an insecure system, would be illegal. Any copyright troll trying to sue a single user for having a private jellyfin instance which they hacked to find out about would probably have a hard time actually making a case.
“Yeah, this one guy was distributing films to himself and a few friends. I know because I hacked him” doesn’t seem like a good case.
Nothing about this is hacking. They’re not defeating any authentication mechanism to scan your system. That’s the whole problem here. Nothing illegal about running a crawler/scanner service.
The fact that you have their content publicly accessible is not a “bad case” at all. Open FTP sites were sued plenty. It may be a bit harder to prove distribution intentions… but wouldn’t be hard to make a case that you violated copyright for the content they could enumerate.
It’s not publicly accessible, though. An account is clearly needed.
No… that’s the point of this thread. There is no requirement to login in order to manually access endpoints. Up to and including pulling video data.
Not unless the reverse proxy adds some layer of authentication as well. Something like HTTP basic auth, or mTLS (AKA 2-way TLS AKA client certificates)
For nginx: docs.nginx.com/…/configuring-http-basic-authentic…
so if I add a user ”john” with password “mypassword” to video.example.com, you can try adding the login as: “john:mypassword@video.example.com”
Most HTTP clients (e.g. browsers) support adding login like that. I don’t know what other jellyfin clients do that.
The other option is to set up a VPN (I recommend wireguard)
This is correct. However I’d want to add, that this will break EVERY app-based access of jellyfin which defeats the purpose for a lot of people. Adding auth in front of jellyfin will work and allow you to use the web client only.
You kind of touched on it… I wanted to make it clear.
VPN would be a better more interoperable answer for most cases, you’ll still be stuck on devices like WebOS on LG tvs, or roku devices, or others that don’t have the ability to install vpn clients.
This is misinformation. It breaks the web app too.
You can’t use basic auth with jellyfin at all. Its a bug. Jellyfin closed the bug as won’t fix because, it seems, they dont care about security.
Oh, sure enough. Basic auth breaks the login function. I didn’t test it myself and didn’t think that it wouldn’t work for basic auth. I’ve put other auths in front of it and it works. So It’s not completely “misinformation”. Just annoying that the easiest most basic form of auth won’t work.
What other auths can you put in front of it?
The problem is that they’re (ab)using the Auth header, which causes a colission and you can’t load many required assets.
I was testing a 2fa based one the other weak and jellyfin was the service I decided to test with. Ultimately didnt like it so I rolled ot back.I’d have to go look it up to get you a name.
You can’t do that with jellyfin.
Basic auth doesn’t work with jellyfin. Its a bug. Enable it on your reverse proxy, and jellyfin breaks. Devs closed it as wontfix
That sucks, good to know.
Looks like creating a VPN is the only option for securing jellyfin.
short answer: no, not really
long answer, here’s an analogy that might help:
you go to
https://yourbank.comand log in with your username and password. you click the button to go to Online Bill Pay, and tell it to send ACME Plumbing $150 because they just fixed a leak under your sink.when you press “Send”, your browser does something like send a POST request to
https://yourbank.com/send-bill-paymentwith a JSON blob like{“account_id”: 1234567890, “recipient”: “ACME Plumbing”, “amount”: 150.0}(this is heavily oversimplified, no actual online bank would work like this, but it’s close enough for the analogy)and all that happens over TLS. which means it’s “secure”. but security is not an absolute, things can only be secure with a particular threat model in mind. in the case of TLS, it means that if you were doing this at a coffee shop with an open wifi connection, no one else on the coffeeshop’s wifi would be able to eavesdrop and learn your password.
(if your threat model is instead “someone at the coffeeshop looking over your shoulder while you type in your password”, no amount of TLS will save you from that)
but with the type of vulnerability Jellyfin has, someone else can simply send their own POST request to
https://yourbank.com/send-bill-paymentwith{“account_id”: 1234567890, “recipient”: “Bob’s Shady Plumbing”, “amount”: 10000.0}. and your bank account will process that as you sending $10k to Bob’s Shady Plumbing.that request is also over TLS, but that doesn’t matter, because that’s security for a different level of the stack. the vulnerability is that you are logged in as account 1234567890, so you should be allowed to send those bill payment requests. random people who aren’t logged in as you should not be able to send bill payments on behalf of account 1234567890.
It's a list from 2021 and as a cybersec researcher and Jellyfin user I didn't see anything that would make me say "do not expose Jellyfin to the Internet".
That's not to say there might be something not listed, or some exploit chain using parts of this list, but at least it's not something that has been abused over the last four years if so.
The last set of comments is from 2024. These have not been addressed. The fact that it is possible to stream without auth is just bonkers.
The entirity of jellyfin security is security via obscurity which is zero security at all.
“As a cybersec researcher”, the limp wristed, hand wavy approach to security should be sending up alarm bells. The fact that it doesn’t, means that likely either, you don’t take your research very seriously, or you aren’t a “cybersecurity researcher”.
“Thank you for this list. We are aware of quite a few, but for reasons of backwards compatibility they’ve never been fixed. We’d definitely like to but doing so in a non-disruptive way is the hard part.”
Is truly one of the statements of all time.
You can't say that a solution is no security at all when it requires time and intelligence to bypass.
It is at least 0.01 security.
Effort or no, if an attacker can reasonably bypass it, it’s not secure. That’s why software gets security patches all the time, why encryption/hashing algorithms can fall out of favor, and why quantum computing can be pretty fucking scary.
I didn't say it's secure, I just said it's security.
.
How about 0.001 security?
Surely you understand how a stupid response to a silly statement like it is one of the sayings of all time can be appropriate in humorous situations, right?
I understand that you did not find it funny, but I hope that you can understand that it was my intention to be funny, and therefore a serious response is disproportionate.
.
When "hundredths fractions of security" fails to get a laugh, I know I'm in the wrong group of people.
It definitely was lol
.
Kinda was. Sry.
.
No, in this case it’s true independent of my opinion or perspective.
.
I’m sorry if I made you upset. Honestly.
Ofc I have no work regarding that because I was shitposting. I was hoping you’d take things a bit more lightly.
Personally, I’m a bit within the autism spectrum. When I was a kid I had a lot of trouble with some social hints that other people seemed to pick up really fast. With time some of those things I’ve learnt to pick up better, and others not so much. Also got bullied and that wasn’t fun.
My impression of this situation is that you misread a social hint, which is fine, and then got a little bit defensive about it, which is also fine. I can understand that. Has happened to me a billion times and I’m not as graceful as you are.
It’s just like… For me it was better to, at some point, stop resisting the pain of accepting I didn’t read these things as well as others did and just admitting “sorry, sometimes i don’t get when ppl are joking” because it reminded me of being in the spectrum and therefore different… For me, this was unthinkable… So I kept insisting on points when many others were telling me, with relative compassion, that I may have made a mistake.
I don’t care about the issue we were talking about anymore. Just want you to understand that even if I do believe you made a mistake in reading the situation, It’s not what I now consider relevant of this conversation, don’t think you were wrong in your perspective regarding security and I’m not laughing at you. I’m not doing anything at your expense. Just sharing a personal difficulty with you for your own possible benefit.
Idk if you can relate, but if you can maybe it could help.
Peace, friend, and have a great week. <3
.
No, you misunderstood. I do care, but not about the issue. About you.
I could be wrong about the issue.
I’m sorry I upset you, but yes, you were coming off a little emotional.
I didn’t mean to be rude.
What I shared was a personal story about my life which is painful for me to remember. I don’t go around sharing shit stuff with people who want to harm me. I share it with people who i think could benefit from it.
I really hope you have an awesome day cause to me, regardless of anything that’s been said, you seem like an awesome person. <3
.
You too friend, and sorry for being mean.
I thought you were being serious as well. I’ve dealt with enough people who would genuinely make that argument so I assume nothing.
No system is secure.
#confidentlyincorrect
The votes are not on your side
How is someone meant to guess what seems to be a randomly generated id? If they try to brute force it then you could probably set up something like fail2ban to block them after a few failed attempts.
I’m not saying video ids shouldn’t require authentication, they should but the risk of someone getting the video id seems fairly low.
It isn’t randomly generated. If you read through you would have known that.
Also, Rainbow tables.
tldr, Rainbow tables are precomputed lists of hashed values used to crack password hashes quickly. Instead of hashing each password guess on the fly, attackers use these tables to reverse hashes and find the original passwords faster, especially for weak or common ones. They’re less effective against hashes protected by a unique salt.
If the ID is the MD5 of the path, rainbow tables are completely useless. You don’t have the hash. You need to derive the hash by guessing the path to an existing file, for each file.
How unique do you suppose file system paths are?
How many hashes would one need to gather to quickly determine the root path for all files? Paths are not random so guessing the path is just a rainbow table.
The scanning for known releases becomes trivial once the file system pattern is known.
I’ve not looked but if the video id is based on its path, then surely the path includes the filename no? You can’t split a hash into its separate original parts, you either guess the entire thing or not. So in that case, the hash is going to challenging to brute force.
It’s not that challenging if you are looking for specific media files, but if you wanted to enumerate the files on a server it’s basically impossible.
Well lets say your a big movie studio… In the past 10 years you’ve released 40-50 movies. You pay some lawfirm to go out and find illegal copies of your movies.
Those 40-50 movies * 1000 or 10000 common paths/names makes you a nice table of likely candidates. Prehash that table in MD5. It doesn’t take all that much effort to “enumerate” all the movies that your studio cares about. 50000 http requests is childs play and you can scan a public server within minutes for your list.
Fully bruteforcing the thing… yeah that’s ridiculous. But I don’t think that people are naming bigbucksbunny.mkv as Rp23GXTHp4GN7P6j86HjRdxtfSKKAArj.mkv. So it’s not like we’re looking for “random” or “all” files anyway.
I don’t think anyone was ever saying that the risk here is full enumeration. Though it is technically possible with sufficient time… just will take a lot of time.
That is possible, but I don’t think you need to worry about that. Having a copy of a movie is not normally itself a crime.
Having it publicly accessible on a web server is distribution. And that normally IS a crime unless you have some licenses to do so.
I think in this case whether it’s distribution or not would have to go to court. It’s not intentended to be distribution. Depending on the judge and the lawyers it could be distribution or not distribution or the prosecution may have committed a crime in finding it.
Sure. Now who here wants to litigate it and find out?
Web scanners/crawlers aren’t illegal though. And since it’s not authenticated there’s no attempt to break any security/authentication/encryption. You don’t get in trouble for finding a random URL in a google search and accessing it. You’d get in trouble if you had to bypass some security measure to get there.
The point of this all is that these endpoints have no measure in place. Seemingly on purpose, and it’s documented by the maintainers that they don’t intend to fix it and leaving it open is intentional.
You can gamble it. I won’t. I just can’t accept that “Jellyfin is better” that keeps getting pushed when big gaping problematic holes like this exist.
Trying hundreds or thousands of hashes against the servers of random unconsenting people on the internet is beyond what I would be comfortable with. People have been prosecuted for less. It’s not the same as a crawler where you try a few well known locations and follow links. You’re trying to gain access to a system that somebody did not intend for you to have access to.
These endpoints probably don’t have protection because they were never designed to and it’s hard to add it later. Theoretically, if the IDs are random that’s probably good enough except that you wouldn’t be able to revoke access once somebody had it. The IDs probably aren’t random because at some point only the path is used. It’s how software evolves. It’s not on purpose that somebody may be able to guess the ID to gain access to it.
And installing a rootkit just because a customer put my music disc in a computer would be beyond what I’m comfortable with. However we know they’ve done it, and more or less got away with it.
If the server is using a standard path prefix and a standard file layout and is using standard file names it isn’t that difficult to find the location of a media file and then from there it would be easier to find bore files, assuming the paths are consistent.
But even for low entropy strings, long strings are difficult to brute force, and rainbow tables are useless for this use case.
Fully agreed. There’s some stuff in the list that could leak server info or metadata about available content to the public, but the rest seems to require some knowledge before being able to exploit it, such as user IDs.
That doesn’t mean these aren’t issues, but they’re not “take your jellyfin down now” type issues either.
So I have a NAS running Ubuntu I only keep my movies, my Jellyfin, and torrent software on in an isolated VLAN I stream from. I would think this would make any security issue with Jellyfin a dead end. I stream all content from Jellyfin domain I made and never use it locally. I stream off it at home from my VPN. This seems a safe way to stream where it can be used away from home unless I am missing something? Pointing out any holes in my logic is appreciated.
Agreed, this is a valid list of minor concerns but this is just a fearmongering post. It’s not good that some metadata can leak but if you take normal precautions (i.e. don’t run this next to your classified information storage) it’s fine to open this so your friends can watch media.
Source: me and my Masters degree in cybersecurity (but apparently OP just learned about Kerckhoff’s principle and rainbow tables in a completely incorrect context so I know how to do my job or smth lmao)
Edit: lol don’t look at OPs post history, now I know where the fearmongering came from
It’s nice to read something sane in these threads.
Source: R1 masters professor. Literally the person you would have needed to take the class from on the topic at my institution.
This is a problem simply because most paths and names will be similar due to *arr suites and docker mounts normalizing them to a standard that jellyfin wants to see. 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 hash that’s used to represent the path isn’t salted or otherwise unique.
Edit: mobile typos.
If I have rate limiting set up (through crowdsec) to prevent bots from scanning / crawling my server, should I be as worried?
Probably not. But depending on how it’s configured it could still be a gamble/risk. A rate limiting setup can mitigate it a lot.
oh yeah I’m pretty sure the majority of users bought a dedicated machine for Jellyfin
More likely than other services due to HWA.
my impression was that people either just put a graphics card in their server, or run jellyfin from the desktop/laptop
Yea many of the linked issues are already closed. Why is this post not down-voted like crazy?
The same reason FUD is so popular in regular news.
No. None of the items are closed. Click the “closed” items. All of them are “Not planned. Duplicate, see 5415”.
.
Who has the technical wherewithal to run Jellyfin but leaves access on the open web? I get that sharing is part of the point, but no one’s putting their media collection on an open FTP server.
The level of convenience people expect without consequences is astounding. Going to be away for home for a few days? Load stuff onto an external SSD or SD card. Phoning home remotely makes no sense.
.
They jacked their prices, or are about to anyway. If you don’t have a lifetime Plex pass then Plex might not be a viable option. My seedbox provider has been pushing people to Jellyfin for anyone without a Plex pass.
.
I thought I had a lifetime Plex pass, but turns out I was on yearly and the price went up $20/year, so I bought lifetime before the price went up. My whole family uses Plex, I couldn’t handle setting up Jellyfin for everyone and their devices.
.
Doesn’t have a sync play feature like Jellyfin does
.
thanks but no. I like my privacy more
.
I’m not exposing jellyfin, but for sure I wouldn’t let my plex server even see the internet (I bet iy wouldn’t even work that way).
jellyfin is perfectly accessible everywhere it needs to be. been using a VPN on my phone for ages for all traffic.
Friends, family using Jellyfin is the reason many have it directly available (and not behind VPN for example).
My Jellyfin server is behind Cloudflare with IP outside of my country banned.
I got Crowdsec set up on Cloudflare, Traefik and Debian directly.
I got Jellyfin up in a docker container behind Traefik, my router opens only 80 and 443 ports and direct them to Traefik.
Jellyfin has only access to my media files which are just downloaded movies and shows hardlinked by Sonarr/Radarr from my download folder.
It is publicly exposed to be able to watch it from anywhere, and share it to family and friends.
So what? They might access the movies, even delete them, I don’t care, I’ll just hardlink them back or re-download them. What harm can they do that would justify locking everything down?
Well… if “they” happen to be the rights holders or lawyers of the rights holders and they happen to enumerate their content on your system because they can guess common linux paths and likely names that their movie/show/music would appear as in your system, you’re going to care real quick when the lawsuit comes.
Where I live, I have the legal right to have a copy of a film of which I have a legal version, they can watch my media library as much as they want, it’s not enough to prove that it’s illegal.
And hacking my server is illegal, they can’t go to court by presenting evidence obtained through hacking, they would risk much more than me.
Keeping that copy on a web accessible platform that is accessible by anyone on the internet(unauthenticated) isn’t covered by your rights at a bare minimum.
Depending on the content “timing” if they trigger on something that doesn’t have a physical/consumer release yet… or all sorts of other “impossible” conditions. This is obviously reliant on what content you actually have on your server.
It’s still something regardless that it’s best not to invite.
It’s as accessible as my DVD collection in my living room: anyone can get into my home without a key by illegally breaking a window.
Using a flaw in my Jellyfin to access my content is illegal and can’t be used against me to sue me, period. The idea of rights holders who would hack me to sue me is just plain ridiculous.
And again, the only proof they would have could not be used in courts.
For real, you’re just fear-mongering at this point.
I was sincerely hoping someone would bring some real concerns, like how one of these security breaches listed in the OP could allow privilege escalation or something, but if all you got is “Universal might hire hackers to break through your server and sue you”, you’re comforting me in my idea that I don’t have much to fear
There is no authentication occurring. There is no “hacking” here. Nothing about scanners or bots scraping unauthenticated endpoints is illegal. This would be admissable.
Using a flaw in a software to retrieve data you should not have access to is illegal where I live, the same way as you’re not suddenly allowed to enter my house and fetch my drawers just because I left a window open. I won’t debate this point further.
Is the place you live anywhere in the US? If yes, then it doesn’t matter because they have the money. If no, then honestly you probably actually have sane laws.
I live in France, and these are the relevant laws :
Bullshit. Notice the term is fraudulent. They are not making a bad login or accessing anything that requires authorization. There is no requirement here that simply accesses a web page is sufficient.
Again FRAUDULENT. Since it’s public access, there’s nothing illegal happening here. Further any company that would be scanning for this material to build a lawsuit would have the legal right to reproduce the content (eg a law-firm that was contracted by universal, sony, etc…)
It requires authentication or bypass of functioning code to be fraudulent. Making calls to apis that have no authentication cannot be illegal. This is literally how a good chunk of the internet itself works. If it was illegal the internet wouldn’t exist in your country.
Edit: Just to make it clear. It’s not a “flaw”. The github link itself shows that the managers of jellyfin are aware of the problem and intentionally do not “fix” it as they want backwards compatibility.
www.legifrance.gouv.fr/…/JURITEXT000030635061/
Case law from the Cour de Cassation, where the defendant was convicted, by Articles 323-1 and 323-5, of having extracted data freely following a proven failure of the protection system.
The complainant just had to show that the data SHOULD have been inaccessible, by expressing this “with a special warning” :
Translated :
In my case, the first thing you see when you arrive at my Jellyfin instance is a login form blocking your entry, and you have to go through a backdoor to access my data, so there’s no ambiguity on this point.
You’re wrong, period. Stop trying to debate laws interpretation of a country you don’t even speak the language of.
LMFO. I actually speak English, French, Polish, and German (in proficiency order) and have an EU citizenship.
I just happen to live in the USA. So congrats, you’re wrong again. Try not to resort to personal attacks next time. You’ll look much less silly.
YOUR intention doesn’t matter. You don’t maintain the jellyfin code. The actual code designers specifically left the endpoints open for “compatibility”. There was a conscious decision for those endpoints to not require authorization, and worse, IT’S DOCUMENTED. This is not like the case you’re quoting. If accessing endpoints without auth was ever illegal, almost all IoT devices would be illegal, a good chunk of gaming and other services would be illegal, etc… This premise is asinine.
You realize that google and other sites regularly scan and capture direct links to websites without ever giving a shit about a login page somewhere else on the site. You don’t see lawsuits against any of those crawlers, nor the people who click the crawled links when they return in a search result. This is the exact same premise.
Oh you insufferable rawgabbit. Even in the face of definitive proof, the only thing you care about is throwing a 4 paragraphs tantrum trying to twist every single word just to not say “OK, maybe I was wrong on that thing”. I’m out.
I’m insufferable? You’re the one relying on personal attacks to make your point. Then run away with tail between legs when I show you 1) how it’s not the same as your case and 2) how other current internet operations WOULD be the same, and there’s no lawsuits in regards to those things.
.
You would be very wrong about that. You can even search open FTP servers using Google
palined.com/search/
OK. I’ll revise. No one with any sense is doing this. “Hi, RIAA and MPAA, come after me” is an asinine approach. I realize we have at least one generation unfamiliar with Napster, KaZaa and LimeWire, which replaced ratio FTP servers (which in turn replaced F-Servs in IRC). This is terrible online hygiene. You don’t leave your media out there for all to see. At least password protect access before linking to your friends.
Look at the rest of this thread though… many people are just fine with “this is FUD, I’m going to keep doing it!”
Still, posts like this raise awareness of the problem.
The typical guides for installing Jellyfin and friends, stop at the point where you can access the service, expecting you to secure it further.
Turns out, the default configuration for many (most) routers, is to allow external access to anything a local service will request it to allow, expecting you to secure it further.
Leaving it like that, is an explosive combo, which many users never intended to set up, but have nonetheless.
Huh, I can’t check the link right now… But if exposing Jellyfin to the Internet is not an option, then it is not ready to be shipped as the Plex replacement I have heard a lot here and on Reddit.
Agreed. I’m a bit disappointed that it’s being touted as such. If you need a local LAN option, use VLC Player.
Do we even know that Plex is better? It’s closed source and hasn’t been audited afaik
Yes… because you can take the raw request your browser makes… remove your auth cookie and replay the same request and it fails.
Closed source doesn’t mean that it can’t be tested for problems. Just means that you can’t go to the code to understand why it’s a problem. You can still see that the problem exists (or doesn’t in this case).
Edit: I haven’t tested every api endpoint myself… but for video files it doesn’t work. It’s not vulnerable to the same thing that JF is in that specific case.
It is if you have compared them together.
I haven’t recently thought and I am a lifetime Plex pass user (we will see what lifetime truly means sooner or later) and I have still been unaffected by most of the changes Plex has done (watch together is the 1st valuable feature that I have lost), so if you can’t expose Jellyfin then it is not better than Plex for me.
Put the instance behind another authentication point like a VPN or reverse proxy with SSO. That will prevent the wider Internet from accessing it without legitimate users being cut off. You should be doing this with any server you operate (like Plex), but definitely one that may have legal implications.
aaaand now you smart tv can’t connect. none of them. the clients dont even support http basic auth creds put into the URL for some crazy reason.
for advanced HTTP-level authentication you would need to run a reverse proxy on the TV’s network that would add the authentication info. for the VPN idea you would need to tunnel the TV’s network’s internet connection at the router. or set up a gateway address in the TVs network settings that would do that. or use a reverse proxy here too so that it repeats the request to the real server.
but honestly, this is the real and only secure way anyway. I wouldn’t be comfortable to expose jellyfin even if the devs are real experts. I mean vulns get discovered, in dotnet, jellyfin dependencies, linux filesystem, and reverse proxy, and honestly who has time to always tightly keep up to date with all that.
that’s not to discount the seriousness of the issue though, it’s a real shame that jellyfin is so much against security
Your smart TV is (presumably) on your local network, so you should be routing the requests locally (point the client at the local ip, assuming it didn’t autodiscover it) not through the VPN/ tunnel.
often, but not always. sometimes the TV is at a different house, when you are a guest or at a second property
Or even just on a differently vlan that you want to go through your reverse-proxy because that is where your security features are to separate you from shit you don’t trust.
In which case there are still ways to make it work, like putting in an SSO bypass rule for the IP of your other property. Point is, under no circumstances is it impossible to both have it be protected against scanning attacks like the ones described in the gh issue, and keep it available to use over the internet for authorized users.
I am sorry, I don’t think I follow, I am CGNATED anyway, so I need to use VPNs to access my server (if IPv6 is not available, for IPv4 I am experimenting with Tailscale funnels as of now).
You should already be fine in that case.
The linked post is from 2021. Many of the items were already closed. This looks like fear mongering.
No. None of the items are closed. Click the “closed” items. All of them are “Not planned. Duplicate, see 5415”.
I think you can IP whitelist who can access it no? That should solve any problems
There is zero (0) chance of an attacker to know and then spoof address of your friend unless you have even bigger problems. Good filter should simply not respond to any packets making very existence of exploitable site undetectable.
Does your friend have a static IP? Unlikely considering that you have to pay extra for a static IP.
@Emmie @Scary_le_Poo That depends on the ISP, there's still some out there that will give you one for free.
We are lucky, we get two free. Technically they aren’t true static, its tied to MAC of your modem, or your router(s) – with ISP modem in bridge mode. You can pay for true static, but I have probably had the same IP for 5 years, and same with the modem/routerbeforre this one.
Wrong use case, the expected one is friends and family watching stuff on your Jellyfin server from different homes, potentially through mobile, all with dynamic IPs
.
Perfect use for allowlisting based on dynamic DNS hostnames.
is that a feature in Jellyfin? and since when do all ISP subscribers have names in DNS?
You would set up the allowlist in your firewall. There are plenty of free options for dynamic DNS though not from any ISPs that I’m aware of.
oh, in your firewall. I think I can count the percents on one hand about how much of jellyfin users run a firewall applience besides it
@Scary_le_Poo I wouldn't say never, but in most cases, you're best served by sticking it behind wireguard- but this is also true of any service or tool you don't intend to make available to the greater internet
So what’s the alternative? VPNs are unreliable
Unreliable how?
Possibly some ISP interference with the OpenVPN protocol. Apparently that can happen sometimes
You can always funnel all your VPN traffic through a more typical port, like 80, and there’s very little anyone can do to distinguish between your traffic and typical web traffic.
If your ISP causes issues with inbound traffic to your home network, just add another link to the chain to include a cloud-hosted server, or host it all entirely in the cloud (if you find a trustworthy one with a reasonable cost).
wireguard has been going fine here for 5+ years. only problems were when that garbage raspberry crashed as it always does (but that’s an issue with the hardware) and when the IP changes, but that’s mitigated by dynamic DNS
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 ;)
I need to run a VPN already. Fine for desktop, but this isn’t a solution for mobile (where you can’t run two VPNs simultaneously)
@jagged_circle @anarchiddy
It's actually possible to run 2 VPNs simultaneously on mobile using RethinkDNS which is an app available on F-Droid. For example I'm currently connected to MullvadVPN and my home network at the same time using two WireGuard configs.
Omg thank you!
Can you order the wireguard connections?
Eg I want my connections to my home server VPN to first go through my mullvad VPN. Because I dont want any connections coming out of my device that don’t go through a shared VPN or Tor.
This may be easier to do on your home network’s router. For instance, mine allows me to set it up as a VPN host, and also to connect to a VPN provider. It has the option to pass all of the connected clients through the connected VPN. So for instance, if I connect my phone to my home VPN, and my home router is connected to Mullvad, my phone’s traffic also gets passed through Mullvad.
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?
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/moviesor 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.
Or you become part of a bonnet and attack your own government’s military. Then you get some very angry knocks on your door and a black back over your face.
And, if you’re brown, probably some electrodes on your genitals until you sign a written confession.
This isn’t happening. The government understand what a botnet is, and if tens or hundreds of thousands of compromised machines are involved, they aren’t coming after you for being part of the attack.
They might send you mail telling you to take care of your shit though.
Some countries have recently been snatching brown people off the streets for any reason. And firing all the smart folks who might know what a bonnet is
Be reasonable, we’re talking about States here.
Use a VPN
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.
financestrategists.com/…/what-can-you-keep-after-…
It can decimate any savings you have for retirement.
What assets?🤣
<img alt="" src="https://lemm.ee/pictrs/image/9e550279-f226-467c-b579-9eda78bb2189.jpeg">
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.
Depending on where you live, it can be up to “all and anything that you may come into direct or indirect ownership of, for the following x years”. Get a job? No salary for you. Want to drive a car? Can’t have insurance on a car that’s not yours. Inheritance? Nope. Get married? Now half of your spouse’s salary is gone. And so on.
You better hire a good lawyer if you want to declare bankruptcy… and how are you going to pay them?
I guess the worst thing is that your server starts attacking the US military servers because you’ve become part of a botnet.
That happened to my friend one time when I installed Linux on his computer. He made the username and password the same 4-character word. Got a letter from the DoD.
I dont think they would be so forgiving these days. Especially if you’re brown.
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.
I dont know what that means.
Can I use that in addition to another VPN on mobile?
Afaik android doesn’t allow two VPNs at the same time. If you have a VPN back to your home already, like via your router, you don’t need tailscale although I’d argue it’s still better.
If you mean a VPN like mullvad, afaik you can’t mullvad and tailscale at the same time. I may be wrong but I gave up on global VPNs a while ago.
You can, its an option if you use tailscale. tailscale.com/mullvad
Also look into using tailscale lock to secure things more if you do decide to use it
Oh right I forgot about that, cool. Should see if you can do this with headscale (ie client feature vs server feature)
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…
There’s a bug (closed as won’t fix) where proxy basic authentication breaks jellyfin. You can’t use it.
Outch
Many of these have already been fixed FWIW, it’s not a collection of open issues.Nevermind, they have only been closed, not fixed. Yikes.No. None of the items are closed. Click the “closed” items. All of them are “Not planned. Duplicate, see 5415”.
Edit: The biggest issue of unauthenticated streaming of content… github.com/jellyfin/jellyfin/issues/13777
Last opened last week. closed as duplicate. it’s unaddressed completely.
That’s really sad. Damn, how disappointing.
I mean it was closed as a duplicate of the collection, not closed.
I meant it’s disappointing that they haven’t addressed any of the security issues.
Honestly, is the problem that they need extra hands to fix these issues?
While I’m sure that some of the answer is in not having dev time to fix it… Their response makes it seem like they’re not fully interested in fixing it for other reasons… In the case of this response, “Backwards compatibility”.
Thats sad honestly, this is where open source excells, and refusing to fix an issue without a plan to address it as a tech debt is just a bad solution