Was annoying to find the details.<p>Looks like PopcornTime was rendering subtitle text as HTML, inside their app (html/js-based), creating an XSS vector (looking at <a href="https://github.com/popcorn-official/popcorn-desktop/commit/a9aa8e16610ee8cb23ba4a6452c5a69bf88d9107" rel="nofollow">https://github.com/popcorn-official/popcorn-desktop/commit/a...</a>, <a href="https://github.com/butterproject/butter-desktop/pull/602" rel="nofollow">https://github.com/butterproject/butter-desktop/pull/602</a>). Likely the javascript runtime they're using allows file access and execution of arbitrary executables, enabling the metasploit shell shown in the demo.<p>For VLC there are a bunch of out of bound reads and heap buffer overflows.<p><pre><code> f2b1f9e subtitle: Fix potential heap buffer overflow
611398f subtitle: Fix potential heap buffer overflow
ecd3173 subsdec: Fix potential out of bound read
62be394 subsdec: Fix potential out of bound read
775de71 subtitle: Fix invalid double increment.
</code></pre>
The article implies that VLC and the others are affected by the same issue (leading to code execution), but according to available information it seems to be completely different issues.<p>The Kodi issue was a zip archive path traversal (i.e. no protection against zip files extracting files to parent directories).
I did security research on VLC on Windows a year or two ago. I may be remembering incorrectly, but last I recall every module was protected by ASLR. Which means that remote code execution is not likely because there is no scripting or network comms to dynamically create a valid ROP chain.<p>I also didn't check for executable heaps at the time but given that all heaps are non executable (which they really shouldn't be executable in VLC) again I don't see how RCE is possible. Maybe there is some way to validate and therefore brute force addresses? I don't know. But there was no VLC POC and I'm sure they would have made one if they could have.<p>Use VLC it's the most secure media player I've seen.
Kodi 17.2 with the fix for this flaw has now been released:<p><a href="https://kodi.tv/article/kodi-v172-minor-bug-fix-and-security-release" rel="nofollow">https://kodi.tv/article/kodi-v172-minor-bug-fix-and-security...</a>
The thing that most amazes my about Popcorn Time is how they find the subtitles. It seems to succeed even when I can't find subtitles myself.<p>More related to the article, you would think that subtitles are literally the easiest file format in existence to safely handle. It's incredibly well-defined in terms of textual data and times.
These are the VLC commits adressing the issue:<p><a href="https://github.com/videolan/vlc/search?utf8=%E2%9C%93&q=subtitle+OR+subsdec+%22checkpoint.com%22&type=Commits" rel="nofollow">https://github.com/videolan/vlc/search?utf8=%E2%9C%93&q=subt...</a>
Interestingly running VLC 2.2.4 on MacOS 10.12 and checking for updates returns 'VLC 2.2.4 is currently the newest version available.', obviously I downloaded 2.2.5.1 from videolan.org but still odd.
Can anyone recommend a video player written in a memory-safe language for OSX that handles MKV files? Or is the simple truth that the problem lies in the parsers, which are shipped as a library written in C, because no sane developer wants to rewrite parsers for 25 different subtitle formats when writing a video player?
It would be interesting to see which subtitles are using these vulnerabilities and what they are achieving with them. We could estimate how long this has been around.
This is another reason you should use a tool like a parser generator when you have to parse untrusted data, rather than writing your own parser by hand.
This is interesting to me for reasons outside of anything to do with exploits or malware. A while back I had a bit of a brain fart while playing with my Hue bulbs: would there be a way to use the subtitle track for a video to encode time-controlled data that can be sent to/read by another application that sends these values to a set of Hue bulbs or similar devices for synchronized ambient lighting?<p>I figured that subtitles were an obvious place to start because you can download them in small files, play them back alongside a video, and they are designed to be "timed out" to synchronize with a video already.<p>I looked into it for a bit but never really found a way (within my abilities at least) to do anything like this from within a .srt file or similar. I'd be interested in hearing if anyone else has more info on how you might do more with that "framework" than displaying text on screen.
Speaking of Popcorn Time, last I heard there were a couple of forks and doubts about the safety of each and every one.<p>Is there any more clarity around the situation now?
Wow, that is bad. I'm always amazed by such vectors in supposedly passive formats, like fonts, images, and so on.<p>There is no excuse that these kind of applications are not completely sandboxed. All you need is some kind of DLL, raw data in, raw pixels out. In case of hardware accelerated codecs, raw pixels in, surface pointer in, nothing out. There is no need to be able to access the filesystem, etc.. To render subtitles on top of the video it's the same.<p>I wish a fraction of the energy we put into DRM would go into sandboxing instead.
If Popcorn Time renders all subtitles as HTML, would an exploit work if the subtitles were embedded in video container? Seed latest hit on Pirate Bay, root a lot of boxes. Yikes.
here is how it looks in real time:<p><a href="https://www.youtube.com/watch?v=vYT_EGty_6A" rel="nofollow">https://www.youtube.com/watch?v=vYT_EGty_6A</a>
This is the sourced post <a href="http://blog.checkpoint.com/2017/05/23/hacked-in-translation/" rel="nofollow">http://blog.checkpoint.com/2017/05/23/hacked-in-translation/</a><p>The ingenuity that goes into RCE exploits never ceases to amaze (and terrify) me. Can't wait for more details to be released.
Treat data as data. Taking the Subrip format as an example, everything starts out fine so long as there is good bounds checking on the purely textual data.<p>Then, however, some dipshit decides to extend the format by adding tags for things like bold, italics, underline etc. This is completely unnecessary for subtitles because the emphasis can be inferred from the dialogue. The unnecessary complexity increase the potential for vulnerabilities.<p>Then some total dickhead decides to add an HTML5 tag, for no reason whatsoever, and it all goes to hell.<p>This is illustrative of the problem with most software: the absence of a clear-headed benevolent dictator to say, "no; you are an idiot; we're not doing that."
> The attack vector relies heavily on the poor state of security in the way various media players process subtitle files and the large number of subtitle formats.<p>Well, last years exploits against iOS, Android and Ubuntu where all related to media metadata processing. It is only natural that the same folks screw up this one too.