Leaderboard

General We at Emby believe in privacy, and as such we don't have any telemetry in place, we do no datamining, we do not store and correlate any connection data, user information and server ids - which means that we have no way to identify and know anything about the owner of a specific server. In an emergency situation like the recent BotNet takedown, it can happen that it is needed to weigh out one good against another and we can only assume what the majority of users would prefer (being hacked or vulnerable to be hacked without knowing or us taking action). In this case - for taking action - it was crucial to get reliable data and information for proper assessment. We don't know about your servers and we don't have any way to access them. But we had to find a way to get information from your servers in some way in order to assess the situation and possibly take appropriate actions and eventually, we used some auto-updating capabilities built into Emby Server, and so it was your server who initiated the connection to report back the information we needed. Conditions The local detection that we ran, performed a categorization into the following thee cases: Systems that got hacked Systems that are in danger of getting hacked Systems that are not vulnerable We have decided to report back only in cases 1 and 2. In case 3, no action was taken and no report was sent back to us. Collected Data Here's an example of the data that got reported: { "Id": "b649349bacf411a9a945eaa7aa675146", "Version": "4.7.11.0", "OperatingSystemDisplayName": "Win32NT", "OperatingSystem": "Windows", "SystemUpdateLevel": "Release", "Plugins": [{ "Name": "EmbyHelper, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null", "Version": { "Major": 1, "Minor": 0, "Build": 0, "Revision": 0, "MajorRevision": 0, "MinorRevision": 0 }, "AssemblyFilePath": "file:///C:/Users/user/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll", "Routes": ["/EmbyHelper/Ping", "/EmbyHelper/RunCommand", "/EmbyHelper/RS", "/EmbyHelper/Keys", "/EmbyHelper/CleanLogs", "/EmbyHelper/DropLogs", "/EmbyHelper/File/List", "/EmbyHelper/File/Read", "/EmbyHelper/File/Write", "/EmbyHelper/File/Delete", "/EmbyHelper/Version"], "FoundByName": false, "FoundById": false, "FoundByRoute": true, "FoundByApi": false, "Alert": true } ], "Alert": true, "UserSecurity": { "AdminsNoPasswordLocal": 1, "AdminsEmptyPassword": 0, "UsersNoPasswordLocal": 0, "UsersEmptyPassword": 0 }, "Artifacts": { "Alert": true, "FoundInScripterConfig": false, "ScripterConfigLines": [], "FoundInFileSystem": true, "FilePaths": ["C:\\Users\\user\\AppData\\Roaming\\Emby-Server\\programdata\\plugins\\EmbyHelper.dll"] } } FAQ As there have been user questions about this, I want to clarify the following: At no point in time did we access any user's Emby server from outside We don't know your server, we don't know how to access them and we have no means to access them The data we collected (see above) does not include any personal information No user names No e-mail addresses No host names No IP addresses No Emby Premiere keys We did not log the IP addresses from which the reports came from The data exists in form of log entries in a cloud project only It won't be further processed or imported into a database The whole project will be dropped in a while and all data will be deleted

Thanks softy!! And appreciate the openness of this. I’ve always known Emby has never collected any user data or stats, right from day dot of VB and MB. I’m on board with this and think its a very responsible action to take. so thanks emby team

Hi. That is not our intent. As you can see there is a huge red banner on this site plus we submitted a CVE report ourselves. We went to considerable effort to identify and mitigate affected systems and that was our focus as opposed to a blast email to everyone but there is also an issue with that as we don't have the email address of most Emby server owners (because most run for free). So we were in a situation where, if we sent some sort of blanket email, we would be inundated trying to address all the people that are not actually affected which would take away from our ability to help those that actually were. So we chose a much more targeted and direct approach to try and protect people as quickly and thoroughly as possible. Thanks

Massive props to @FrostByte, everything is working. Again, if I have not said it before, thank you for all of your patients and help.

