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