Would you rather people roll their own database format, or use a single tool that aims to be used for that purpose? And, considering the number of bugs I've encountered with HDF5, I'll gladly sign onto the SQLite train.
Conversation
This Tweet was deleted by the Tweet author. Learn more
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.
1
This Tweet was deleted by the Tweet author. Learn more
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.
2
1
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.
1
1
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.
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
Show replies