9 ms·
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 applica
by captainmuon 9y ago
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.
- jbk 9y agoHa, 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 :)
- viraptor 9y agoNot 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 potential issues, but we can start chipping away some stuff right now. There's a lot we can fix without fixing everything at the same time.
- dom0 9y ago> 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.
- MereInterest 9y agoI get equally confused anytime Microsoft Office gives the "Files from the internet may contain viruses." warning. How do you mess up a document editor so badly that the document can affect the computer? I know that the answer is Visual Basic, and I know that there are legacy reasons why it will never be removed, but holy cow, it is ridiculous.
- RobAley 9y agoIt's not just VB. Any code in a program which parses any kind of data, including "passive" data like images, docs and even plain text, is vulnerable to bugs in it's own code. It's often not related to what the data is, but the way in which it is handled.
- bsandert 9y agoPlease don't fall into the Dunning-Kruger[0] trap by assuming a straightforward task is also easy to perform. These things may very well be complex and include aspects that are not immediately obvious. And even if they don't, even simple code executing simple tasks can be vulnerable to bugs or flawed reasoning without the authors (or tooling) being stupid or naive. [0]: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
- innocenat 9y agoAnd I find this especially true for anything media-related. I am amazed it even works for most user without problem [0] [0] Obvious problems, like unplayable, etc. Minor problems (chroma placement error, transfer function, etc) seems to occur very frequently.
- tomp 9y agoWell, M$ Office makes sense, since it's macros. What I really don't understand is Acrobat Reader. It has a "Protected View", which is the first WTF - .pdf-s are read-only, so there should be absolutely zero active code running anyways. What's the next, much bigger WTF WTF WTF is that you need to exit protected view to print the document. How can the program read and render the document on screen, but not print it?! How is this even possible?
- etix 9y agoMoving 4K / 10-bit buffers at 30 or 60 fps (because 3D) between processes is not as easy as it sounds.
- johncolanduoni 9y agoBoth 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.
- jbk 9y agoSure, but then you need a multi-process sandbox, and it's not easy to do. And the performance is not easy to obtain.
- johncolanduoni 9y agoYou can co-opt Chromium's. I've been doing that with a project I'm working on and it has worked quite well. I'm also not sure where you'd lose much performance. If you hand the file handles/sockets and backbuffer to the renderer, you only need enough IPC to synchronize the drawing. Sending small messages on the order of 100 times per second between processes is not going to be a bottleneck.
- jbk 9y agoBut you need to pass data from the access to the stream_filter, from the stream_filter to the demuxer, from the demuxer to several decoders, from the decoders to potentially a few video-filters and chroma-converters, and then finally to the output. Each of them need different access policies, and several of them require FS access. It is not easy. If it was, people would have done it already.
- johncolanduoni 9y agoYou can get most of the security people are asking for without that level of granularity. If the decoder is exploited and is able to attack the demuxer, that's still worlds better than the decoder being able to run with full user privileges. Do any of those components need unrestricted/unpredictable file access? Because if they don't you can just open the files in the main process that handles the UI and send them to the sandboxed process via IPC. None of Windows/OSX/Linux do permission checks when file handles are read from, they only check when the file is initially opened.
- cesarb 9y agoAFAIK, fonts aren't a passive format, they contain code which executes in a VM.
- marcosdumay 9y agoAt least SRT files are a purely declarative sequence of lines with "time time text".
- jbk 9y agoBut SSA is not. It's specifying a font and sometimes even shipping a font inside the SSA file.
- Khao 9y ago"Officially", SRT files are only timecodes and text, but most players support html codes directly like <b> <i> <u> to support more formatting options than the basic SRT. I wonder if some of them simply render the text as html and could be vulnerable to similar attacks. I say "Officially" because SRT has no standard, it just evolved through usage and it's a fucking mess, as I'm a software dev working on a subtitling editor software.
- olau 9y agoI seen a similar problem in another context where a browser engine is used to render some simple HTML in an app for convenience, but then suddenly turns into something exploitable because nobody is thinking about updating the engine when a bug is found in an esoteric (for the app) feature. Embedded web engines should probably have a minimalistic safe mode.
- Tepix 9y ago"There is no excuse that these kind of applications are not completely sandboxed." Woah, what a sense of entitlement! What's your excuse for not having submitted a patch years ago?
- deleted 9y ago[deleted]
- weberc2 9y agoNot the OP, but valid responses range from "I have a life" to "it's not my project" to "I don't want to". Odd that you think criticism depends on contribution.
- riffraff 9y agothose are likely most of the same reasons these apps are not sandboxed (switching "not my project" with "I'm not payed work on this").
- weberc2 9y agoThose are valid reasons not to improve a project, but it doesn't make your project immune to criticism. If you're not going to take the time to make your project better, that's fine, but other people are still free to point out that your project isn't very good or that your project could be much better if you managed your time differently.
- simias 9y agoI 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.
- ajross 9y agoVideo 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.
- zelphir_kalt 9y agoSo far I did not know that there is anything in video subtitles, that needs interpretation. What is needed is not a sandbox, but simply code, which stops trying to do weird stuff with something as static as subtitles. They should be a timestamp for the time in the video where the text shall appear plus text itself nothing more. If it does not parse according to a specific format throw that stuff away and read the next line in a subtitles file or simply declare the whole file invalid and be done with it. Don't try and start doing weird things with something like subtitles and we are fine. Why does VLC or one of the other programs feel the need to do anything more than that, resulting in gaping security vulnerabilities? Is there any good justification? Or is this again about some overflow with unexpectedly long strings or something like that? (In such case it is the not so careful programming on VLC side that is the problem) Furthermore the subtitles are often inside the video graphical data itself. I've actually never used a subtitles file. I tried a few times, but every single damn time they were off, and not only off but exponentially off, which made it impossible to get the correct text for all play positions in the video. If you ask me, so far all the subtitle files I tried for any movie suck anyway. (This is ignoring any subtitle file specifications, which might exist.)
- thaumasiotes 9y ago> They should be a timestamp for the time in the video where the text shall appear plus text itself nothing more. I think the option to have positioning information was a good idea.