Leaderboard

Advisory: https://emby.media/support/articles/advisory-23-05.html A Full Report on the Incident is Available Now:

Separating user and admin accounts is a basic tenet of system security. Paul

You can setup non-admin accounts to use a pin locally.

Making admin accounts accessible password-free is simply bad practice anywhere. Why would you even want to use a TV to administer the server? Do that on your desktop or tablet. Paul

I love this thread. "Hi, I am trying to commit crimes. Please allow me to commit crimes."

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!

OK, I appear to have it fixed. First problem that allowed me to get up and running again was correcting the permissions of the /var/lib/emby folder to 755. Then I had access to my logs. Reading the log led me to the correct folder for the EmbyHelper.dll, ReadyState.xml, & EmbyScripterX.xml files. Deleted all of those. systemctl start emby-server started the server and allowed me to change my admin password. Rebooted the server and emby started as expected. I marked the permissions as the solution, since that is what allowed me to find the files necessary for removal. Once I did that, my command to find them worked, even though I had run it as sudo. I don't quite understand that though. Thank you very much @sargenthpfor your help!

I would NOT recommend setting anything to xx7. That gives the world full read-write access to that folder. That folder should have 755 access (Owner Full Rights, Group Read Rights, Other Read Rights).

I for one am appreciative of how quickly you acted regarding this hack. I run Emby in docker (on Unraid) and it doesn't appear anything has been compromised and I didn't see any unusual activity in Emby but as your blog suggested I changed everyone's passwords as a precaution. Thank you for being diligent.

Sounds like someone has no idea how to do security and the reasons why.

The image looks like it might be notepad, and windows doesn't like/let you save over the hosts file.. So @Methodman104 after you add the line to the text file as CBers stated, you might have to save the file to a different location on your computer, for instance, the desktop. The file will then be hosts.txt instead of hosts. (You may also need to enable, "show known file extensions" in windows) You'll rename hosts.txt to hosts (the icon will go from a text document to a blank document) Then you can copy/paste/overwrite the hosts file (youll need to give admin write rights)

Add a new line and enter the following: 127.0.0.1 emmm.spxaebjhxtmddsri.xyz Then save and close the file. That way, it something tries to get to emmm.spxaebjhxtmddsri.xyz, it will get blocked/redirected to your computer.

So you want to use your admin account, at all times, even on a tv where theres no need, and you want that account to have no security on it after its been verified its "you"? Ya, I'll be that person.. maybe going back to Plex is the right path for you.

If your admin users can only be accessed with a good password, even locally, you should be fine. Also, if you have a reverse proxy, that should also block the vulnerability in its default settings. The problem arose because people loosened their security relying on the ability of the server to identify local access, which the vulnerability broke if there was no other defence.. Paul

Correct. Personally, it is worth a small investment in your time just to give your system a 'once over' but only a compromised system needs those actions.

I've never pinned containers to the desktop in Synology either so I'm not of help. I'd make a post in their forums to ask how this could be done on 7.2. Concerning the DSM 7.2 upgrade for anyone who followed my instructions previously to allow use of NVMe drives as volumes you have nothing to worry about. The GUI still won't show things correctly but the volume(s) created will work just like they did on 7.0 and 7.1. Be aware that DSM 7.2 will require a new build of Emby Server built for this which you can down from or normal download site. All you need to do is apply the DSM 7.2 to the Synology system followed by the installation of the new 7.2 build of Emby Server and you're set. Carlo

Rocky Linux working well so far. The only thing that popped up with the SELinux prompts about creating a user.

Clean way to do this is with a service unit override. 1. Stop emby and restore the original unit file. 2. Verify that the unit file has the original ExecStart command: $ systemctl show emby-server |grep ExecStart 3. Create a unit override to add the Nice parameter. This will open an editor where you can add Nice=-5 to the service block. $ systemctl edit emby-server Add: [Service] Nice=-5 4. Exit and save the override file. Y and enter for the prompts. 5. Start the Emby server. And run top/htop to verify the new nice value.

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.

Thanks, hope you get a handle on the extra work and looking forward to the version .12 release

I wondered about that. I gave it a go anyway and deleted Library.db, however, the Emby Statistics plugin task still fails so I just restored the backup of Library.db and will continue to see if I can figure out the issue. Thanks for your help!

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.

That's in the userdatas table. playback_reporting is a from a plugin and not part of the emby server core. No, it's all together.

Thanks Luke, great idea on shutting Emby down 1st then scanning afterwards. Luckily I caught my error earlyish, probably only 50 movies to redo, +90% of my stuff is TV shows which I did correctly

Hi, that's helpful. Thanks for the info.

To any and all that are interested - As a side note, I found the EmbyHelper and EmbyScripterX.xml in my backups going back to May 15th (I only keep 10 backups). I went ahead and deleted all of the backups since there was nothing in them that a fresh backup wouldn't catch. I could have gone through all of the backups and just deleted the files in each one, but this was faster.

I am glad you have it going! sudo is a utility to allow an user to execute something as a different user (if they have the permissions to do so). Linux is very user and security oriented. The Emby Server needs to run as the service account/user "emby" in order for it to have access its folders and executables.

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.

Even when using Connect login via the local credentials is possible. If you didn't have passwords on those local credentials then you could just enter very strong ones for all of them and your users don't even need to know them (if they always use Connect).

It would be more preferable to start and stop Emby with the service. That is what systemctl start emby-server does. If you are using a Linux flavor that is not using systemd you might need to execute: service emby-server start Note: If you are running as your account and not root you will need to add sudo in front of these commands.

