Comment by ConfucianNardin | Hacker News Reader

Comment by ConfucianNardin | Hacker News Reader

ConfucianNardin

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/a..., 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).

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.

> 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).

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.

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.

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

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

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

Java would work much better for VLC.

No. Java doesn't have fearless concurrency, zero-cost abstractions or move semantics.

"Fearless concurrency" and "zero-cost abstractions" sound a lot like meaningless marketing terms.

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.

"fearless concurrency" is meaningless marketing, "zero-cost abstractions" is valid term

Oh look, it's the Rust Evangelism Strike Force at work again.

Please don't react to provocation by making the thread worse (a.k.a. please don't feed the trolls).

How are you so sure it's trolling? Someone from the Rust Team has defended such behavior as good marketing [0].

[0] https://lobste.rs/s/wq6eov/changes_i_would_make_go#c_ofxtj1

One is never 100% sure, but note that the first part ("Please don't react to provocation by making the thread worse") holds regardless.

Feel free to rewrite VLC in Rust. No one is stopping you.

Pretty sure that was sarcasm.

Yes but it would also not have nearly as many features as it does right now.

We ban accounts for trolling, so please don't do that here.

Also, you've posted many uncivil and/or unsubstantive comments. We ban accounts for that too, so please don't do that either.

Reply on news.ycombinator.com