are you perhaps a teen? that's a magnet link, its used to transfer things via bittorrent. we used to put them in the spokes of our bicycles when we'd ride down to the five-and-dime
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.
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.
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.
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.
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.
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.
I've not torrented in at least a decade, and I don't remember seeing magnet links inline in text like that.
Certainly don't miss those hours of waiting for an ISO to download only to find it's all corrupt, or a record label plant, or a handheld recording of a cinema screen...
I think you mean 2 decades. I haven't waited an hour for anything to download since I used to grab bootleg concerts that were very poorly seeded in the early/mid aughts.
I thought you were right at first, but with commercial VPNs constantly be advertised as a way to get around content restrictions, I wouldn't be surprised if more people understood a VPN than a torrent these days. Assuming they're willing to pay that is.
"Understood" is different from "can afford" and "has the ability to purchase," and definitely different from "will subscribe to an otherwise useless British VPN in order to watch two hours of television."
Most such VPN providers have servers on multiple location. UK is very popular location so just connect to it if you already paid for VPN. I think some people already paid for VPN as I can see YouTuber's ads.
You might want to check if your router/firewall/ISP blocks/throttles torrent traffic, I'm seeing 173 seeds and just 18 peers (for the first part), it should quickly go up to full speed.
And if you happen to be belong to the rest of the ~99.13% world population, you can grab it here: