Earlier quoted context omitted.
Look at FFmpeg and all the multimedia libraries and you will be horrified.
I thought they cleaned up after the last round of exploits?
hahah :)
I wish :)
Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
61–70 of 234 posts
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#62Earlier quoted context omitted.
Moving 4K / 10-bit buffers at 30 or 60 fps (because 3D) between processes is not as easy as it sounds.
Both Windows and OS X provide ways for a sandboxed process to draw directly to a GPU-resident texture owned by another process. Chrome's renderer sandbox is a good example of this technique.
A media player is rarely that simple. Before writing to the GPU you have to access the content (file, network), demux, then decode and finally display.
The most dangerous areas are the demuxers and decoders so they have to be sandboxed.
So yes, you're right, but this doesn't solve the problem of moving the buffers between processes.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#63Slightly related to this: where can I find data sanitizers for common file formats (PDF, MP3 and so on)?
what counts as sanitizing? How do you know a file is malicious?
Especially with PDFs, my "sanitization" can be your "stripped away all the fonts and functionality - might as well have given me a plain .TXT", and vice versa.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#64Wow, 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,…
You actually don't NEED a lot of these things
I'm perfectly fine with a default / embedded font.
I don't have an optical drive
A database can be in the local app storage.
I'm fine opening a subtitle file myself.
Why would I need IPC?
Why would I need to unzip anything? If it's subtitle files, it can be done in-memory.
Are you sure we need low-level audio?
I don't have a remote, so I'd like it to be disabled by default. I don't need any access to the network.
etc. etc. etc
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#65Earlier quoted context omitted.
Both Windows and OS X provide ways for a sandboxed process to draw directly to a GPU-resident texture owned by another process. Chrome's renderer sandbox is a good example of this technique.
A media player is rarely that simple. Before writing to the GPU you have to access the content (file, network), demux, then decode and finally display. The most dangerous areas are the demuxers and decoders so they have to be sandboxed. So yes, you're right, but this doesn't solve the problem of moving the buffers between processes.
You can share file handles/sockets on Windows/OSX/Linux via IPC without giving the renderer process the ability to open the files/sockets themselves.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#66The 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.
They use a hash function to match subtitles.
http://trac.opensubtitles.org/projects/opensubtitles/wiki/Ha...
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#67Earlier 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,…
You actually don't NEED a lot of these things I'm perfectly fine with a default / embedded font. I don't have an optical drive A database can be in the local app storage. I'm fine opening a subtitle file myself. Why would I need IPC? Why would I need to unzip anything? If it's subtitle files, it can be done in-memory. Are you sure we need low-level audio? I don't have a remote, so I'd like it to be disabled by defaul…
Congratulations, you don't need those things. What about the other 19.999.999* users? Are you sure they don't need any of those things? :)
* Arbitrary number.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#68Hollywood is resorting to shitty tactics
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#69> The attack vector relies heavily on the poor state of security in the way various media players process subtitle files and the large number of subtitle formats. Well, last years exploits against iOS, Android and Ubuntu where all related to media metadata processing. It is only natural that the same folks screw up this one too.
What same folks? iOS, Android and Ubuntu are not developed by the same people. More than that, it's not like these apps are actually developed by Apple, Google or Canonical.
Plus you're dissing some very complex projects. I think you're underestimating the complexity of the work these "same folks" are doing.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#70Earlier 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,…
Interesting. I am only interested in these features: - 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); - you need access to the system settings to disable screensavers, and adjust brightness; - you need to unzip, untar, decrypt,…
The first part are the dangerous parts.