Hacker News new | ask | show | jobs
by eclipxe 1221 days ago
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.
1 comments
chongli 1221 days ago
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.

link
vel0city 1221 days ago
> 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.

https://www.cvedetails.com/vulnerability-list/vendor_id-3611...

link
fsflover 1221 days ago
With Qubes OS I don't have to care what a video player does, since it's isolated in a hardware-virtualized VM.
link
sprayk 1221 days ago
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.
link