Conversation

This Tweet was deleted by the Tweet author. Learn more

Status Quo

@KardOnIce

Apr 18, 2019

Replying to

@vyodaiken

@RichFelker

and 7 others

For the explicit use-cases I'm listing though, that is an expectation. People post proteomics files online for public use, so randomly uploading and downloading files for people to run on a local application is an expected use, much like it is with Word documents.

This Tweet was deleted by the Tweet author. Learn more

Replying to

Sharing image editing documents / word processing documents, etc. is irresponsible? What about media files? It's certainly a design objective of SQLite to handle untrusted files properly and they put far more effort into that than most alternative file format implementations.

Replying to

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.

Replying to

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?

Replying to

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.

Replying to

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.

Replying to

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.

Replying to

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.

Replying to

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.

2:46 AM · Apr 18, 2019Twitter Web Client

Replying to

Any library that makes syscalls to parse/decode png is bogus.

Replying to

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.

Show replies