Emby Vulnerabilities

[theGEBIRGE]

Hi,

I've reported two vulnerabilities for version 4.7.14.0 way back on the 12th of December 2023 to apps@emby.media:

1. Pre-authenticated retrieval of every image in a user's library (among other things).
2. Post-authenticated remote code execution on the server.

Since then, I've followed up two times. While I've received an answer the second time, it didn't address any of my questions.

My proposed date for releasing the details of the vulnerabilities was the 12th of March - which again wasn't addressed.

This issue is my last attempt at getting any kind of feedback. I don't want to simply release the details (including complete exploits), as that would hurt the users the most (Shodan reports about 23.500 reachable hosts as of this writing).

So:

Are those issues being worked on? Maybe there's already a fixed version or at least a timeline?

Cheers
Frederic

Edit: I'm adding this mention in the hopes of better visibility. @softworkz

[softworkz]

Hi Frederic,

please take my apologies for the late reply, this is the first time I'm seeing this message. I must have missed the initial post and I never managed to configure GH to send me e-mail notifications on mentions.

Regarding your issues:

• 1. This is currently being worked on and has been commonly known for a long time already
• 2. It seems this hasn't gone trhough to me. We have enabled reporting of vulnerabilities in this repo now. Would you mind to drop a copy of your report here?
     Just go to the Security tab and click "Report a vulnerability". These reports are private (until disclosure)

Thank you very much
sw

[theGEBIRGE]

Hi softworkz,

thanks for the clarification. I've created the advisory. The second issue was already fixed quietly (I think).
I did some quick testing at the time (see https://gebir.ge/blog/take-your-media-anywhere-with-emby/).

Cheers
Frederic

[softworkz]

Hi Frederic,

thanks a lot for filing the issue. Before getting to get this straight and settled in a formal way, I wanted to talk to you a bit. I can understand very well how frustrating it can sometimes be, when you do work in favor for somebody or some entitiy, and you keep getting ignored, even though it would seem that it would be in the best interest of theirs. I can only apologize on behalf of Emby for being so sparse in responses. Unmatched expectations may to some extent also be due to picturing Emby as a commercial business, like usual while in fact, it's still the same developers who have started developing Emby with a high amount of enthusiasm and insane amounts of work. It has grown into a business in a formal way, but it's still the same people and the kind of transformation towards professionalism, re-organization, commercialization with rapid growth and likes hasn't happened. It's still the same people, running things in the same ways. Success has been growing just very slowly over a very long time - without generating relevant income initially.
Emby has never been an open source project of the typical kind. Everything has been developed by the same few persons with just a minimal percentage of community contributions to the code (that's why it was even possible to switch to closed source: the contributed code could be replaced by own code with moderate effort).. Probably it was more about following hype and trends that a GPL license was chosen in the first place.
Having worked hard on Emby, eventually they introduced an option for users to become a "supporter" for a few dollars and in turn you got unlocked a some extra features for being a supporter.
At some point, a guy came around, who wanted to have those extra features for free - without becoming a supporter for $2 (or 3) monthly. He seriously complained about it and demanded to get it for free. A little later, that guy had developed a cracking tool in order to unlock the supporter features in Emby without payment and published the tool on GitHub - which of course led to controversies and lots of discussions. That guy seriously claimed that the Emby source (99% developed by the founders and 1% community and 0% by that guy) would belong to him and everybody and that's why he thinks to have the right for getting the supporter features for free and for creating a cracking tool.
It was a difficult situation - I've been right in the middle of it, so I'm not telling from hearsay - and my advice was to get out of the GPL trap as quickly as possible - it was an existencial matter as this guy was about to completely destroy that little source of income. There had never been plans before about going closeed-source before and there was a lot of hesitation to go that way - but eventually, it was the only way out. Without those events, Emby might still be open-source today - or at least larger parts than there are now.

That person I'm talking about - was the primary founder of Jellyfin.

Something to keep in mind with all of this: Emby is not an open source project run by volunteers! They offer paid subscriptions, which incidentally is one of the reasons why the Jellyfin team decided to fork.

So - no: Emby had provided a full featured complex product for free and offered a number of extra features on top which were exclusive to "Supporters". The Jellyfin founder demanded getting this from Emby for free, even though there was an online service included for which Emby had upstream expenses.

On the legal side, Emby had made a mistake in their choice of license; from a moral point of view though - JF didn't "rescue" the code from a community project - they rather stole the lifetime work from the Emby developers - and they knew it.

Not many people know about this today - so you may see it as a kind of quid-pro-quo disclosure. ;-)

Before getting to other points, I'd like to say that I appreciate your effort in uncovering those vulnerabilties andI think that it is highly valuable for us and other. The very least thing you deserve is somebody talking to you about your findings and in this regard, I'll try to remedy the bad experience in the past.

(tbc)

[softworkz]

Remote Code Execution through XSS in Admin Dashboard

What you found here wasn't just a security "hole" - it was rather an "open space". If you had looked further, you would have found a lot more of such injection vectors. The appropriate encoding of non-static text had never been explicitly done anywhere. Only cases where DOM APIs are used for constructing content with properties like .innerText were not affected.

A while ago, a complete review has been done to identify all applicable cases and fix them accordingly.

Your findings are clearly valid. Thanks!

(tbc)

[theGEBIRGE]

Hi sw.

Let me preface this by saying that I have absolutely no stakes in this matter. :)

