[wil421]

When I was riding bikes to the store we had dialup and floppies were giving way to CDs.

It’s been over a decade since I’ve used BitTorrent and I didn’t know magnet links were still popular. I hate seeding and there was also a lot of malware hidden in public trackers.

Once I switched to Usenet I never looked back. P2P file sharing has never been a good experience for me.

[ryandrake]

How does one get malware from playing a .mkv or .mp4 video file?

[vel0city]

Media decoders are often rather complicated and often involve parsing data directly into large and constantly changing memory buffers. A huge chunk of Android vulnerabilities have been from vulnerabilities in media libraries, even JPEG parsing has been known to lead to vulnerabilities in Linux.

[Laaas]

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.

[Loughla]

Why do I feel like the people downloading ConAir(1997)YIFYWEB-DLs.MKV are not high value targets?

[chongli]

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?

[eclipxe]

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.

[chongli]

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.

[vel0city]

> 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...

[fsflover]

With Qubes OS I don't have to care what a video player does, since it's isolated in a hardware-virtualized VM.

[sprayk]

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.

[pessimizer]

overflows

[chongli]

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.

[MobiusHorizons]

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.

[bobdvb]

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.

[vel0city]

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.

[1317]

both of those examples happen within normal usage

file system for finding external subs (or like, playing the video)

internet for streaming

and then oh look, it has the permission

[wil421]

Most of the time it’s a rar file that contains screenshots, album art, thumbnails, etc. not just a video file. I’ve been burnt a decade plus ago when I automated some extractions into a media folder on an old windows laptop. By the time I noticed, it was deep in the registry and near impossible to remove. It was something akin to MacKeeper malware on Macs, I don’t recall the old windows malware names.

With my Usenet automation I’ve never had the issue in about 9ish years but it could happen. I pay a usenet provider and indexer a low fee to rid myself of torrents and seeding.

[ghotli]

This is a really good talk I saw in person on this exact subject. Focuses on using rust and the nom library for safe parsing. He opens with a description of how VLC is one of the worst offenders for vulnerabilities historically because it supports so many different file formats / parsers written in c.

> Safe and fast parsers with Nom and Rust

https://www.youtube.com/watch?v=8mA5ZwWB3M0

[dec0dedab0de]

There would need to be an unpatched vulnerability in your player that the file exploited. Only virus I ever got was from an mp3 file that exploited the vulnerable version of winamp that I was using because I hated the newer version.

[brokenmachine]

There's a really good explanation in the book "A Bug Hunters Diary".

It used an old version of vlc and a buffer overflow vulnerability to get code execution.

[Laaas]

What do you use instead? IPFS isn't very practical compared to Bittorrent I find.

[mlindner]

There's no malware risk from trackers lol...

[ayewo]

Which Usenet service do you use?