Saik0 @ Saik0Shinigami @lemmy.saik0.com

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

---

Read more

Posts

1

Comments

1,970

Joined

2 yr. ago

No. None of the items are closed. Click the "closed" items. All of them are "Not planned. Duplicate, see 5415".

No. None of the items are closed. Click the "closed" items. All of them are "Not planned. Duplicate, see 5415".

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.

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.

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.

Having it publicly accessible on a web server is distribution. And that normally IS a crime unless you have some licenses to do so.

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.

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.

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 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.

https://www.financestrategists.com/financial-advisor/bankruptcy/what-can-you-keep-after-filing-bankruptcy

It can decimate any savings you have for retirement.

They can also crawl this publically-accessible social media source for their data sets.

Crawling would be silly. They can simply setup a lemmy node and subscribe to every other server. Activitypub crawler would be much more efficient as they wouldn't accidentally crawl things that haven't changed, but instead can read the activitypub updates.

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.

Not unless the reverse proxy adds some layer of authentication as well.

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.

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.

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.

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

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.

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.

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.

The domain is a DDNS.

Eh, if that's operating in the US (or other country that cares), they may still give up the mapping to a legal request.