News for hackers. Stuff that matters.
Re:Security Bulletin VLC 3.0.11 by mywittyname on Thursday June 18, 2020 @04:05PM (#23567348)
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?

Re:Security Bulletin VLC 3.0.11 by kelnos on Thursday June 18, 2020 @06:04PM (#23568644)
> 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:Security Bulletin VLC 3.0.11 by peterwwillis on Thursday June 18, 2020 @09:41PM (#23570160)
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 :-)

Re:Security Bulletin VLC 3.0.11 by michaelmrose on Thursday June 18, 2020 @04:17PM (#23567493)
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.
Re:Security Bulletin VLC 3.0.11 by xxpor on Thursday June 18, 2020 @04:47PM (#23567833)
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 :)
Re:Security Bulletin VLC 3.0.11 by michaelmrose on Thursday June 18, 2020 @04:50PM (#23567862)
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.
Re:Security Bulletin VLC 3.0.11 by xxpor on Thursday June 18, 2020 @04:57PM (#23567939)
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 :)