Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
You mean that one issue that is still open and linked in the "security and quality" tab on github?
i feel like one issue is a bit of a downplay here, considering that it's 12 different issues being shown as one mega issue. but yes that has most of them
But that's also the most recent version of it. Some of those issues that they have listed there has had previous issues that were closed to be consolidated into that mega issue, which then was closed to be split into their own issues again.
But how does it matter if the issue is closed or open? It is linked and stated early and tracked.
That issues get merged and closed is quite normal when there arw duplicates.
Also, i think the oppoaite. The issues get 'upplayed'. Which one of these are you actually worried about? And how does they affrct you?
I don't think downplaying them is the way to go though, Some of these issues have been in existence since 2019.
Like I mentioned though, it does seem like its starting to be worked on, a few of them are in progress the one I really don't like is #13991 which is a combination of:
For example I just made a user with no access period to any collection, just a login access and took the auth token for the user. I was able to grab every user on the servers ID including hidden and administrative users as well as users who don't use jellyfin's auth system, then couple that to see what the users login method was, when their last access was, what folders they were allowed to use[note these are represented as id's the client can't actually parse them so you need to traverse the api for it], how many max sessions they could have, etc. without actually having access or logging in as that user or even being an administrator. If you snag an admins userid it even gives you internal server data such as logging paths that the server uses on the dashboard, the transcode path, the metadata path, what networking settings the server is using such as trusted ip nets the port jellyfin is using by default your certificate file and password if configured[although password may be ommited/the field left blank i didn't test internal certs]. From there you can even recurse through the folder UUID's provided via "enabledfolders" and the other folder restrictions on the users endpoint and get the name of the folders which could leak personal information about the library or the user because the 403 request it returns leaks the name of the library as part of the error message. "username is not allowed to access Library name"
Thankfully it's finally being worked on but, I do think it's worth stating the timeframe on them and that those issues do still exist.
Just like I think it's worth stating that media endpoints are still fully unauthenticated as well, so as long as you can guess the full file path, you can md5 it and get unauthenticated media paths, but that's in progress as well, its just super slow because that breaks third party clients.
I am not downplaying them. And yes they should get fixed. But this attack needs access to an account on your server.
Yes, also should be fixed, probably by some sort of salt and authentication, but can be easily prevented by adding a random character in the base/root path to the media. Especially with docker or similar, thats an 1 min fix.
And even if not? What then? Why would someone want to attack that?
Those are not good, no. But no deal breakers and actually more blown up then downplayed imho.
Doesn't it affect all of us in that we cannot safely run it exposed to the internet? I mean I still yolo it and run my jellyfin completely exposed because there's no way I'm guiding anyone through setting up wire guard or configuring clients to do additional auth, but still. I would love to not worry about that.
The question is, are the vulnerabilities actually a risk for your setup?
Should they be fixed? Absolutely.
But do they affect you? For me its basically a no.
A vulnability can be a nothing burger or critical issue that needa to be fixed. But it depends.
If it's a nothing burger then they should come out and say it's fine to run your instance publicly then
No, it is impossible to certify security, it's only possible to certify insecurity.
They could only say something like "it's designed to run exposed" or something like it.
You can pay for the audit if you like and still there would be no certainty.
I assume, before they say something like that they want a completely new API. But this would break every single client.
How come this is not an issue for other projects then? Why isn't Overseer also saying "don't host this publicly because we can't also can't guarantee perfect security? Is the issue really just that they can't prove security or is there an actual security issue with the API? From what you're saying it sounds like the only issue is that they haven't done an audit but that it's otherwise fine, but other people are saying there are actual security holes regardless of whether an audit is performed.
Like, I'm fine running stuff publicly that hasn't been audited like most of the stuff I self host. Why are people treating jellyfin differently than other self hosted projects that haven't been audited?
I am saying that the mentioned security vulnerbility is not as big as ppm make it to be. The bad thing right now is that IF you know the exact path of a media item you can probe if its there. As soon as you varg your path by just single character from the default/guides that are out there, this is basically no longer practical.
Is this ok? No. But to fix this, every Client would be broken.
The current API dies not follow modern security practices since some are not or partially autheticated. Thats basically inherited by Emby.
That is the current main issue and needs to be dealt with.
I assume that after the last EFcore (database handling) this gets addressed since now the API can be designed around the standerized databade calls.
Also overseer is also not saying "pls host on the public internet". If you do so, you are on your own. Why jellyfin gets treaded different? I do not know.
EDIT: I guess at least some ppl, use this as a comfortable excuse to stay on Plex. "But it is insecure... so i can not set it up"
Ok, well you just made it sound like the main issue was the lack of audit /guarantee and not an actual security issue. I don't think breaking clients is an excuse not to at least get started putting forward a date, even if it's a year in the future, where clients need to be updated by. Sure Overseeer isn't begging people to put it on the internet, but there aren't any known vulnerabilities to my knowledge, same with vaultwarden. Imo it's a big win to getting more people comfortable using jellyfin if they can put their foot down and say clients need to update, or stay on the old version. Every time there's Plex drama, it seems like the list of reasons people don't want to spend time to migrate isn't getting whittled down much. I've donated hundreds of dollars over the years at this point to jellyfin proper as well as several clients hoping things could move faster. Like imagine if the Overseeer devs designed a frontend. There's nothing that jellyfin can't technically do that I find missing, but it feels like a death by a thousand cuts.
Just because you do know any or that there are no know to the public does not mean it is secure. Do we know if the plex communication with your server is secure? No one cares, because no one is looking into it.
The main issue, is that ita not that simple to get new versions on the closed eco systems on many smart TV, especially when you are just a single dev and no company who can throw money on the problem.
As I said, the issue is not that big, and mainly an excuse for most ppl. The API break will come, hopefully sooner than later, but it needs to be carefully designed, to prevent issues in the future.
But again, the current issue is not that much of a problem. I do not see the benefit of anyone to probe my server if i have certain media files on there. And i do not use the default paths.
Sure not knowing of an issue doesn't mean it's secure, but that doesn't also mean that projects with known issues aren't a problem... Like if you want jellyfin to be popular you should want this to be fixed - I don't get this attitude from people who main jellyfin who seem opposed to pushing for it to be better. It not being a big issue is your own personal opinion - it's obvious that known security issues sitting around for a long time bothers a lot of people so the sooner it gets addressed, the fewer reasons people have to stick with Plex. That's a good thing right?
I am saying all this because it's more blown up than it is. I have said in basically every single post that it needs to be fixed right? So pls do not suggest that I do not want it to get better.
But, this link to the collection of vulnerabilities gets posted on every argument without any explanation and or classification. Which is also not ok.
For starters, it being brought up wouldn't be an issue if there was some timeline to fix it and the response wasn't just "it's too hard and would break clients", and secondly, I think it's not congruent with wanting to improve jellyfin if your reflex is immediately to say that nothing is truly secure. Could you imagine if next cloud had a similar issue and put it off for more than 5(?) years?? Is that really not enough time to get the clients and apps in order? They should just put the issue to rest so we can move on with making jellyfin better. I don't think anyone wants it to remain an issue for another 5 years, and I think calling that blown out of proportion is kinda ridiculous.
Like if 5 years ago they said you have 5 years to update your app, we could have had this issue checked off and nobody would be able to complain about it or use it as an excuse not to switch, so the next best time to set a deadline would be now. They should just as soon as possible say you have a couple years to update your apps, at least schedule a date years in the future to rip off the bandaid instead of kicking it further down the road.
At no point in life I said that.
Jellyfin has proven with the latest RCEs that they can handle relevant critical security vulnabilities.
As always, jellyfin does not have that much relevant contributers, and a lot of work has been done in recent time. It is very easy to lean back and say what they should or should not have been doing.
Breaking Clients would make the project not usable for many ppl or at least decrease the usability.
As i have already said, getting uodatea on those closed eco systems can be a nightmare.