Check Point posted to their blog about maliciously crafted subtitles being used to exploit players vulnerable to (I’m assuming) buffer overflows. While Plex isn’t specifically listed, Kodi, VLC, Popcorn Time, and strem.io are. Can we get an official comment on this? They haven’t posted technical details yet due to responsible disclosure guidelines, but it would be nice to know if we are affected as well.
http://blog.checkpoint.com/2017/05/23/hacked-in-translation/ for further reading.
I forwarded this on to get more information. At this time, Plex is aware of the issue and is working to evaluate the it’s impact on the Plex ecosystem.
Came here to post this exact thread. Glad there are already security focused users asking the right questions. I’m going to see if there is any discussion over at https://forum.opensubtitles.org/ about this since that is the primary source for Plex subs right?
Source: https://support.plex.tv/hc/en-us/articles/200471113-Configuring-Subtitle-Support
There is a single thread open on their forums:
@trexid said:
Came here to post this exact thread. Glad there are already security focused users asking the right questions. I’m going to see if there is any discussion over at https://forum.opensubtitles.org/ about this since that is the primary source for Plex subs right?Source: https://support.plex.tv/hc/en-us/articles/200471113-Configuring-Subtitle-Support
There is a single thread open on their forums:
I want to take the dev’s word for it, but there are very few details. Was it the special characters in the filename causing the exploit itself in the client media players? Or was that just how they manipulated their subtitles files to be at the top of the search results? I wish we had more details about the actual exploit (where they showed MSF being used).
Sine Plex is a spinoff of Kodi I expect it to be vulnerable in the same way.
@Nebula said:
Sine Plex is a spinoff of Kodi I expect it to be vulnerable in the same way.
Outdated information. There is nothing from Kodi in Plex.
The last thing was ‘Plex HomeTheater’, which was Kodi-based.
@maik
I wish we had more details about the actual exploit (where they showed MSF being used).
This vulnerability was disclosed ‘responsibly’. Which means no details are shared about it for a certain amount of time, to give the developers some time to fix things.
Therefore, details about it are not available, yet.
Came to ask this, following!
@maik said:
I want to take the dev’s word for it, but there are very few details. Was it the special characters in the filename causing the exploit itself in the client media players? Or was that just how they manipulated their subtitles files to be at the top of the search results? I wish we had more details about the actual exploit (where they showed MSF being used).
If you want to know about the exploit easiest way is look at the fixes that have been published to github for other projects it gives an idea.
strings = Common.sanitize(strings); // xss-style attacks
strings = strings.replace(/--\>\;/g, '-->'); // restore srt format
Looks like from inside the SRT using strings you could create a xss attack.
@OttoKerner said:
@Nebula said:
Sine Plex is a spinoff of Kodi I expect it to be vulnerable in the same way.Outdated information. There is nothing from Kodi in Plex.
The last thing was ‘Plex HomeTheater’, which was Kodi-based.
Good to know, thanks!
im also curious to see if Plex is affected by this.
Hello,
I came here for the same purpose.
I found this thread in the Kodi github. If this can help 
(I’m not a programmation expert)
I hope the Linux based servers are safe, since the ‘plex’ user is severely limited, but I really don’t wanna see my server shredded one day…
Understand details about vuln are not yet public, but what’s the word from Plex headquarter? Is Plex affected by this or not?
Some updates from OpenSubtitles.org in the thread.
He said they’ve corrected requirements for subtitle names. Basically removing special characters.
OSS - Site Admin (OpenSubtitles.org)
for now, I can say, everything is safe. I checked the test described and can confirm the only penetrator from the security company made some tests on this vulnerability.
Also it is fixed now, so it can not happen in future.
The problem was with the filenames of subtitles and how they handle it in media players.
Now, all special characters in filenames are removed.
Link: insecure subtitles - OpenSubtitles forum
So, it sounds like he’s remediated as much as he can for OpenSubtitles by restricting special characters from file names. I’m still interested in getting a definite answer from the Plex team in any case.
I was about to disable all subtitle support from my Plex Server for the time being until I saw that reply from the site admin. It puts me a little at ease to continue using subs from OSS.
This doesn’t, however, specify the scenario of Plex folks importing their own subs from whatever sites may still be affected by this exploit and potentially open a security hole show in the video from CheckPoint.
I hope there is some official feedback soon.
The real issue with the details of the vuln being undisclosed is that guys that were using it already, will now intensify the efforts of growing their bot nets using it - they know that patches are rolling out.
For us though, I’m not sure whether it’s only the server end of the service that’s being affected. If someone is I.e using the plex desktop app for windows 10, and is streaming a movie with direct playback and subtitles not burned in, aren’t those processed on client side as well?
This issue is disconcerting, and Plex’ lack of at least general acknowledgement is not helping… only us who are the forum members have the current info on this with regards to the platform.
we are checking things. there are lots of things to check
In light of the comments posted above from OpenSubtitles.org, is there an easy way to ‘purge’ all of the subtitles in your library, to ensure that you haven’t already downloaded infected files? I’m using Sub-Zero, and it automatically populates the subtitles when the libraries are updated.
edit: It’s OK, answered it myself. I’m able to list all the .srt files on the system (linux) with their full paths, (find / -name “*.srt” > filename) and should just be able to rm them all using a file listing them all.
You could just go with find /your library location/ -type f -name ‘*.srt’ -exec rm {} +
I’m also hoping someone will put together a parser for subtitile files - looking for malicious code in them.
@BigWheel said:
we are checking things. there are lots of things to check
How about a simple:
“Yes, we use the exploitable libraries, chances are high that you’re all exposed. We’re still gather details on how to fix it.”
OR:
“No, we don’t use the exploitable libraries, you’re probably not exposed.”
My guess is that it’s the former.
