All Activity

@yockerI noticed some behavior in this that you might want to put some guard rails on. Specifically, I had an episode of a show whose credit detected before the intro. Since I can't imagine a circumstance when this is ever a legitimate issue (I don't think old TV shows worked like old movies where the credit reel ran first), you might want to prevent the credit segment from being written if the IntroStart/IntroEnd tag timestamp comes after. Perhaps it could even be used to weigh confidence score checks?

I literally posted up above what the exploit covers..Jellyfin was the only one that had full RCE and that is why they were contacted..Please read the entire thread before making such baseless remarks. But I'll post it again..

We do not have thje capacity to re-program a complex portal like this - and I don't mean whole GitHub - I mean the vulnerability reporting alone. They have proper separation of private and public information exchange and reporters of vulnerabilities like it, because they are getting proper credits for their findings through GitHub. The ability to acquire CVE numbers has its own hurdles and is not something we can deal with - GitHub handles all of this very well. Apart from that, the way for reporting that we provide is not even up for debate.

Upgraded to 2.0.7 Been running through several videos across tv shows this morning that would previously crash about halfway through while subtitles were on. Everything seems to be stable so far! Even made it through multiple episodes of a single show auto playing without any crashes Thank you @Lukeand team for all your work on finding a fix

Yes, like it has been said before, if you get to acquire such video from a malicious source, then ffprobe (not ffmpeg) might crash. But not Emby Server. It would continue to be working.

Because not all us use GitHub? I freaking hate that site. This kind of info HAS to posted here, on the forum.

Yeah but it doesn't really matter what that video codec is used for. What matters is if ffmpeg detects it, no? In other words if the content, regardless of size, happens to be identified by ffmpeg as MagicYUV then that opens the door to the exploit.

It is specific to that single video codec, prmiarily used in professional post-production (lossless compression, fast and multithreaded decoding, huge video files but still much smaller than individual images).

We DO have a process in place and a way for confidential disclosure of security issues: https://github.com/EmbySupport/Emby.Security/security/advisories Three cases have been processed (analyzed, fixed, validated, released, advisory published) already, two others are in progress. Once confirmed and the patched versions are available, these will be published as well.

I have been seeing s6 errors on 4.9.5.0, as well. After a few hours of troubleshooting, found this thread. For me, the problem manifests as: Running the container with podman, it does not ever stop when given `SIGTERM`, requiring podman to `SIGKILL` the container. I backtracked to 4.9.3.0 and my setup works fine again. # Running 4.9.3.0 [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] waiting for services. [s6-finish] sending all processes the TERM signal. [s6-finish] sending all processes the KILL signal and exiting. From Github copilot:

So far it seems significantly better, Virtual TV seems to work now when the playlist delay is set to 0. I am able to skip to up next episodes properly also. I will continue to use it and report any issues I face. Thanks for the all the help, I really appreciate it.

Is ffmpeg used to process metadata images in any way? Is it used to render, resize, scan or modify banners, actors, directors, thumbs, station logos, etc? Edit to add: If this CVE is specific to video codecs and not in any way affected by images then I retract what I posted. But if a file delivered as an image can contain a malicious payload and still be consumed by ffmpeg as if it were a video there could be other vectors to exploit this.

Since the vulnerability is in ffmpeg, how would an image provide an exploit surface in Emby? We are addressing the issue but RBJ is correct, the actual risk here is very low and should be pretty easy to identify (due to the huge size of a bad video). Beta is already handled and stable is in-process.

There isn't anything in the current beta related to this FR but the discussion went away from that and to "features" in general. I would say we have some major new features in the beta.

Is it time to rethink strm files? Maybe we should be able to indicate the media type in the file name? movie_soundtrack.mka.strm? movie_soundtrack.audio.strm? Does Emby assume a movie because of the extension?

Greetings I've been using Emby for well over a year now and have experienced 'Drop OFF' so much so that the wife refuses to use Emby for any serious TV viewing. My AI pal says that this is a common occurrence reported by many. The symptom: some channels like CNN play and then all of a sudden drop - Emby just returns to the main screen with no warning and nothing in the logs. Personally I think this is an ffmpeg failure - Emby seems reluctant to re-try playing for a blip or major vid change - it just exits where other players like VLC will keep playing. To that end I found Emby Theater - portable - this allows for a third party video player but unfortunately Emby does not seem to pass the necessary information for VLC to launch. If Emby theater offers an external player option, it should reliably pass the stream URL to that player. VLC is the most common external player, yet Emby Theater does not pass the correct arguments to it, especially in portable mode. I'm a retired software engineer and don't mind fixing things my proposed solution : Emby Shim: We need to know: Where system.xml lives Where externalplayers.json lives Whether portable mode overrides the standard %APPDATA% path Whether portable mode uses a relative config folder Whether portable mode ignores external player settings unless a specific flag is set Once we know the correct path, we can: code a shim ( I will most likely use a python script ) that will launch VLC for the chosen stream. I can guarantee it will not drop-out the way Emby does, and VLC 'will' retry automagically for minor stream blips. Other Info: This happens on Emby Windows and also Emby Linux - Linux seems a tad more stable but not much - it still happens. You say lets re-create ok - I have a way to do that: I have also made my HDHR channels play in .m3u format example: #EXTINF:-1 tvg-id="4.1" tvg-name="WBZ 4.1 CBS" group-title="OTA,Local",WBZ 4.1 CBS http://192.168.1.255:5004/auto/v4.1 (I bet you didn't know that HDHR comes with a built in streaming server... that works perfectly - uses port 5004) Anyway if I point Emby to a stream with a very week channel with lots of pixilation in normal tuning when tuning via Emby it will drop at the 1st failure and return to the menu VLC will keep playing and just wait for the stream to clear. I need this feature in Emby to avoid Drop-Off - this will be a huge fix for my IPTV playing in Emby. Once resolved I'll gladly share the 'shim' with the community. -or- perhaps I'm the one missing something if Emby has a way to let Emby Theater play VLC via the external player. Does anyone see any issues with creating the Shim ? Thanks Jan

