A sophisticated attacker could make use of bugs in the player to hack the system. This sort of trick is often used against high value targets where the effort needed makes it worth it.
Why does the video player have the capability to do anything other than read video files the user specifies through the system file chooser dialog and play them on the screen?
Because playing them on the screen involves demuxing audio and video, decoding audio and video, usually using two different but complex codecs, some which have extensive capabilities and features (think multilingual subtitles, interactive menus, etc etc). Oh surely your video player should allow you to pause and play with a remote control, right? More code surface. We probably need an ability to check for updates. And so on and so on.
But even without anything more than open, decode, play - anywhere a vulnerability exists could allow an attacker to execute arbitrary code.
All of that stuff should be handled through standard APIs. Applications shouldn’t be updating themselves at all; that’s the job of the operating system’s package manager.
Really, a video player should be a dumb bit of glue code that wires together file open APIs with video playback APIs, and a few bits and bobs for saving preferences (API) and allowing remote control (another API). There’s no reason whatsoever for a video player to be able to access files arbitrarily or connect to the internet or log keystrokes in the background or anything else! The only reason they can do this is because we haven’t built operating systems with all this in mind, apart from mobile OS’s that is.
> All of that stuff should be handled through standard APIs.
"Standard APIs" isn't some silver bullet to never have any security vulnerabilities. There can absolutely be vulnerabilities in "standard APIs".
ffmpeg is a pretty standard media utility, and it gets lots of CVEs. Decoding complicated media is complicated and often done in unsafe languages in attempts to squeeze more performance.
neither video/audio decoders nor demuxers nor subtitle format parsing/rendering have OS APIs. hell, there's at least a few ways you can draw a rendered frame to the screen on any OS that will take different paths through either the OS's drawing APIs (if you're not on Linux) or graphics drivers. Even _if_ the OS supported taking video file data and playing it, it wouldn't support all of the codecs/containers/subs you'd want to play.
No, what I’m asking is: why does the operating system allow the video player to do anything other than what it needs to do to play videos? If the video player suddenly starts trying to access files on its own (anything not explicitly chosen by the user through system file dialog) or trying to access the internet then the user should be prompted to give permission.
We have this kind of API permission (capability) system on phones. Why can’t we have a really fine-grained one on desktops? It’s like a firewall for APIs.
The ux you are describing is a lot worse than what people get with vlc or mplayer. For example, you can open videos from the cli, which means there is no file chooser involved. Also if you have a subtitle file (.srt) with the same name as the video you opened, the subtitles will automatically be added. Both of these are things people want as part of a versatile video player.
The level of lockdown you were describing is what we have on mobile platforms (which incidentally still have lots of malware). Generally speaking, people want more flexibility out of general purpose computers.
On the other hand something like pledge would be useful here, since the attack vector is untrusted files, not untrusted applications. With pledge, the application could open any files, then relinquish the ability to open new files before parsing the contents.
The level of lockdown you were describing is what we have on mobile platforms (which incidentally still have lots of malware). Generally speaking, people want more flexibility out of general purpose computers.
I expected this response. I think it's a false equivalence. We don't need to have a proprietary locked-down operating system like iOS in order to give the user full control over the capabilities an application has access to. We just need a standard API for handling these sorts of permissions.
Granularity is usually the problem here. It is very difficult to fully specify the full set of things you expect a program to be able to do. Even if you could, it is not usually something an end-user will want to do, due to the verbosity involved. Permissions are also time / sequence dependent. If you have something that can specify the user's expectations fully, it will be very verbose due to the inherent complexity, so the system will either be unused, default to overly broad permissions lists, or rely on trusting various pre-baked recipes that others have made. At that point I'm not sure how much you have gained for the average user, and it seems you lose some very real usability in the process.
Curious to hear how you would go about solving this problem. It seems that there is just a lot of inherent complexity here and I can't see any way to avoid that complexity without preventing the system from being useful.
Decoding the video involves hardware acceleration, so data is not just processed at the application layer, it's passed much deeper. In very specific and rare attacks, it's been possible to bypass application and even OS level protections by crafting media files. So that when they're processed there's an overflow which dumps some payload into unprotected memory and allows some intrusion into the viewers system. This has been done with photos, general images and videos.
It's not reliable unless you happen to know the specific, unpatched exploit on the target system. There aren't general purpose vulnerabilities for such things.
Many times these kinds of attacks are buffer overflows, tricking the hardware/OS to execute code it wasn't intending. Its not just that the media player starts to behave strangely, often the attack corrupts code outside the media player. See the Android Mediaserver vulnerabilities, or many of the buffer overflow vulnerabilities in ffmpeg.
If an attack corrupts how the OS checks permissions, it doesn't matter if you've got some API framework for calls, it broke out of it.
