5 ms·

Was annoying to find the details. Looks like PopcornTime was rendering subtitle text as HTML, inside their app (html/js-based), creating an XSS vector (looking

Was annoying to find the details. Looks like PopcornTime was rendering subtitle text as HTML, inside their app (html/js-based), creating an XSS vector (looking at https://github.com/popcorn-official/popcorn-desktop/commit/a9aa8e16610ee8cb23ba4a6452c5a69bf88d9107 https://github.com/popcorn-official/popcorn-desktop/commit/a..., https://github.com/butterproject/butter-desktop/pull/602 https://github.com/butterproject/butter-desktop/pull/602). Likely the javascript runtime they're using allows file access and execution of arbitrary executables, enabling the metasploit shell shown in the demo. For VLC there are a bunch of out of bound reads and heap buffer overflows. 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. 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. The Kodi issue was a zip archive path traversal (i.e. no protection against zip files extracting files to parent directories).

jbk 9y ago
> 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. Yes, those are very different issues. From what I understood, one is an XSS (popcorn-time), one is a heap-based buffer overflow (VLC), and one is a zip-transveral (Kodi). And tbh, I don't see how you can exploit the bug for VLC (with ASLR and HEASLR).
- pjmlp 9y ago
  Easy, you cannot count with an executable being always compiled and executed in an OS with ASLR and HEASLR enabled. So it becomes a game of luck getting some users exploited.
driverdan 9y ago
Thank you! I was frustrated when I saw this last night and it didn't contain any details. I assumed buffer overflow but different attacks for each is more interesting.
leni536 9y ago
Yeah, the article was a bit poor on details. I expected some libass or other common library/codec vulnerability.
the8472 9y ago
Are those things vlc-specific or is there a common vulnerability shared with the underlying libs (libavcodec, libass?)
AdmiralAsshat 9y ago
Thanks for that. I read the article and was really confused at first. I don't do a whole lot of video editing, but I've opened up a .srt file a handful of times and noticed that it was nothing more than timestamps and text. The fact that the article made it seem like this was some kind of universal vulnerability made me wonder, "A simple subtitle file should be opened in read-only mode. Are these programs just reading whatever is in the .srt file and EXECUTING it!?!" That would be beyond horrible. The fact that it's multiple, independent vulnerabilities makes me feel a little better. I've used Kodi and OpenSubtitles before while watching a movie to search and download subs for the movie without ever leaving Kodi. When it works, it's nothing short of magical.
easuter 9y ago
If only VLC had been re-written in rust this would never have happened. For shame.
- remotehack 9y ago
  Java would work much better for VLC.
  - easuter 9y ago
    No. Java doesn't have fearless concurrency, zero-cost abstractions or move semantics.
    - thaumasiotes 9y ago
      "Fearless concurrency" and "zero-cost abstractions" sound a lot like meaningless marketing terms.
      - easuter 9y ago
        Only to someone who hasn't experienced the earth-shattering enlightenment rust provides.
      - rdiddly 9y ago
        Dunno about "fearless concurrency," but "zero-cost abstractions" and "move semantics" are straight off the front page of rust-lang.org. So they're kind of marketing-ish in trying to make you go "hmm sounds intriguing" and click to find out more.
      - jarman 9y ago
        "fearless concurrency" is meaningless marketing, "zero-cost abstractions" is valid term
- lawl 9y ago
  Oh look, it's the Rust Evangelism Strike Force at work again.

jbk 9y ago

> 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. Yes, those are very different issues. From what I understood, one is an XSS (popcorn-time), one is a heap-based buffer overflow (VLC), and one is a zip-transveral (Kodi). And tbh, I don't see how you can exploit the bug for VLC (with ASLR and HEASLR).

pjmlp 9y ago
Easy, you cannot count with an executable being always compiled and executed in an OS with ASLR and HEASLR enabled. So it becomes a game of luck getting some users exploited.

driverdan 9y ago

Thank you! I was frustrated when I saw this last night and it didn't contain any details. I assumed buffer overflow but different attacks for each is more interesting.

leni536 9y ago

Yeah, the article was a bit poor on details. I expected some libass or other common library/codec vulnerability.

the8472 9y ago

Are those things vlc-specific or is there a common vulnerability shared with the underlying libs (libavcodec, libass?)

AdmiralAsshat 9y ago

Thanks for that. I read the article and was really confused at first. I don't do a whole lot of video editing, but I've opened up a .srt file a handful of times and noticed that it was nothing more than timestamps and text. The fact that the article made it seem like this was some kind of universal vulnerability made me wonder, "A simple subtitle file should be opened in read-only mode. Are these programs just reading whatever is in the .srt file and EXECUTING it!?!" That would be beyond horrible. The fact that it's multiple, independent vulnerabilities makes me feel a little better. I've used Kodi and OpenSubtitles before while watching a movie to search and download subs for the movie without ever leaving Kodi. When it works, it's nothing short of magical.

easuter 9y ago

If only VLC had been re-written in rust this would never have happened. For shame.

remotehack 9y ago
Java would work much better for VLC.
- easuter 9y ago
  No. Java doesn't have fearless concurrency, zero-cost abstractions or move semantics.
  - thaumasiotes 9y ago
    "Fearless concurrency" and "zero-cost abstractions" sound a lot like meaningless marketing terms.
    - easuter 9y ago
      Only to someone who hasn't experienced the earth-shattering enlightenment rust provides.
    - rdiddly 9y ago
      Dunno about "fearless concurrency," but "zero-cost abstractions" and "move semantics" are straight off the front page of rust-lang.org. So they're kind of marketing-ish in trying to make you go "hmm sounds intriguing" and click to find out more.
    - jarman 9y ago
      "fearless concurrency" is meaningless marketing, "zero-cost abstractions" is valid term
lawl 9y ago
Oh look, it's the Rust Evangelism Strike Force at work again.