There is no real world RCE with this CVE for Emby or Jellyfin. Read the CVE info and the investigative report. In order for them to exploit with RCE they had to explicitly disable a long standing and enabled by default kernel security feature, ASLR. It was the only way they were able to craft a payload that could result in RCE. The investigators are very clear about this in their post. DoS, silent process/thread failures and possibly server process crash are the realistic scenarios AFTER a malicious payload gets on the server for ffmpeg to process. This part is not a concern as I've been told that ffmpeg is not involved. It is still entirely possible for this type of payload (image) to get on anyone's server because almost every Emby user relies on 3rd parties to provide metadata (images) for our content. Those images we all get from any number of sources could possibly be used exploit this CVE.

Hi SamE, Thank you so much. The update to 2.0.7 fixed the issues.

Hi Luke, The issue was resolved in AppleTV version 2.0.7. Thank you very much for your support.

I would echo what others have said earlier. I love Emby, I really do, but, and I say this with genuine "love" sometimes it's not so much what you do, but how this is communicated. You had no advance heads up about this vulnerability, which is of no fault of your own, but despite the message being read, it took a long time to acknowledge with no further information until a fix to the beta branch was announced. Commiting the fix to beta in a timely manner is commendable, but for people to patch their server they need to be 1. Aware of the problem 2. Willing to run beta software. There will inevitably be large number of Emby admins who are completely unaware but would blindly update to a new stable point release and be blissfully ignorant to any CVE. I accept that this may not be the most severe CVE in existence and from my understanding no RCE is possible on Emby, however as a standard operating procedure on how to react to these I'd suggest 1. Acknowledge the issue 2. Provide a brief assessment of the risk of the CVE and am ETA on a time to fix and any suggested mitigations in the meantime, such as stop ingesting media from any questionable sources, take server offline, sprinkle holy water on the server whilst muttering an incantation. 3. Push a fix both to beta and backport to a stable release. From all the evidence it looks like Emby as a project has escaped serious issue thus far, but having a process in place for the next CVE would be very sensible. Whilst a lot of what I've said might seem superfluous, there are some situations where the optics of the situation matters a lot. We all want Emby as a project to have continued success, if prospective users come to the forum to look around, evidence of a robust security posture and professional approach makes a lot of difference. Just my opinion, and genuinely meant as constructive criticism.

Emby have patched the ffmpeg - or more specifically, they have simply disabled the magicyuv decoder in their custom ffmpeg. To note, the magicyuv codec is an uncompressed codec used for professional pre-processing, thus is extremly unlikely to be in 'common' use - if it was, the file sizes would be huge. If you source unsolicited files from the internet - then I guess there is a slim chance it may become an issue for you, but it will only cause a DoS as Emby does not allow any remote code execution in Emby anyway. I'm not speaking on behalf of Emby, but the risk of this CVE to Emby is 'low' thus they have taken the steps to remove the risk (by patching ffmpeg in beta) but have, thus far, decided not to panic the community by releasing a 'hotfix' - as this does not warranty this. I agree with this approach but perhaps a brief paragraph from them explaining the 'why' would be useful.

Greetings I have done some research on this topic, not specifically for Emby but for VLC and other players, the issue is the AC-4 Dolby Support - apparently the greedy corporate folks at Dolby refuse to release this to the public domain so if you do not pay for the rights to publish AC-4 you do not get to play it. A few other platforms like QEMPlay2 figured it out and were told to shut down, I confirmed this with the folks at HDHR some time back. It is a true shame that Next Gen chose an audio stream that the mass public will never get easily. I'm sure in time other players will pay Dolby's ransome to get service but frankly I don't expect Emby to be one of them - hope I'm wrong but so far Next Gen will just be for a chosen few, and then to make matters worse normal broadcast channels when moving to Next Gen add on DRM encryption blocking the broadcast for 90+% of normal viewers - personally I think this is a move to make cable companies richer. Bottom line: Forget ATSC3 until there is a major landscape shift. On the plus side HDHR software play it just fine as long as the channel you are attempting to tune is not DRM encrypted. Oh yeah and the feds plan to make ATSC3 the norm and eventually do away with ATSC - cable companies will love this. Jan

thanks! didn't know that in a change the layout. I still find the menu in that addon a bit confusing.. will try later. thanks!!

Hey, do you have a roadmap? ive been in beta for a long time and havent seen anything related to this. Thanks

@ebr Might you point to where we can follow the Beta at?