Conversation

This Tweet was deleted by the Tweet author. Learn more

Replying to

I didn't say running untrusted SQL. I said "a lot of attacker control over the database queries". If I meant executing arbitrary SQL, that's what I would have said, and I clearly didn't mean that. Please don't misrepresent my statements any more.

Replying to

sqlite.org/whentouse.html > SQLite does not compete with client/server databases. SQLite competes with fopen(). #2 on list of recommend uses > Application file format Also listed: > Data transfer format And yes, it is widely used this way in the real world, as intended.

Replying to

I believe you. This is a highly irresponsible recommendation, both from a security perspective and a design one, and ppl should ignore it.

This Tweet was deleted by the Tweet author. Learn more

Replying to

Consider something like the XCF file format used by a program like GIMP including all kinds of fancy structured data. People are certainly exchanging these files. SQLite would be a substantially safer base to build on than the current GIMP implementation. I'm quite sure of that.

Replying to

Or heck, .doc or .psd, which are basically just memcpy’d internal structures of Word and Photoshop respectively.

Replying to

That's basically XCF too. github.com/GNOME/gimp/blo They're collaborating with the Krita developers to make en.wikipedia.org/wiki/OpenRaster as a replacement. It's probably going to be even more complex though since they're going to want to add more capabilities.

en.wikipedia.org

OpenRaster - Wikipedia

Replying to

The solution to the problem cannot be not making this kind of software, or somehow getting users not to exchange media files, image editing files, word processor documents, etc. Really just parse the file format in a memory safe language without dynamic code execution.

Replying to

And that memory safe language can certainly be a subset of C with annotations / rules that make it memory safe. No problem with that, I just don't think it's a very useful/practical thing to do personally since I'd rather use a nicer language if it has to be from scratch anyway.

Replying to

We know how to write software with decent security and these kinds of capabilities. It's not a mystery. We choose to use software architectures and languages making it unrealistic to provide decent security. Even if you claim that it's due to programmer incompetence, not tools...

1:44 AM · Apr 18, 2019Twitter Web Client

Replying to

... then clearly there are near 0% competent C programmers. The whole point of safer tooling is that humans aren't being trusted to never make a mistake or miss something. It's extremely hard to right completely correct software and those bugs should not be remotely exploitable.

Replying to

The tools can't allow assorted little mistakes which are certainly going to happen to cause code execution vulnerabilities. It just isn't a viable way to build a secure computing ecosystem still capable of doing the same kinds of things, like loading up a GIMP / Krita project.

Show replies