There's a CVE now: CVE-2023-33193 Advisory: https://github.com/EmbySupport/security/security/advisories/GHSA-fffj-6fr6-3fgf

I'd like to hear from the Emby team as to why it decided not to act on this reported vulnerability a long time ago. I suspect, though, we will never be told. Kudos to @psefor taking the time to report.

People do not usually enter the forum, most people doesn't even know it exists. Full disclosure to everyone possible is always the best approach, because there are people affected that might not realize they are affected. Yes, I get that you don't have the email of everyone that ever downloaded Emby, but doing a reasonable attempt to inform registered customers is the lowest bar possible and you have not cleared it. And yes, you will be innundated, thats on you because you had three years to patch this. You did not take down a botnet, you took down the part of the botnet that you had access to, but there's probably lots of compromised systems out there that have no idea what's going on. If you are trying to argue that informing less people of your security issues is better than more people, then I think your approach to security is severely out of date.

Starting thread for assistance with the Security Advisory 2023-05-25. https://emby.media/support/articles/advisory-23-05.html Post here for questions and help with the Linux platform.

I'm going to put these changes into the next beta build.

the beta was fixed in version 4.8.0.31, so yes you are far behind and should upgrade to the latest 4.8.0.37 You cannot go from beta 4.8.x to stable 4.7.0.12 due to major database changes. You would need to start from scratch if you wanted to move to stable at this point.

So just a quick update - looks like ddns was not updating - so we fixed that and port is now 100% open (wasn't before). OP is testing .. but I'm getting a 'Forbidden' on the splash screen/curl - so possibly related to connection https enforcement (needs to be disabled or preferred) .. will report back after the OP testing.

The fact this was reported years ago and wasn't resolved before it became a big problem, they deserve some egg on their face for that. The rest of this is really just a lot of hair splitting, salivating and hand wringing over the potential for a public apology/shaming from people who haven't had their favorite feature request implemented yet. Notifying the effected servers through their logs and putting them in a position where their server is safe but they have to seek out more information was a fine response to a situation with no good answer.

Again, many many THANKS! You and your team and everyone here are the BEST. Thanks so much for taking the time to help me and many others. I owe you many many beers. Cheers!

The problem is that you informed no one. Posting a banner on the web site of the forums is not notification any more than my stapling my resume to a utility pole would count as notifying every local business that I am looking for work.

I see a lot of deflecting, a lot of explanation, and a lot of justification. What I don't see is any sort of acknowledgement that anything is being done to improve the process. Combine that with the "marketing spin" being put on this and leaves a VERY bad taste in the mouths of users. As has been mentioned, Emby did not "take down a botnet", it took down a specific number of servers around the world that were participating in a botnet. It is also massively misleading to claim that it was taken down "in 60 seconds" - while that may have been how long it took to post the plugin update and begin the process of pushing it out, it took TWO WEEKS from the initial hack, and more than three years since the vulnerability was exposed, before anything was "done." Further, how many servers around the world are still running affected code and have been compromised? To think that there are a whopping 1200 servers GLOBALLY that were impacted by this is not at all reasonable. I came to Emby because the front-end functionality was significantly more reliable than that of Plex. Due to Emby being insanely slow to implement very basic, repeatedly asked for features on the back end, I have continued to run my entire Plex setup solely for the purpose of the DVR functions. It looks like I will be needing to entirely rethink my entire setup once again because this overall response it not at all well-seasoned for a commercial entity.

I appreciate the quick fix (if it really wasn't a 3 year old exploit that you all have known about). However, a simple email to all addresses that you did have would have been the right course of action. A simple, we are aware and are working to fix this and if you have questions here's a link to the forum post where our staff can best answer your questions would have been great. It does make people antsy and I guess that's where everyone is going with this. You can't please everyone and you all made a decision that you thought was in everyone's best interests. Right or wrong you stand by it, learn from it and move on. More communication with your customer base is never a bad thing. You have a great product... broadcast that when everything is going great and broacast it as well when things are broken. People value transparency more than anything.

I didn't even realize all this was going on until 4.7.12 popped up on my dashboard, kinda surprised me since I wasn't expecting another update until 4.8 releases so I came on here and found quite the snafu. Glad that it seems like I wouldn't have been a target in this one. Always feels like you can do more to secure your setup and every so often with an intrusion like this you get that warm, fuzzy feeling that you're actually doing a decent job lol. I know the Emby team isn't very large. People think once you ask for money, you must have all the resources and manpower in the world with an expectation that get things handled perfectly... when in this case at least, it's more likely a few individuals working around the clock assessing a serious situation. At the end of the day it sounds like the team did their best to resolve the issue and protect users systems quickly, and they've been upfront here on the forums with what they did and why. I appreciate that. Good job guys.

I think it's a fair question if you run the Release version - because no server updates were made prior to the action - only Plugin updates from 18/05 on my system. Beta had lot of main updates around this time - but this was actually for the fixes. So if the main Release was not updated until .12 - then the only 'update' must have been via a Plugin... ? and I believe that is what CBers is asking ... edit - doh - yes, softworkz has confirmed.

Yes it was. I think there's no point in keeping it a secret because it's clear enough by now and it's the first and last time that we could use this method.

Thank you so much @softworkzand team! It's such a relief to see you and others at Emby not only protecting our privacy, but also protecting the security of our personal servers. I'm so glad Emby has mechanisms in place to combat these attacks AND act quickly to prevent further damage. Thank you!!!

Given the latest events, isn't it about time the development team took this a little more seriously and stopped kicking it down the road? All internet facing systems in 2023 should have the option for MFA.

Just want to point out here that regardless of whether you allow direct external access, there are still multiple vectors that an adversary can use to infiltrate your network remotely by tunneling back over your outbound connections. These include such vectors as phishing emails, malicious websites with o-day exploits, and updates to your installed software which contain malicious code embedded in the supply chain of the application developers. I don't disagree with your point about security being a user choice. But your certainty of security by not having open public ports is a bit naive.

External user has confirmed on two devices that it is working. Thank you rbjtech for your help!!! Who knew it would have been DDNS not updating, but at least it was something simple. My server is setup to "preferred, but not required" for secured connection. Is there an inherent benefit to use https vs http in my setup? All users I provide the fqdn directly.

Online radio stations and even IRL ones mitigate repetition of music through the use of rules. You can specify that a song/artist/album can only be played once during any given "x hours/days". Can it be integrated into Emby itself? This would be a great solution to the repetitive use of the same handful of episodes/movies in Playlists / Shuffle and VirtualTV, so we get a better mix of content. As a last resort, an optional rule within shuffle/playlists could include "only play an episode/show/movie/music if it hasn't played in "X' amount of time". Thanks!

Will I still be able to login as admin after the server reboots to apply the security fix?! The dashboard msg says: "One or more administrator accounts are configured to allow logging in without password in the local network. For security reasons, this option is no longer allowed for administrator accounts and has been disabled. The following accounts are affected: admin" but this is wrong! I do have a password for this acct. So, after the server reboots, will the admin acct be locked out since Emby thinks it does not have a password? I don't know if the msg is just poorly worded or if I am just dunce. What has been disabled and what is the impact of that for an existing admin acct is not clear.

Thanks, I just updated to 4.8.0.32 which seems to be the newest for DSM 6.

That should be OK. And as you note, the current beta (since 4.8.0.31) does not have the vulnerability, nor does the current (new) stable version 4.7.12.0. Also, if you use a reverse proxy, that almost certainly blocked the vulnerability before it affected Emby. Paul

No, you can lend your support here: For local Web app only, you can hide it via custom CSS.

This was reported three years ago? Unbelievable. What level of incompetence is this?

Wow I can't believe that this was reported and ignored for over three years.

You have your files incorrectly named for multi-versioning, missing " - " (space-dash-space) after (Year). https://emby.media/support/articles/Movie-Naming.html#multi-version-movies

Okay, terminal will work. Basically, do these steps in Terminal. You will need to use an account with Admin privileges. The port will be the one you used when you enabled SSH on your NAS ssh yourNASusername@yourNASip -p yourSSHport sudo -i cd /volume1/@appdata/EmbyServer/plugins dir del the files you need to

For you own benefit, it's recommended you go through the advisory notice and check for any evidence of the files described in the article, then take the necessary actions if required.

SSH enabled, admin password reset, NAS restarted. Will try Terminal to SSH into NAS. Hopefully I’ll be able to follow your instructions to clear the .dll files.

I understand and sympathize with your comments. I too do not expose any of my local devices or applications directly to the Internet and in that alone have mitigated much of the risk for my home network. However, not all Emby users are so inclined and as recent events have shown, many do not take even the most basic steps to protect their application and home network. So it does indeed fall back on application vendors to think about deploying apps with a default configuration that addresses the lowest common denominator, the end user that takes NO action to secure their hosting environment. Indeed the vendors have to as any breach, even if it is not a shortcoming in their code, reflects poorly on them and their product. It is then up to the rest of us that are comfortable identifying the risk level we are willing to accept, to adjust the application configuration accordingly.

Finally figured this out. Thanks a lot FrostByte, it was your resources that helped! Two main threads were able to get me there. Downloading and setting up WinSCP and NAS settings: Creating permissions to delete trouble files through WinSCP:

I think ultimately the local network password option will go away and we'll just have to improve the login and user switching experience in our apps.

For all that may share with over 25 FRIENDS and FAMILY if you are over the limit of devices, how about having them buy the app. If your SHARING with them what is the big deal over a 5 dollar app when they are getting the content and you are putting in all the work to provide it. Just Saying!

You should be able to do something like this:

I have Emby running on RL 8.8 and everything works great. I had started out on FreeBSD 12 but could not get hardware transcoding to work. HW Transcoding works perfectly on Rocky Linux. I installed the Nvidia drivers following the standard RHEL instructions. After that I can use my RTX 3050.

sudo helps been on the mgmt side to long and losing my skills.

Not only was this not fixed in over 3 years, but it was open to anyone accessing the forum to see! Lots of lessons to be learned from this, and I can only hope they are.

A quick way to find the files on a host based Linux installation (rpm/deb), might need elevated privs with sudo or as root: $ find ~emby | grep -iE 'helper.dll|embyhelper.dll|readystate.xml|embyscripterx.xml' If you're running the Emby server as a different user than replace ~emby with ~user. Though if you are then you'd likely already know the location and how to find the files...;-) When using Docker: $ find <path to host mapping for /config> | grep -iE 'helper.dll|embyhelper.dll|readystate.xml|embyscripterx.xml' Then follow the Actions listed in the Security Advisory.

You can't during recording, but the diagnostics plugin actually has a command line search and replace feature for transcoding playback, so you could actually use that to experiment. Just make sure to play the live stream from the channel, rather than starting a recording and playing the recording. That article is actually very helpful though and it sounds like we want to increase the value of reconnect_delay_max.

https://emby.media/support/articles/advisory-23-05.html Sometimes it sucks to be right. This has finally been fixed in 4.7.12.0, thanks for that.

http://{ip}:port Your server dashboard also displays this information. If you're adding a DDNS you can set this in Emby Server network settings so that the domain name will be your remote address.

That is exactly what I thought. I just cannot trust my conclusions because my meds makes it hard to concentrate at times. I thank you immensely and will rest easier because of your response. I wonder if I need to work in an extra nap today?

The key setting is this If your Admin account did NOT have the above set (ie it said don't require a password on the local network) - then the attacker combined this poor choice with the local/remote IP spoofing to then login as Admin remotely without the need for any password, set or not.

result: