I know the transcoder is based on ffmpeg - does this vuln affect plex at all?
I’ve posted the same general question in the Plex Pass general forum section.
Guess I should have asked in public.
Still no answer to mine.
If Plex’s transcoder has the vulnerability, which, actually, wasn’t a zero-day according to some research on Google (search “ffmpeg zero day” - reddit discussion among others show bug’s been around awhile, perhaps it just got used in the wild)
I generally stated/have a theory that those of us using Plex to watch content we didn’t control from “source” to our eyes are likely to be more affected.
We’re watching our own converted media from disc, we’re in what I’d call the green zone.
We’re watching “corporate” “trusted” site plugins (CBS, ABC, Apple, etc) are medium safe yellow zone.
We’re watching content obtained from others, or plug-ins such as SSplex/LMWT/BitTorrent/CouchPotato/SIckbeard, well, that’s the red zone.
At this point it’s conjecture on my part. We still don’t know for sure Plex uses the HLS/AppleHTTP mentioned.
My guess is yes though.
Update from my Plexpass forum post.
@jmckee said:
This is a valid concern and the developers are aware of it and will have a fix to mitigate this issue in the next release.AFAIK, this will only affect the server running the file itself through the transcoder. IE you playing the infected video from a shared server will not affect you, but it can affect the server that was serving the file. The main advice as always is to only run files from a trusted source through the transcoder.
I failed to realize that me playing transcoded ‘bad’ content from a shared server would only affect the host.
However, that still leaves red zone content in which plugin streams may be transcoded from questionably sources.
@JamminR said:
Update from my Plexpass forum post.
Thanks for linking these, it was 4am when I posted in the other topic and I could not for the life of my find this thread!
I’ve not seen any further conversation on the ffmpeg vulnerability and a fix within Plex. Does anyone know if the fix is included in 0.9.15.2 released on 1/22/16? I don’t see it in the list of fixes in the changelog.
https://plex.tv/downloads/1/archive
Thanks.
Sadly, as it usually seems with the inner Plex core, no answer yet.
I unfortunately don’t frequent these forums; do Plex reps ever comment on these types of questions? I’d love to know that Plex has protected me against this ffmpeg vulnerability.
@jmckee - it sounds like you maybe had some direct feedback that Plex developers were working on releasing a fix. Do we know if that’s already been included 0.9.15.2 or is upcoming?
Thanks all.
@TA@Plex said:
I unfortunately don’t frequent these forums; do Plex reps ever comment on these types of questions? I’d love to know that Plex has protected me against this ffmpeg vulnerability.@jmckee - it sounds like you maybe had some direct feedback that Plex developers were working on releasing a fix. Do we know if that’s already been included 0.9.15.2 or is upcoming?
Thanks all.
Everyone I have talked to says that the fix was already implemented and released.
I unfortunately don’t have a way to test it out myself to confirm it, but that is what I was told.
Awesome, thank you for the reply. I’ll keep an eye on this thread and change logs in case we see something more official.
Thanks again.
@TA@Plex said:
Awesome, thank you for the reply. I’ll keep an eye on this thread and change logs in case we see something more official.
Sorry, bad news. There was something lost in the communication. The fix has been committed but is currently undergoing internal testing before release.
(I guess it’s good I didn’t try it out)
https://forums.plex.tv/discussion/comment/1130063/#Comment_1130063
I get “permission problem” with that link, but thanks all the same. I’ll keep watching for a released fix. Hope it comes soon.
@TA@Plex said:
I get “permission problem” with that link, but thanks all the same. I’ll keep watching for a released fix. Hope it comes soon.
Sorry about that (I sometimes forget to check which boards I’m posting/linking to) The post was this:
@atrus said:
I think there is a misunderstanding here. The developers have made the changes internally yes (according to @rcombs ), but it has not yet been released. There is internal testing going on with that release still. Releasing a build which is not up to snuff will break more hearts than it mends.
When I spoke the developers they said it had been released, when atrus double checked they clarified that it had been committed and was released into testing but not to the general public yet. I just wanted to make sure I passed on the correct information and since I was wrong, had to get the correct stuff out to this thread as well.
Any word on public availability of a version of Plex that includes a fix for this vulnerability? I’m growing more concerned that the folks behind Plex aren’t protecting their users in a more timely fashion. This vulnerability has been public since January.
Appreciate any updates. Thanks.
This is long-overdue for an official statement from Plex. I can understand a few hours, maybe a couple days. Not months for a security vulnerability.
According to the DEV Team the issue was resolved and committed into the 0.9.15.x and 0.9.16.x releases
That’s a pretty important fix - it should be listed in the release notes. I didn’t find any mention of it though.
If you search the release notes you will notice that they have never commented on previous fixes to ffmpeg vulnerabilities either
There have been quite a few ffmpeg issues over time: https://ffmpeg.org/security.html
Perhaps that’s something that should be added. If a program that Plex relies upon is vulnerable, and they incorporate a new version to plug a security hole, the users are interested in knowing that it’s fixed.
Actually I wish they would tell us which versions of open source (eg ffmpeg) their software is based off of.
This way we could also cross reference things like this much easier.
Carlo
@hthighway said:
If you search the release notes you will notice that they have never commented on previous fixes to ffmpeg vulnerabilities either
Doesn’t matter. This one got a lot of press, justifying its own separate public statement. Besides, just because they’ve always done something a certain way doesn’t mean it was right.