Okay I will say it to her and say the result, thanks you

Went thru my Asustor configuration and only had the 'EmbyHelper.dll' and not the 'helper.dll'. Curious if that makes any difference. Out of an abundance of caution I've deleted my Emby install (which when uninstalled from the Asustor app store, DOES NOT remove the hidden Emby data), deleted the Emby directory via SSH and am awaiting the .12 release before rebuilding. I would like clarification on this from the explanation "Analysis of the plug-in has revealed that it is forwarding the login credentials including the password for every successful login to an external server under control of the hackers." Was this a compromises of JUST Emby credentials, or ALL user (Linux) accounts? Also makes me wonder how the Emby Connect syncs passwords between end user and Emby configuration - it's just linked via the email address, correct? Because I never give out 'passwords' to end users, they just setup on Emby connect, and I link them. I'd suggest making some user setup changes to not allow blank passwords as well. Love the product and I know this sucks - thanks for working so hard as you all are to make this right. It's the rapidness of the response that I'm judging you on and kudos. You all need a nap and beer after this.

If that file existed on your system then you were affected by this attack. However, other than the existence of those, we haven't determined any other changes or harm that actually was done so that may be it. It should be assumed that all of your logins were sent to that remote site though so that may have been what they were after (for use later). Just be sure to change all passwords.

MMan, Only remove the # pound sign from the last line with the emmm.spxaeb... It looks like you removed all the # signs. The lines above are just examples. Those are supposed to keep the # sign. Removing all the # causes errors and probably slows down your system startup. The # comment feature is a typical programming step. I think people assumed you knew this.

2023-05-25 09:45:32.594 Error App: We have detected a malicious plugin on your system which has probably been installed without your knowledge. Please see https://emby.media/support/articles/advisory-23-05.html for more information on how to proceed. For your safety we have shutdown your Emby Server as a precautionary measure. Go through what @ebrposted above.

What about this?

You might be able to screen cast using google cast features but I would not recommend that. I would suggest to your user to use our Android app.

Looks like you can either wait for the patch (4.7.12) thats coming out soon, or you can manually do it. I just did it manually and it was about an hours worth of googling and screwing around with winscp. If you want to try to tackle it manually, follow all steps listed in this post: After you've done that and are able to login to your nas via winscp, follow the steps listed on the page linked in the red bar at the top of the site (https://emby.media/support/articles/advisory-23-05.html#actions-to-take)

Ive been digging into this a lot because I am running into this issue of my recordings stopping early, with similar messages showing in the logs. First, the message "operation not permitted" is being thrown by ffmpeg, so this indicates ffmpeg is failing. Although it may be an issue with the source, ffmpeg should be able to recover and not fail. In the log, I see the following as part of the ffmpeg command line: --reconnect_delay_max 2 This is the maximum delay in seconds after which to give up reconnecting. Two seconds seems too low, and this may be why ffmpeg is failing. Maybe trying more seconds before failing might save recordings that are failing now. Also, there are two command line options that might help that I dont see being used. reconnect_on_network_error - Reconnect automatically in case of TCP/TLS errors during connect. reconnect_on_http_error -A comma separated list of HTTP status codes to reconnect on. The list can include specific status codes (e.g. ’503’) or the strings ’4xx’ / ’5xx’. For more information, please see an excellent writeup at https://medium.com/intrasonics/robust-continuous-audio-recording-c1948895bb49 I hope this was helpful and I hope some of these suggestions can be incorporated in the future. Im the meantime, is it possible for me to change the ffmpeg command line in Emby for live tv recording? Ive looked pretty extensively and cant find it -- maybe its in a .dll or something. Anyone know where this is located?

Then you are not at risk.

@Bagulthat's really nice, thank you ! About my previous issues with http3, I moved caddy from a pi4 to a more powerful toy and all my issues are now ancient history. Reverse Proxy is rock solid and Emby has never been so fast even if I still don't know what was the issue with the pi...

If you have none of the symptoms, and already have in place the recommendations, you should be good to restart Emby server.

Never mind, I wrote a Ruby script that does some API requests to do the job.

Hi. The rules have not changed. This system has been in place since 2015 and is explained on the page where a purchase is made. If you have a legitimate use case, please email billingsupport@emby.media. Thanks.

Hi this is not related to Premiere. If your public IP changes then it would be best to have a domain name but the server should see the update eventually.

Please apologize. I've been working more than two days non-stop on that matter, and I guess it's time for a rest.

@blackstar88The side loading of the API seems solve the AAC issue but lead to the garbled under water sound that I get from the dolby atmos sound files

Thank you! That worked perfectly. Now I can watch stuff without interruptions while the same machine is busy with handbrake.

Those who like to use picture in picture and/or multi-task with other apps while having video playing. And by the way, testing YouTube on android it stays in portrait for all videos. In fact it just follows whatever my device setting is. Additionally testing on iOS, apple's apps are now also going by system settings for the same reason. We'll add an option to control this behavior but I would also just like to mention that several users ago when we initially forced it to landscape, we also had some users at that time who thought it was being "forced upon them".

Ok so no it's actually a special case and opus codec still works correctly in Emby with such bitrate, this is about the opus container that is limited to 256000. I normally request ogg container but seems for downloads with transcoding I made a typo and it was choosing opus container causing this issue. I don't think this worth much investigation on Emby side, Opus container have no reason to be used over ogg for this use case.