They are also far more successful at avoiding vulnerabilities in practice. Still, there are occasional memory corruption bugs. It doesn't make sense to blame on them rather than the tooling. I would certainly rather open an untrusted SQLite database than an MP4 file with FFmpeg.
Conversation
I would expect more servers have been hacked due to exploits in ImageMagick than SQLite. Should we stop opening untrusted images on the web as well?
1
No, but we should stop using a library that's not suitable to it. ImageMagick is awesome software in terms of functionality, but not suitable for opening untrusted files, especially of wacky type.
1
What library would you use even to just render a PNG (relatively simple format) to pixels without a significant risk of remote code execution? If I had to stake my life on this, I'm not going with a library written in C, that's for sure.
1
1
If I were running a web service that received png files uploaded by users and needed to process them, the png decoding would run in its own process with full seccomp and then I would use whatever code I like.
1
There's a huge trusted computing base for that. It's far easier and more realistic to write a safe PNG -> pixels parser than it is to make safe sandbox for arbitrary native code execution by an attacker. The easiest boundary to defend is preventing initial arbitrary code exec.
1
And these things are not exclusive from each other. Using a sandbox does not mean you can't also use a safer PNG implementation. I asked which library you would pick which is still entirely relevant with a sandbox and determines how tightly implemented the sandbox can be too.
1
1
Any library that makes syscalls to parse/decode png is bogus.
1
It at least needs read(...) to retrieve data and write(...) to output the pixels along with the memory management system calls (mmap, munmap, mprotect, mremap). There is a lot more attack surface exposed than just the internal of those system calls.
1
Um, of course not. Caller provides the input an output buffers.
1
So how exactly is the caller going to get the pixels out of the process? Shared memory?
And which PNG library is going to work in this kind of environment, since the whole point was which PNG library you would use. It's not a super complex file format like many others.
Yes, shared memory is the approach with the least attack surface. If it needs malloc (it shouldn't, but bad ones will), a bump allocator with free nopped out and bounded workspace in bss works fine.