Security Bulletin VLC 3.0.11(videolan.org)
videolan.org
Security Bulletin VLC 3.0.11
https://www.videolan.org/security/sb-vlc3011.html
7 comments
Crown prince of Saudi Arabia hacked Jeff Bezos's phone by sending him a video over WhatsApp, so its definitely something that agencies are already hard at work on.
This has already been done.
Not to defend pedophiles but they seem like the canaries of tor; there was recently one in California who remained anonymous (while using facebook no less) on tor for two years until the FBI got involved and paid for a custom exploit. Somehow they were able to use a malformed video file to leak his IP.
Not to defend pedophiles but they seem like the canaries of tor; there was recently one in California who remained anonymous (while using facebook no less) on tor for two years until the FBI got involved and paid for a custom exploit. Somehow they were able to use a malformed video file to leak his IP.
Very well said.
It's really hard to exploit because 99.999% of video are watched online by streaming meaning that there are layers of re-encoding everywhere, so your payload is impossible to deliver there.
The only way I see to work is by using torrent where the content is exactly the same as the one you crafted locally.
The only way I see to work is by using torrent where the content is exactly the same as the one you crafted locally.
Pirated movies represent a substantial vector. A substantial minority even in the US pirates movies. Once a person is infected other means can be used to attack machines which share files or communicate with the infected computer.
Given a company with thousands of employees what are the chances that several pirate movies? Patient zero acquires an infection and sends email to many employees which contains a link to say a url when viewed results in other employee machines getting attacked and ultimately company machines compromised.
Given a company with thousands of employees what are the chances that several pirate movies? Patient zero acquires an infection and sends email to many employees which contains a link to say a url when viewed results in other employee machines getting attacked and ultimately company machines compromised.
What's an effective strategy to combat this? Will re-encoding all externally sourced videos work or do you have to do something else?
I'm not familiar with attacks against video codecs. I always assumed that malicious videos would use buffer overflows injected into metadata for videos (or subtitles). But if they can be injected into video streams directly, will they carry over when re-encoded?
I'm not familiar with attacks against video codecs. I always assumed that malicious videos would use buffer overflows injected into metadata for videos (or subtitles). But if they can be injected into video streams directly, will they carry over when re-encoded?
> Will re-encoding all externally sourced videos work or do you have to do something else?
Re-encoding involves decoding, so if there's a vulnerability in the decoder used there (which may or may not be the same code that would be used to just watch the movie), you're still sunk. I suppose doing the re-encoding in a VM or at least a container would offer some protection.
Re-encoding involves decoding, so if there's a vulnerability in the decoder used there (which may or may not be the same code that would be used to just watch the movie), you're still sunk. I suppose doing the re-encoding in a VM or at least a container would offer some protection.
The "simple" solution to this is diverse decoding-encoding. In two VMs you install two different implementations of a video transcoder. In one VM with one implementation, you decode the video, and in the other VM in a different implementation, you re-encode the decoded video.
To succeed, the vulnerability would have to work against two different software implementations of a decoder and an encoder, and predict which ones you'd use. For extra effect you could randomize what you use each time. Attacker would have to infect a whole lot of videos to finally hit on the one that you decode-encode in the right combination using an incredibly complex vulnerability.
Nobody in their right mind would ever develop this vuln, just like nobody in their right mind would implement this defense :-)
To succeed, the vulnerability would have to work against two different software implementations of a decoder and an encoder, and predict which ones you'd use. For extra effect you could randomize what you use each time. Attacker would have to infect a whole lot of videos to finally hit on the one that you decode-encode in the right combination using an incredibly complex vulnerability.
Nobody in their right mind would ever develop this vuln, just like nobody in their right mind would implement this defense :-)
Presumably the easiest strategy is not pirating movies or not watching them on machines that also have access to important resources. For example watching on a machine in your living room that only does games/music/videos seems reasonable.
Another option could be a VM that just runs minimal linux, reencodes your pirated movie, and then shuts down. Of course this assumes no one figures out a vuln that lets you execute arbitrary code from the movie file AND a vm breakout at the same time :)
Wouldn't it just have to infect the vm like before and then reinsert the malware in the newly encoded video. No vm escape required a little meta thinking.
You could use 2 VHDs: One for the OS that's mounted R/O, and then one for the video file that's R/W. You only use the video VHD once, then destroy it. You also reboot between every file.
Edit: oh I see what you're saying. It'd be in the same encode. I'd have to think about it more, but I wonder if there's potential for playing games with the page table to mark things as read only or something. It's a fun thought exercise :)
Edit: oh I see what you're saying. It'd be in the same encode. I'd have to think about it more, but I wonder if there's potential for playing games with the page table to mark things as read only or something. It's a fun thought exercise :)
Remember when VLC was in the Vault 7 Wikileaks release? It turned out the CIA could deliver a media file which had a surveillance payload. It wasn't ever made clear if this required a special bugged VLC or if the main VLC was in fact the bugged one.
DropBox would work (that's what FB did), so would serving the video directly.
That's how Facebook does it.[1]
1. https://www.vice.com/en_us/article/v7gd9b/facebook-helped-fb...
1. https://www.vice.com/en_us/article/v7gd9b/facebook-helped-fb...
> The firm worked with a Facebook engineer and wrote a program that would attach an exploit taking advantage of a flaw in Tails’ video player to reveal the real IP address of the person viewing the video.
Pretty strange. Shouldn’t the computer’s IP be like 192.168.0.1 or something? Maybe it took a traceroute (over public internet) and sent that away?
Pretty strange. Shouldn’t the computer’s IP be like 192.168.0.1 or something? Maybe it took a traceroute (over public internet) and sent that away?
I assume it didn't "detect" the address so much as it was able to make some kind of a network connection to an external server without going through Tor.
[deleted]
Are there any exploits based on fonts?
Many. Here's another famous one: https://en.wikipedia.org/wiki/JailbreakMe#JailbreakMe_2.0_(i...
It's even more of a problem because the whold world uses basically just one implementation (ffmpeg).
Having lived through the age of Kazaa and Morpheus, where it was on the end-user to scour the shady web looking for magical codecs that would let our silly anime videos render properly, I don't particularly miss it. Despite the fact that Windows Media Classic + K-Lite Codec pack perhaps ran a little faster on my student laptop, I remember being overjoyed that a single, standalone binary (VLC) could play everything I threw at it. It could even fit on my thumb-drive, allowing me to run it on a friend or family's laptop if they were having trouble with a particular video file.
Even Media Player Classic and K-Lite use the codecs from ffmpeg, and don't implement their own.
Can’t agree more. Every codec implementation or video-related software package is just a giant pile of pointer-heavy C/C++ code. It’s not a bad thing because it’s fast and practically still the only way to do it. But looking at cosebases like VLC and especially ffmpeg makes me a little nervous. How many bugs like this are hidden in these libraries that we don’t know about?
IIRC, there was a project within the VLC team to port a codec to rust (it was shown off at a con talk IIRC). I'm curious what happened to that project.
Also, it looks like the VLC Summer of Code ("SoC") 2020[1] mentions a potential project for fuzzing.
[1] https://wiki.videolan.org/SoC_2020/
Also, it looks like the VLC Summer of Code ("SoC") 2020[1] mentions a potential project for fuzzing.
[1] https://wiki.videolan.org/SoC_2020/
Kostya (long time ffmpeg contributor from e.g. RV40 reverse engineering) moved on to writing a greenfield ffmpeg alternative purely in Rust, with all new codecs, named NihAV.
Follow the blog: https://codecs.multimedia.cx/ but there's no source code release yet AFAIK.
Follow the blog: https://codecs.multimedia.cx/ but there's no source code release yet AFAIK.
> Follow the blog: https://codecs.multimedia.cx/ but there's no source code release yet AFAIK.
Nice; though the documentation/blog is quite hard to follow :)
Nice; though the documentation/blog is quite hard to follow :)
What would you think about sandboxing all media related components?
> What would you think about sandboxing all media related components?
You have to be very _specific_ when you say _sandboxing_. Since, the attack surface is mostly at the decoding layer - there are at least few dozen ways to sandbox the processing logic on modern UNIX-like OS based on the requirements:
1. Farm out, give it its own namespace and filtered list of seccomp2 calls to do the decoding.
2. Farm out, compartmentalize the decoding layer to BSD jails
3. Same as 2) but using chroot - give the necessary libs/bins/mount
4. Farm out, run the decoding components on a separate VM - somewhat akin to QubeOS.
5. Farm out, run ephemeral spark jobs to process the decoding on a compartmentalized VMs/Containers....
These days the word _sandbox_ is overloaded.
It used to be that you put things that are in userland under selinux and go to bed at night.....
You have to be very _specific_ when you say _sandboxing_. Since, the attack surface is mostly at the decoding layer - there are at least few dozen ways to sandbox the processing logic on modern UNIX-like OS based on the requirements:
1. Farm out, give it its own namespace and filtered list of seccomp2 calls to do the decoding.
2. Farm out, compartmentalize the decoding layer to BSD jails
3. Same as 2) but using chroot - give the necessary libs/bins/mount
4. Farm out, run the decoding components on a separate VM - somewhat akin to QubeOS.
5. Farm out, run ephemeral spark jobs to process the decoding on a compartmentalized VMs/Containers....
These days the word _sandbox_ is overloaded.
It used to be that you put things that are in userland under selinux and go to bed at night.....
[deleted]
Currently, this code is only reachable in the case of a hardware decoder, on macOS, using VideoToolbox library, when it needs annexB conversion.
But as there are other issues on other dependencies, we preferred to bump it everywhere.
But as there are other issues on other dependencies, we preferred to bump it everywhere.
Clarifications that are not clear from the title:
- 3.0.11 is the fixed version, the bulletin isn't about a vuln in that version.
- It only affects iOS/macOS
- 3.0.11 is the fixed version, the bulletin isn't about a vuln in that version.
- It only affects iOS/macOS
Maybe this is an opportunity to try another open source video player. Smplayer also works on windows mac and linux.
- Preferences menu isn't broken into normal and space shuttle control panel.
- Playlist works in fullscreen mode which isn't the case with VLC.
- Saves place in videos by default, mpv the simpler interface is actually smarter and remembers the position in a group of files if you pass it the same files. I think VLC can do this but its somewhere in the space shuttle preferences interface.
- Adding a folder doesn't add non video files to a playlist
- Audio syncing doesn't appear to be an issue over the network
- It understands any network stream that youtube-dl supports which seems to be much better than vlc
- Preferences menu isn't broken into normal and space shuttle control panel.
- Playlist works in fullscreen mode which isn't the case with VLC.
- Saves place in videos by default, mpv the simpler interface is actually smarter and remembers the position in a group of files if you pass it the same files. I think VLC can do this but its somewhere in the space shuttle preferences interface.
- Adding a folder doesn't add non video files to a playlist
- Audio syncing doesn't appear to be an issue over the network
- It understands any network stream that youtube-dl supports which seems to be much better than vlc
As far as I know, SMplayer is based off of mplayer which uses ffmpeg under the hood, just like VLC. The most serious vulnerabilities would be present on both (although I think this exploit is VLC specific).
Smplayer can use mplayer or mpv which in turn can use ffmpeg or in theory its fork libav. There is a big intersection under the hood and indeed there is a possibility for a defect to effect both VLC although this issue is vlc and mac specific.
I don't think Smplayer is more secure I just think its a better tool than VLC.
I don't think Smplayer is more secure I just think its a better tool than VLC.
I am always suspecting porn sites to be a huge honeypot for any sort of malware. I am still betting most browsers still have their share of 0-days.
3.0.10 was such a buggy release for mac0S. Astonished they let something so awful out and that it took months to release a fix.
People open video and images files all the time. The amount of breath I see burned here on obscure or niche security concerns is ridiculous. The implementations aren’t buggy, they are just written by like one person, the sole maintainer you cannot under any circumstances discourage from doing this work, with a criticism-proof godlike level of knowledge, in vast amounts of uncommented code that makes huge numbers of unenforceable assumptions in the pursuit of better performance, targeting vast hardware with closed source binary blobs also seeking performance, on every popular platform. It’s a minefield.