I looked for a C# codebase that I could audit for vulnerabilities to satisfy my security interest (which back then was only a hobby). At first I've landed on Jellyfin, which in turn made me aware of Emby.

Judging by your long reply, I've clearly struck a nerve with the blog post, which wasn't my intention. I'm all about the vulnerabilities and zero about politics.

That being said, your version of the story is very interesting and definitely different from the usual narrative of how the forking process happened. Thanks a lot for sharing!

Cheers
Frederic

[softworkz]

Encoding/FfmpegOptions

I doubt that the underlying technique of switching the encoder binary in order to gain remote code execution was fixed

This is not a "technique". It is a regular and intended feature. You can see the admin UI for it by installing the Diagnostics plugin, then on the server dashboard "Diagnostic Options" and on this page the 2nd tab (FFmpeg Options).

Essentially, this is "by design". I usually hate this "by design" declaration because it is often misused as a means for expressing something like: "it is like it is"

So let me explain; The "Design" in this case: is that an authenticted admin user can configure all kinds of settings for Emby Server and plugins. There are various cases where executables can be configured and it is required for Emby Server admins to do that.
It is not limited to Emby Server code but there are also plugins which allow to configure executables and as an Emby Server admin, you can install arbitrary plugins from the catalog.
Even when we would mark those cases where exectuables are configured as restricted (e.g. require a LAN connection to change it) and audit all plugins in the catalog to mark such settings accordingly, it would not suffice. There are also more subtle (indirect) ways for an Emby Server admin to get some specific binary to be executed. I know of some, but there will always be clever people like you, who will find other ways, when we would try to close the known ones.

Eventually, we - and users - need to face the fact that access to an Emby Server in the context of an Emby Admin User is equal to having shell access to the server. That's an inevitable truth. We haven't documented that (yet we should do), but we also never claimed it to be otherwise.

What's important to note, though: This is in no way equal to having full system access. Possible actions are always restricted by the permissions of the user account under which the Emby Server process is running. On Windows, you can't do anything which requires elevation and on Linux, we typically install a special user account ('emby') under which the server is running.

In the future, we are planning to change the installation on Window to set up Emby Server as a Window Service running under its own user account, to get it separated from the account context of the installing user.

[softworkz]

Judging by your long reply, I've clearly struck a nerve with the blog post, which wasn't my intention. I'm all about the vulnerabilities and zero about politics.

TBH, I've been kind-of waiting for an occasion to write down the story again from a more distant view - and that was a good one. So I wrote it for you, but also for having it at hand for copy-paste in other situations later.

But amittedly, it's also true that I find it annoying and sad that the official narrative is so far away from the truth 😉.