Hacker News Reader

Comment by Thaxll | Hacker News Reader

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.

View on HN

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.

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?

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 :)

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

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 :-)

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.

Reply on news.ycombinator.com