21–30 of 234 posts
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?
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…
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, MXF or MKV files;
- you need the same if ever you have a database of files (media center oriented);
- you need raw access to /dev/* to play DVD, CD and other optical disk (and the equivalent on Windows);
- you need ioctl on such devices, to pass the MMC for DVD/Bluray;
- you need raw access to /dev/v4l* for your webcams and be able to control them;
- you need access to the GPU stack, which is running in kernel-mode, btw, to output video and get hw acceleration;
- you need access to the audio stack, also in low-level mode;
- you need access to the DSP acceleration (not always the GPU);
- on linux, you have access to x11 for the 3 above features, which is almost root;
- you need access to /etc/ (registry) for proxy informations, fonts configuration and accessibility;
- many OpenGL client libraries need access to the /etc too;
- you need access to the network, as input and output (think remote control);
- you need access to the system settings to disable screensavers, and adjust brightness;
- you need access to mounts to be able to see the insertion of DVD/Bluray/USB/SD cards and such;
- you need to expose an IPC (think MPRIS on Linux);
- you need to unzip, untar, decrypt, decipher and so on;
- you need access to the fonts and the fonts configuration (see fontconfig).
and I probably forgot one or another case.
The point is, all those features have good reasons to exist and very good use cases; but the issue is that for a media player, it will request almost all permissions except GPS and address book.
And quite a few of them are very close to kernel mode.
So, what is the solution?
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.
I've been working on such a prototype, but it's a lot of work... I accept donations :)
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 Kodi issue was a zip archive path traversal (i.e. no protection against zip files extracting files to parent directories).
Clearly VLC should be rewritten in Rust.
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.
Does this also work for Android versions of Kodi et al?
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…
Clearly VLC should be rewritten in Rust.
Earlier quoted context omitted.
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?
"random people"? You mean there's some select group we know of that doesn't ever write bugs? (DJB doesn't make a group)
The problem is that boring stuff can also be very security sensitive.
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…
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).