1. 12

  2. 4

    I found this video particularly interesting given the discussion also occurring right now on the SQLite As An Application File Format thread. The conclusion of that argument on SQLite’s own webpage is:

    SQLite is not the perfect application file format for every situation. But in many cases, SQLite is a far better choice than either a custom file format, a pile-of-files, or a wrapped pile-of-files. SQLite is a high-level, stable, reliable, cross-platform, widely-deployed, extensible, performant, accessible, concurrent file format. It deserves your consideration as the standard file format on your next application design.

    Obviously, the more complex we make things, the broader the attack surface gets. I find it helpful to ask why something was created and whether what I’m trying to use it for was that. In the case of SQLite, I never would have thought twice about running a query against a SQLite file until watching this video. But putting a database in the place of other formats would seem odd to me and this video helps reinforce some of the benefits of trying to be as simple as possible. To tie in another current thread, this would be why my websites have reverted back to static HTML pages: lower attack surface and cheaper hosting due to less computing requirements.

    1. 2

      “But putting a database in the place of other formats”

      It is designed to handle issues, like filesystem failures, that most developers don’t even know how to handle. Many won’t do it. Then, SQLite became complex. Then, we saw how they tested it. We said to ourselves, “Wow! There’s no way anything we quickly throw together will be that reliable. Let’s just use SQLite.” Then, some did. :)

      “I never would have thought twice about running a query against a SQLite file”

      Almost all code is designed assuming the inputs are non-malicious. Many look for faulty input which has some overlap. Evil inputs might do that or more insidious behaviors to force the system to do what it wasn’t designed for. You should assume these two things:

      1. All systems are insecure unless designed otherwise with rigorous, proven methods with an independent evaluation by expert breakers. All apps, especially but not limited to memory-unsafe, may fail insecurely if fed malicious input. They have to be explicitly designed to enforce security properties and/or stop classes of attack.

      2. “Attacks only get better.” (Schneier) New classes of attack will occur. So, you should use mitigations like OpenBSD’s to potentially combat them, damage containment, monitor for odd behavior, have read-only backups of critical data, and a battle-tested way of restoring the system.

      Apply these principles to every piece of hardware, OS kernel, library, or application. It’s always true unless there’s counterexample Im forgetting.

      1. 1

        But putting a database in the place of other formats would seem odd to me

        I think this is unfair in the context that many file formats are attempts at reimplementing dbms with relational objects. Some formats are simple, but many are complex enough and have yielded their fair share of CVE. The way I read the SQLite As An Application File Format article is that instead of reimplementing yet another dbms, why not reuse a battle tested engine.

        On the other hand, this talk brings some question about the SQLite threat model dealing with untrusted database input. A “simple” alternative could be to split SQLite into multiple processes where a restricted “server” handle the database and the client process use a simple protocol to send queries and read results. In most case files parsing is where exploitation happens and doing it in unprivileged process it is simply good practice.