Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

blog.checkpoint.com

Post reply on HN
Print view View original

121–130 of 234 posts

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#121

Post by unwind »

pawadu wrote: post #15
_jomo wrote: post #9

These are the VLC commits adressing the issue: https://github.com/videolan/vlc/search?utf8=%E2%9C%93&q=subt...

Holy crap, that code doesn't look good. I predict we will see more exploits for this project. Maybe we should stop random people from contributing to complex C projects?

Wouldn't go that far from reading a single commit, but to anyone looking to pick up tips from a well-known respected C codebase: don't ever write

    (*(psz_text + 1 ) ) == '~'
when you can instead write

    psz_text[1] == '~'
Fewer tokens means less overhead for the human reader, and that asterisk-and-add pattern is exactly what the bracket array indexing operator does, so why not use it? This is one of my many C pet peeves, heh.

Also on a more personal note, if you're going to be putting things inside parentheses with whitespace, make it symmetrical.

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#122

Post by phkahler »

jbk wrote: post #22
captainmuon wrote: post #8

Wow, that is bad. I'm always amazed by such vectors in supposedly passive formats, like fonts, images, and so on. 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 subt…

Ha, the famous sandboxing remark. I wish it was that simple! So, let me share some light on the sandboxing for multimedia (I work on VLC). If you sandbox an application like VLC, in the current way of doing sandboxing, which we've done for macOS, WinRT/UWP, and snaps, you still need a lot of permissions. Namely: - you need to be able to open files without user interactions (no file picker), in order to open playlist,…

Thanks for that. This type of thing comes up all the time. I used to wonder how web sites could be so dangerous, but it becomes clear when you think about all the extra access developers wanted for good reasons - imagine a web browser that didn't have access to the file system, and so on. I still don't like this state of affairs, but I don't have an alternative solution. Wayland should be more secure than X, but they're starting to poke holes in there for various reasons (color picker, warp pointer for compat, etc...).

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#123

Post by leni536 »

ConfucianNardin wrote: post #23

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 shel…

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

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#124

Post by the8472 »

ConfucianNardin wrote: post #23

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 shel…

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

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#125

Post by pjmlp »

jbk wrote: post #30
ConfucianNardin wrote: post #23

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 shel…

> 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 (wi…

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.

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#126

Post by OneLessThing »

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.

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.

Use VLC it's the most secure media player I've seen.

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#128

Post by rossy »

jbk wrote: post #85
johncolanduoni wrote: post #58

Earlier quoted context omitted.

> Probably do a multi-process media player, like Chrome is doing, with parsers and demuxers in a different process, and different ones for decoders and renderers. Knowing that you probably need to IPC several Gb/s between them. That's not actually how Chrome's renderer sandboxing works. Both Windows and OS X allow you to share a GPU-resident texture between processes (DXGI shared surfaces and IOSurface respectively),…

But you need to pass data from the access to the stream_filter, from the stream_filter to the demuxer, from the demuxer to several decoders, from the decoders to potentially a few video-filters and chroma-converters, and then finally to the output. Each of them need different access policies, and several of them require FS access. The last part is just one of the issues, very far from all of them. Seriously, stop thi…

These shouldn't require IPC at GB/s speed either. Modern sandboxes, like the one in Chrome, have a broker process which can open filesystem objects, device objects and sockets (file descriptors or handles) and pass them to a sandboxed decoder/renderer process, so there would be no need to stream filesystem data to the sandbox when the sandbox could do the file I/O itself. Even for Matroska ordered chapters, where the demuxer would have to tell the broker which files to open, the broker could enforce certain rules, such as enforcing that local mkv files only reference other local files, the files are all in the same directory, and that the files are always opened in read-only mode.

As for isolating decoders from video filters and chroma conversion, I'm not sure why that would be necessary, since those shouldn't require any additional privileges. I understand that retrofitting an existing program to use a multi-process sandboxing model is far from easy, and I'm definitely not volunteering to do it, but I don't think there is anything specific about a video player that is harder to sandbox than a web browser.

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#129

Post by leni536 »

simias wrote: post #115
captainmuon wrote: post #8

Wow, that is bad. I'm always amazed by such vectors in supposedly passive formats, like fonts, images, and so on. 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 subt…

I don't understand why sandboxing the userland is not a thing on the linux desktop at least. When you sanely configure a un*x server you generally at least create a user per application. The web server runs as www, the database with its own user, the ssh process runs as the logged-in user (the daemon runs as root obviously, but only for just as long as it needs before forking a less priviledged child) etc... But when…

Well, there is firejail now. It does Xorg sandboxing through xpra, I don't know how it affects hardware acceleration though.
Post reply on HN