Hacker News Reader

Comment by an_opabinia | Hacker News Reader

Media decoders are the biggest, richest, unexploited, practical and valuable target for developing end user malware and government surveillance. If I wanted to surveil a dissident using Tor for example I would deliver the payload in a protest video they download or whatever.

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.

View on HN

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.

DropBox would work (that's what FB did), so would serving the video directly.

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.

That's how Facebook does it.[1]

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?

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.

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?

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

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/

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.

Nice; though the documentation/blog is quite hard to follow :)

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.

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.

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.

Are there any exploits based on fonts?

Yes.

https://arstechnica.com/information-technology/2020/03/attac...

Many. Here's another famous one: https://en.wikipedia.org/wiki/JailbreakMe#JailbreakMe_2.0_(i...

Very well said.

Reply on news.ycombinator.com