Yeah that's fair and I think that's a good move, my point is just that people are acting like this is not feasible to exploit. I'm at the point in my exploit testing excursion where I have a script that can generate a stream of potential IDs based on real torrent names being parsed and reformatted using radarr's default naming pattern as well as the commonly used trash guides ones permuted with some common library paths used in the default docker compose examples, and it's turning up actual ID matches with my jellyfin instance. All I have left to do is make it create API requests to test the IDs against the unauthenticated API instead of checking an exported list and there's a proof of concept. 5 years is a long time for someone to figure that out.
- Posts
- 0
- Comments
- 260
- Joined
- 3 yr. ago
- Posts
- 0
- Comments
- 260
- Joined
- 3 yr. ago
That's exactly the point I'm getting at. Putting an auth wall doesn't work with many apps, and if you add exceptions to the API then you're not really protecting anything.
What do you mean viable? The web UI is just an app that is delivered to your browser, it makes more or less the same API requests as an app would make, so IDK why the risk would be lower with an app?
If an attacker can access the login endpoint for example to brute force or dictionary attack, it doesn't matter if the web UI is or isn't accessible if the login endpoint it uses is exposed for an app. The attacker could serve their own copy of the web UI and proxy requests to the API your app connects to. Blocking the html from being served doesn't make a difference.
Do you not do any renaming? That probably would make it even easier as you can just brute force with a database of filenames scraped from torrents. I already have a proof of concept that generates valid jellyfin IDs from any given file path, it only takes a few more steps before you can plug in a shodan scan of jellyfin instances and just shotgun a bunch of IDs generated from torrents.csv at them and find stuff you can stream without authentication.
People not bothering to rename, using the default radarr naming scheme, or everyone using the same naming pattern from trash guides just makes it easier.
Probably the only way to guarantee nobody can probe your media and stream it without authentication is to make sure to rename everything using a format that only you use or mount all your media under a path inside docker that contains a long randomly generated folder prefix.
I managed to use the reader mode trick to get the text:
Signal warns it would pull out of Canada if made to comply with lawful access bill
Marie Woolf 6 - 8 minutes
Udbhav Tiwari, Signal vice-president of strategy and global affairs, says Ottawa’s Bill C-22 could threaten encryption and make private messaging services a potential target for cyberattacks.
Secure messaging service Signal, which uses end-to-end encryption, is warning it would withdraw from Canada if asked to compromise its users’ privacy under Bill C-22, Ottawa’s proposed lawful access legislation.
In an interview, Udbhav Tiwari, Signal vice-president of strategy and global affairs, said the company has deep concerns about measures in the bill, including its potential to introduce security vulnerabilities.
Mr. Tiwari said that Signal “would rather pull out of the country than be compelled to compromise on the privacy promises we have made to our users.”
He expressed fears that Bill C-22, which is currently being scrutinized by Commons committee, could threaten encryption.
Mr. Tiwari also warned changes to systems required under the bill could make private messaging services a potential target for cyberattacks.
“Bill C-22 could potentially allow hackers to exploit these very vulnerabilities engineered into electronic systems, with private messaging services serving as an ideal target for foreign adversaries,” he added in a text message.
Spy watchdog asks for greater oversight of proposed lawful access regime, including to boost public trust
Signal was founded in 2012 and is not linked to major tech companies. It has millions of Canadian users and is used for secure communication by journalists, dissidents, government agencies, private citizens and politicians.
The bill would require telecoms, internet companies and other electronic service providers to make changes to their systems to give surveillance capabilities to police and the Canadian Security Intelligence Service to combat threats and criminal activity.
Signal runs on its own centralized servers. The only user data it stores are phone numbers, users’ last login information and the date they joined the service. Users’ contacts, chats and other information are stored by users themselves, on their phones.
The bill would require “core providers” – which would later be defined through regulations – to retain metadata for up to a year.
The metadata would not include e-mails, web-browsing history, social-media activity or text messages, but it could include information about which telephone numbers have been in touch with each other, and data allowing someone’s location to be pinpointed.
“End-to-end encryption is incompatible with exceptional access, no matter how creative the route taken to achieve it,” Mr. Tiwari added in a statement. “Provisions that enable the deliberate engineering of vulnerabilities into critical infrastructure like Signal are a grave threat to privacy everywhere.”
White hat hackers warn lawful access bill could make it easier for criminals to penetrate Canadian systems
Last year, a Signal chat between U.S. national security officials and Defence Secretary Pete Hegseth mistakenly included a journalist. The chat specified timings of warplane launches and when bombs would drop in planned attacks on Yemen’s Houthis.
At a Commons committee hearing on Bill C-22 earlier this month, Public Safety Minister Gary Anandasangaree, who introduced the bill, was asked about its impact on encrypted services, and described it as “encryption-neutral.”
Tech companies, including Apple, and the Canadian Chamber of Commerce have warned the lawful access regime proposed by the bill could weaken or break encryption.
Meta, which owns encrypted messaging service WhatsApp, testified earlier this month to a Commons committee examining the bill. Rachel Curran, the tech giant’s head of public policy in Canada, warned that the bill “could conscript private companies into service as an arm of the government’s surveillance apparatus – with expansive scope and insufficient safeguards.”
“As drafted, the bill could require companies like Meta to build or maintain capabilities that break, weaken, or circumvent encryption or other zero-knowledge security architectures, and force providers to install government spyware directly on their systems,” she said.
Simon Lafortune, a spokesperson for Mr. Anandasangaree, said Wednesday: “We want to reassure Signal and all service providers that we are not legislating to require them to install capabilities to enable surveillance and any assertions otherwise are false.”
The broadly worded bill could lead to the rollout of forced metadata collection for messaging apps, said Kate Robertson, a senior research associate at the University of Toronto’s Citizen Lab whose expertise includes cybersecurity, state agencies’ use of personal data and surveillance activities.
Ms. Robertson said that when recently pressed to commit to protection for encryption, “government officials were reticent.”
“Encrypted communication systems are a lifeline for human rights defenders, journalists and dissidents around the world,” she said.
Matt Hatfield, director of OpenMedia, a non-profit that advocates for widespread and affordable internet access, said “Signal, WhatsApp and other encrypted messaging services could clearly be scoped into Bill C-22 under its current definitions of electronic service providers.”
“A future public safety minister could issue orders to them requiring them to retain user metadata,” Mr. Hatfield said in an e-mail.
Michael Geist, Canada Research Chair in internet and e-commerce law and professor at the University of Ottawa, said he expected private messaging services to become a high-value target for law enforcement if the bill becomes law, including for obtaining metadata.
He said that currently, courts focus on obtaining data itself, but the lawful access regime would mandate permanent structural changes to company systems.
“There is a significant difference between court-ordered disclosures and mandates to retrofit or change technical structures,” he said.
Gotcha yeah, I did this for LunaSea with traefik forward auth for the arrs, but the lack of support in jellyfin clients is annoying. Though personally I've been waiting 5 years for Findroid to support transcoded streams / adjusting video quality so personally that's higher on my list of priorities.
I do around 0.75tb per day, so like 22 per month. A lot of that is probably seeding and streaming as 90% of it is upload.
Gotcha I see, just checking if I missed something since that was the issue last time I tried doing something like that. These days I just yolo it and expose jellyfin to the public Internet.
Yeah not only would a lot of people have the same media name, because of docker mounts, probably a lot of people have the same path to the media inside of the docker container even if the external location is different. I bet you could make a rainbow table of sorts of the most popular movie/TV torrents combined with the most common place in the container for media to be mounted, then use shodan to get a list of hundreds of instances that you could scan for the common hashes.
I'm just seeing the issue for the first time and noticed it was raised 5 years ago - surely that was enough time to at least put forward a changeover date and give clients time to update.
Surprise surprise a workflow built on top of a probabilistic slop generator is a house of cards, and not owning tools that create reproducible output is asking to have it blown down.
Wait so if you're gonna allow access without authentication then why bother putting pangolin in front of jellyfin? Does it help in some other kind of way? I don't really get how it helps without interfering with apps accessing jellyfin.
How do you get apps through something like that? Do you have to open your browser and hit the URL periodically to handle auth there and it just remembers your IP?
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.
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?
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.
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?
Do you know what section of the settings that's in? I checked them all and didn't see anything related to search results. I don't mind the posters tbh, it's just that you can only really see 2 results vs 5 in Plex. Not a big deal but it's just kind of comical how so many small paper cuts have remained the same over so many years in jellyfin.
If it's a nothing burger then they should come out and say it's fine to run your instance publicly then
I just want Findroid to support transcoding. I hate that the official app is very obviously just a webview - I mean if I couldn't tell then I wouldn't care, but it doesn't feel very native and behaves slightly glitchy when navigating around. Sometimes instead of scrolling, the webview does the little "stretch bounce" overscroll thing. I wish they could get an experienced android dev to make a polished native-feeling app.
I honestly feel like 99% of my aesthetic issues with jellyfin would be solved by having the Overseer devs do a redesign. Overseer looks amazing and I tried to make a jellyfin theme to copy it and Plex, but found that not enough elemts had classes for me to select with CSS so I gave up. Jellyfin vue looks pretty good but suffers the same problem as third party apps - being under heavy development with lots of missing features (last I checked I couldn't get subtitle selection to work)
Here's a bonus one: why does the Plex search results look so much better??
Yes that's what I would like to advocate for. I did something similar with LunaSea, but often people suggest doing that with Jellyfin and are not aware that almost no apps support it, and that adding exceptions for the API makes you basically as secure as not having it. But people tend to get very defensive when you try to tell them that something won't work, so I try to phrase it as a question to see if I can get them to understand what the limitations are in a way that's less confrontational.