Handle audio and video files

[pde]

Audio and video codecs are full of exploits!

Would it make sense (and be possible on Raspberry Pi hardware) to transcode those to standard formats, and then run a checker/sanitizer over the resulting file?

Obviously not bulletproof, but probably much better than a verbatim copy of a file!

[Rafiot]

If you know about a safe parser for audio/video files to convert in safe formats, I'm listening.

Don't forget it has to run on a rpi.

And if you have malicious files at hand, same, please share them, I'm interested in making the tool more robust.

[pde]

"Safe" is a relative term :). Something that could be done quickly for audio would be to use an insecure tool like mencoder protected by apparmor (or maybe seccomp) to transcode to a simple format like wav, and then a second step to reencode the wav file to mp3 or ogg.

The video case is harder on RPI hardware...

[Rafiot]

I'm not so worried about compromising the rPi itself: the OS is mounted in read only, /tmp is mounted in tmpfs and with noexec, and the script runs as user. If an attacker has a 0day in debian and can obtain root, your attacker has more resources than a 50€ solution can protect against.

Your solution is good, but it doesn't apply in the rpi case:

1. I have at most 1G available on /tmp (on the rpi3, 512M on the older versions)
2. The destination key will have a variable size, but I cannot assume it will be big enough to store a wav file.

There might be cases where it would be possible, and it could make sense to implement it in the python library, as an option.

[pde]

Hmmm, you could probably use a pipe to do this. Pipe the data out of mencoder, through a simple WAV format verifier, into lame. Then you won't need enough disk for a WAV file.

…

On Sat, Feb 03, 2018 at 11:40:03PM +0000, Raphaël Vinot wrote: I'm not so worried about compromising the rPi itself: the OS is mounted in read only, /tmp is mounted in tmpfs and with noexec, and the script runs as user. If an attacker has a 0day in debian and can obtain root, your attacker has more resources than a 50€ solution can protect against. Your solution is good, but it doesn't apply in the rpi case: 1. I have at most 1G available on /tmp (on the rpi3, 512M on the older versions) 2. The destination key will have a variable size, but I cannot assume it will be big enough to store a wav file. There might be cases where it would be possible, and it could make sense to implement it in the python library, as an option. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #26 (comment)

-- Peter Eckersley [email protected] Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993

[Rafiot]

That's a good point... I need to give it a try.

I'm not sure how much time it's going to take on a raspberry, how much ram the encoding will use, and how reliable it will be: I messed around with ghostscript to generate PDF/A years ago and I ended up in endless loops half the time... that's one of the reasons I stopped converting files.