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

41–50 of 234 posts

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

#41

Post by viraptor »

dom0 wrote: post #34
viraptor wrote: post #31

Earlier quoted context omitted.

Not even multi-process. Threads on Linux can have their own seccomp profiles. You don't need to sandbox absolutely everything at the same time either. In this case opening the file in the main, unrestricted app and spawning a new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy. Other points may be more tricky, and it's a good list of p…

> Not even multi-process. Threads on Linux can have their own seccomp profiles. Feels kinda pointless, since all threads in a process share the same memory protection.

They don't have to. Clone can do a lot of magic without full processes.

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

#42

Post by jbk »

viraptor wrote: post #31
jbk wrote: post #22

Earlier quoted context omitted.

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

Not even multi-process. Threads on Linux can have their own seccomp profiles. You don't need to sandbox absolutely everything at the same time either. In this case opening the file in the main, unrestricted app and spawning a new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy. Other points may be more tricky, and it's a good list of p…

> Threads on Linux can have their own seccomp profiles.

Not on Windwows or on macOS.

> new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy.

Of course that does not solve anything, because your demuxer|decoders|output needs access to the FS, have access to kernel-mode and those are the dangerous parts.

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

#44

Post by etix »

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…

Moving 4K / 10-bit buffers at 30 or 60 fps (because 3D) between processes is not as easy as it sounds.

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

#45

Post by DenisM »

viraptor wrote: post #24
pjmlp wrote: post #19

Earlier quoted context omitted.

Looking at the bug fixes done in VLC, Ada or Modula-2 would be enough, although there are plenty of options actually. Rust isn't the only alternative to write native code safer than C will ever allow.

Don't know about Modula, but have you tried Ada? The usability of it is nowhere near modern languages IMO. We learned a lot about nice code since then :-)

Modula 2 is much like C in it's close-to-the-metal performance abilities.

On the downside, if you want to call it that, is a more prominent syntax (keywords instead of curlies, upper-case keywords, etc).

On the upside it lacks any unsafe operations, except for dealloc. In addition, it has actual modules in lieu of includes, hence it's blazingly fast to compile and/or recompile. It'a a pity it didn't catch on, the language lacked a company to back and promote it. AT&T promoted C, Apple promoted Objective C, Microsoft promoted VB...

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

#46

Post by kutkloon7 »

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.

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.

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

#47

Post by viraptor »

jbk wrote: post #42
viraptor wrote: post #31

Earlier quoted context omitted.

Not even multi-process. Threads on Linux can have their own seccomp profiles. You don't need to sandbox absolutely everything at the same time either. In this case opening the file in the main, unrestricted app and spawning a new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy. Other points may be more tricky, and it's a good list of p…

> Threads on Linux can have their own seccomp profiles. Not on Windwows or on macOS. > new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy. Of course that does not solve anything, because your demuxer|decoders|output needs access to the FS, have access to kernel-mode and those are the dangerous parts.

I'm not sure what you're trying to say. Yes, I meant Linux. Yes, it can solve the issue of separate subtitle files, which this article is about. Read access to an existing FD is not the same as full FS access, and there's no demux involved here.

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

#48

Post by DenisM »

aclsid wrote: post #39
thresh wrote: post #14

Clearly VLC should be rewritten in Rust.

Yes, they clearly have the resources to do that. Maybe you can propose a prototype in Rust?

Sarcasm can feel good, but it poisons the well of civilized discussion. Kindly refrain.

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

#50

Post by jbk »

viraptor wrote: post #47
jbk wrote: post #42

Earlier quoted context omitted.

> Threads on Linux can have their own seccomp profiles. Not on Windwows or on macOS. > new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy. Of course that does not solve anything, because your demuxer|decoders|output needs access to the FS, have access to kernel-mode and those are the dangerous parts.

I'm not sure what you're trying to say. Yes, I meant Linux. Yes, it can solve the issue of separate subtitle files, which this article is about. Read access to an existing FD is not the same as full FS access, and there's no demux involved here.

> Yes, I meant Linux

The demo is on Windows. The goal is to do a sandbox that works on most OSes.

And, it will not solve the decoder issue, since it is on the decoding side, which still has access to the GPU/Aout and the kernel.

> Read access to an existing FD is not the same as full FS access, and there's no demux involved here.

You're totally missing the point here. The issue is demuxers/decoders/output, not really the access.

Reading from an FD or not would not solve the buffer overflow exploitation (if it was actually exploitable).

Post reply on HN