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).
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.
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.
ROP: return oriented programming
ASLR: Address space layer randomization
Having ASLR is not bullet proof to remote code execution, e.g. iOS has ASLR for a long time and can still be jailbroken (which usually involves a code injection etc). The key is info leak, e.g. if you somehow can reliably find the memory location of open() syscall, the memory location of the whole libc can be inferred, and libc is usually large enough to construct a ROP chain. (I haven't work in security area for a long time so correct me if I'm wrong).
The researcher unable to provide a POC for vlc could simply mean it's hard due to ASLR, but it's not impossible.
Also: I believe ASLR is a compiler option (with a supported OS), it should be relatively easy for Kodi and Popcorn Time to start using ASLR.
Address space randomization is not "protection". It's a form of security by obscurity. The odds of an exploit working are reduced, at the expense of more crashes due to exploit failure.
It helps developers ignore bugs, since they can no longer reproduce them.
Off topic: I love VLC but can't get it to use hardware acceleration on my late 2015 mac. 4k 60fps @ 40mbps consume all CPU if I try to play a lower compression 150mbps video it studders and all my fans turn on. mpv and quicktime play the same videos with 15-20% CPU. The poor performance of VLC on my macOS makes it a no go for me.
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.
> literally the easiest file format in existence to safely handle.
Well, which one of them. There's nearly a hundred different subtitle formats, and each one has a whole set of variants. Just Timed Text alone (XML) can have more layouts than one could count, specially since it's meant to be able to replicate technically all previous industry formats.
> 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.
Depends on the format. SSA for instance can have embedded font and image files, which presumably have much more complex decoders.
It seems subtitles aren't important enough to have reduced the number of formats. From reading the comments, it seems like the world would benefit from a single format with most capabilities and have everyone convert all files to that. Until then, we need players that understand everything.
I don't seem to find a way to update VLC to 2.2.5 on Ubuntu (or Debian, or Mint for the matter). I understand Canonical does not provide updates in the repos - but the VideoLAN website's download URL for Ubuntu is just "apt://vlc" - it would be nice to be able to download one or more .deb's too.
Interestingly running VLC 2.2.4 on MacOS 10.12 and checking for updates returns 'VLC 2.2.4 is currently the newest version available.', obviously I downloaded 2.2.5.1 from videolan.org but still odd.
I strip all mp3 metadata using the 'id3mtag' tool[1].
id3 -d *.mp3 ; id3 -2 -d *.mp3
That deleted all tags - v1 and v2 id3 tags.
I don't do this for security - I just don't like mp3 metadata competing with metadata in the filename and most mp3 metadata is laughably bad anyway[2] so I just wipe it.
[1] /usr/ports/audio/id3mtag on FreeBSD
[2] Misspellings, First Last instead of Last, First, ALL CAPS ALL THE TIME and using special characters/unicode that always breaks car stereo implementations.
Can anyone recommend a video player written in a memory-safe language for OSX that handles MKV files? Or is the simple truth that the problem lies in the parsers, which are shipped as a library written in C, because no sane developer wants to rewrite parsers for 25 different subtitle formats when writing a video player?
mpv is not affected, at least by these four vulnerabilities. They all seem to be specific to each video player, rather than affecting shared code or code in open source multimedia libraries.
It would be interesting to see which subtitles are using these vulnerabilities and what they are achieving with them. We could estimate how long this has been around.
This is another reason you should use a tool like a parser generator when you have to parse untrusted data, rather than writing your own parser by hand.
This is interesting to me for reasons outside of anything to do with exploits or malware. A while back I had a bit of a brain fart while playing with my Hue bulbs: would there be a way to use the subtitle track for a video to encode time-controlled data that can be sent to/read by another application that sends these values to a set of Hue bulbs or similar devices for synchronized ambient lighting?
I figured that subtitles were an obvious place to start because you can download them in small files, play them back alongside a video, and they are designed to be "timed out" to synchronize with a video already.
I looked into it for a bit but never really found a way (within my abilities at least) to do anything like this from within a .srt file or similar. I'd be interested in hearing if anyone else has more info on how you might do more with that "framework" than displaying text on screen.
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 subtitles on top of the video it's the same.
I wish a fraction of the energy we put into DRM would go into sandboxing instead.
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, 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 :)
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.
Video players are among the most difficult of applications to sandbox. The codecs involved may be in-app software or hardware reached via one of a dozen abstraction APIs. The same is true for audio and frame buffer access. There is a huge amount of code that needs holes poked in the sandbox walls to function.
And realistically once you do that you have another component out there with all that complexity and permissions to exploit. That's exactly what happened with Android. The apps have a clean sandbox, so all the exploits target the mediaserver process instead.
If Popcorn Time renders all subtitles as HTML, would an exploit work if the subtitles were embedded in video container? Seed latest hit on Pirate Bay, root a lot of boxes. Yikes.
[+] [-] ConfucianNardin|8 years ago|reply
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.
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).
[+] [-] AdmiralAsshat|8 years ago|reply
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.
[+] [-] jbk|8 years ago|reply
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).
[+] [-] driverdan|8 years ago|reply
[+] [-] leni536|8 years ago|reply
[+] [-] the8472|8 years ago|reply
[+] [-] easuter|8 years ago|reply
[+] [-] OneLessThing|8 years ago|reply
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.
[+] [-] yegle|8 years ago|reply
Having ASLR is not bullet proof to remote code execution, e.g. iOS has ASLR for a long time and can still be jailbroken (which usually involves a code injection etc). The key is info leak, e.g. if you somehow can reliably find the memory location of open() syscall, the memory location of the whole libc can be inferred, and libc is usually large enough to construct a ROP chain. (I haven't work in security area for a long time so correct me if I'm wrong).
The researcher unable to provide a POC for vlc could simply mean it's hard due to ASLR, but it's not impossible.
Also: I believe ASLR is a compiler option (with a supported OS), it should be relatively easy for Kodi and Popcorn Time to start using ASLR.
[+] [-] jbk|8 years ago|reply
Also, the security researcher did not provide a demo for the VLC exploit. Their demo is only on Kodi and popcorntime.
But anyway, security issues means releases.
[+] [-] Animats|8 years ago|reply
Address space randomization is not "protection". It's a form of security by obscurity. The odds of an exploit working are reduced, at the expense of more crashes due to exploit failure.
It helps developers ignore bugs, since they can no longer reproduce them.
[+] [-] foobarrio|8 years ago|reply
[+] [-] resoluti0n|8 years ago|reply
https://kodi.tv/article/kodi-v172-minor-bug-fix-and-security...
[+] [-] kutkloon7|8 years ago|reply
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.
[+] [-] FranOntanaya|8 years ago|reply
Well, which one of them. There's nearly a hundred different subtitle formats, and each one has a whole set of variants. Just Timed Text alone (XML) can have more layouts than one could count, specially since it's meant to be able to replicate technically all previous industry formats.
[+] [-] etix|8 years ago|reply
http://trac.opensubtitles.org/projects/opensubtitles/wiki/Ha...
[+] [-] stordoff|8 years ago|reply
Depends on the format. SSA for instance can have embedded font and image files, which presumably have much more complex decoders.
[+] [-] phkahler|8 years ago|reply
[+] [-] _jomo|8 years ago|reply
https://github.com/videolan/vlc/search?utf8=%E2%9C%93&q=subt...
[+] [-] pjmlp|8 years ago|reply
> Fix potential heap buffer overflow
> Fix potential out of bound read
> Fix invalid double increment.
[+] [-] aruggirello|8 years ago|reply
Do we have to build it from source?
[+] [-] pawadu|8 years ago|reply
Maybe we should stop random people from contributing to complex C projects?
[+] [-] mrmondo|8 years ago|reply
[+] [-] jbk|8 years ago|reply
[+] [-] anon1385|8 years ago|reply
[+] [-] zippoxer|8 years ago|reply
[+] [-] greggman|8 years ago|reply
[+] [-] pawadu|8 years ago|reply
[+] [-] rsync|8 years ago|reply
I don't do this for security - I just don't like mp3 metadata competing with metadata in the filename and most mp3 metadata is laughably bad anyway[2] so I just wipe it.
[1] /usr/ports/audio/id3mtag on FreeBSD
[2] Misspellings, First Last instead of Last, First, ALL CAPS ALL THE TIME and using special characters/unicode that always breaks car stereo implementations.
[+] [-] chii|8 years ago|reply
[+] [-] runeks|8 years ago|reply
[+] [-] jbk|8 years ago|reply
[+] [-] sotojuan|8 years ago|reply
[+] [-] rossy|8 years ago|reply
[+] [-] m1el|8 years ago|reply
[+] [-] sparaker|8 years ago|reply
[+] [-] mplewis|8 years ago|reply
[+] [-] Sujan|8 years ago|reply
[+] [-] soylentcola|8 years ago|reply
I figured that subtitles were an obvious place to start because you can download them in small files, play them back alongside a video, and they are designed to be "timed out" to synchronize with a video already.
I looked into it for a bit but never really found a way (within my abilities at least) to do anything like this from within a .srt file or similar. I'd be interested in hearing if anyone else has more info on how you might do more with that "framework" than displaying text on screen.
[+] [-] Filligree|8 years ago|reply
Is there any more clarity around the situation now?
[+] [-] captainmuon|8 years ago|reply
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 subtitles on top of the video it's the same.
I wish a fraction of the energy we put into DRM would go into sandboxing instead.
[+] [-] jbk|8 years ago|reply
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 :)
[+] [-] simias|8 years ago|reply
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.
[+] [-] Tepix|8 years ago|reply
Woah, what a sense of entitlement! What's your excuse for not having submitted a patch years ago?
[+] [-] ajross|8 years ago|reply
And realistically once you do that you have another component out there with all that complexity and permissions to exploit. That's exactly what happened with Android. The apps have a clean sandbox, so all the exploits target the mediaserver process instead.
[+] [-] adynatos|8 years ago|reply
[+] [-] lanius|8 years ago|reply
[+] [-] buttcoinslol|8 years ago|reply
[+] [-] yq|8 years ago|reply
https://www.youtube.com/watch?v=vYT_EGty_6A
[+] [-] unknown|8 years ago|reply
[deleted]