Live data from Hacker News

Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

blog.checkpoint.com

111–120 of 234 posts

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

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

What features could the OS offer you (to help your program be "sandboxed") that it currently does not?

I think we can do everything now for the majors OSes, but I'd guess this is a 50-100 man-month work for VLC.

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

#113
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 :-)

I mean, Ada was spec'd to run flight computers for military aircraft and similar mission-critical stuff. If you want something that is secure, Ada can do it. It just won't offer many creature comforts in doing so...

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

#115

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 it comes to the desktop everything runs at $user and that's the end of it. While this makes sense for multi user "mainframe"-style systems, for modern desktops it's an anti-pattern almost. I wish I could run my browser as its own user, my password manager as an other, my code editor/toolchain in an other, the closed source spotify client in a third etc...

It's kind of doable today but it's not exactly friendly to setup. In particular Xorg is not exactly designed with client isolation in mind as far as I can tell, preventing one window from overtaking an other without being too cumbersome is left as as exercise to the reader.

But really, at the OS level I feel like we already have all the functionality we need and we just completely ignore it. On a desktop the critical account isn't really root per se, rather it's the user account that contains all of my data.

Maybe we've just been doing it wrong the entire time and we should just log into our single-user desktop computers as root and then spawn our shells and other applications as various unpriviledged users as necessary (this could easily be scripted in launcher scripts). I wonder if anybody has attempted to do that, but again I don't expect that Xorg would work very well in this configuration.

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

#116
post #97

Earlier quoted context omitted.

I don't think nobody has thought about it, but since you were apparently unaware that there was an alternative to performing several GB/s of IPC for moving buffers around there's obviously some options that haven't been considered. The Chromium sandbox has to deal with every issue you've listed (it's even calibrated to run ffmpeg inside the sandbox, since that's something Chromium needs to do).

> but since you were apparently unaware that there was an alternative I will refrain from answering to such attacks. As you seem to know better, I'm waiting for your patches.

It's not an attack. Each platform's methods of GPU IPC are pretty sparsely documented. Two months ago I wouldn't have known about them; I only learned by working on integrating Chromium's sandbox into an application that needed to work with the GPU within a sandboxed process.

That doesn't change the fact that none of the things you listed are unsupported by Chrome's sandbox model, and if you only need to establish a barrier around the video pipeline (and not e.g. VLC's ability to notice device status or interact with webcams) you don't even need 3/4 of what Chromium's sandbox has implemented. Like I said, I've actually walked the walk when it comes to using their sandbox for Windows and Linux with a process that needed to access certain user files, the GPU, and even each platform's font server equivalent, so this isn't me just spitballing about some theoretical solution.

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

#117
post #76

Earlier quoted context omitted.

The problem isn't only about matching subtitles to movies but also where to look for subtitles, e.g. opensubtitles.org, subscene.com, etc.

I believe it just scrapes them all. I can't remember the last time opensubtitles didn't have a sub I was looking for

Perhaps the most difficult problem is to find a subtitle in multiple languages.

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

#118
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 :-)

Some of us like readable languages not composed of hieroglyphs.

Ada was and still is a quite modern language, designed for software development done by large teams, where I can several years later still understand what I wrote.

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

#119
post #45

Earlier quoted context omitted.

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

> Apple promoted Objective C

Actually Apple promoted Object Pascal, but then they decided to cater to the growing UNIX market and replaced the Mac OS SDK with C and C++ (PowerPlant) one.

https://en.wikipedia.org/wiki/MacApp

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

#120
post #107
post #17

Earlier quoted context omitted.

As usual, the common set of friends we already know since the 80's: > Fix potential heap buffer overflow > Fix potential out of bound read > Fix invalid double increment.

i've never seen a double increment exploited before- it's undefined behavior, but what is the typical route against that?

Use a memory safe language that doesn't require direct pointer manipulation to access string and memory buffers, with an optimizer able to elide bounds checking if proven safe to do so.
Post reply on HN