1. 30
  1.  

  2. 17

    “You’re almost certainly affected by this extremely serious SQLite vulnerability we found, but we won’t tell you anything about it. Except by the way here’s the commit fixing it in Chromium. Except if you actually visit it all it does is upgrade to an entirely new SQLite version, so it doesn’t actually tell you anything useful. Also we pwd a very widely-used consumer product but we’re never going to tell you how, even after this is fixed.”

    I found this page very frustrating to read. They’re obviously giving vendors time to patch as if they were following the “usual” responsible disclosure procedures (they say they’re pushing vendors to patch in the first paragraph on the page), but if they’re just waiting for vendor coordination why even bother to announce at all? The page feels like it’s just there to build hype about this vulnerability because there’s nothing I can possibly do with it; I can’t examine the code, I can’t learn from the bug, I can’t patch my systems because distributions haven’t issued patches yet. What exactly is the point here? Is it literally just there to tell Google Chrome users to upgrade? (Because, at least on my Debian 9 systems, Chromium has not been fixed yet so only Chrome users can do anything.)

    1. 4

      Yeah…

      Apparently the bug involves letting people run their own queries, which is probably not the case in most deployments (or you are already having a bad time), which can be crafted to corrupt the database.

      1. 13

        Untrusted code can run its own SQL queries against a SQLite database if it’s running in a browser which implements Web SQL. A couple do, still. ¯\_(ツ)_/¯

        Not all browsers ever implemented it at all and it’s deprecated now. The official reason given for deprecating it was that there wans’t a 2nd independent implementation besides SQLite. I suspect a supplementary reason might have been that someone thought giving “oh hey here’s a razor thin wrapper around raw SQLite, just go nuts with that complicated API provided by a huge pile of C code, I’m sure it will definitely not manifest any RCE issues” was unwise.

        1. 6

          I suspect a supplementary reason might have been that someone thought giving “oh hey here’s a razor thin wrapper around raw SQLite, just go nuts with that complicated API provided by a huge pile of C code, I’m sure it will definitely not manifest any RCE issues” was unwise.

          that’s the core reasoning in this post

          1. 2

            Aha! Thanks. I never saw that and I didn’t think it was ever spelled out explicitly in the standards docs.

        2. 7

          https://repo.or.cz/sqlite.git/blob_plain/HEAD:/test/fts3corrupt4.test

          There are some testcases that will crash unpatched sqlite versions (confirmed it using the “DB Browser for SQLite” Windows application). Turning that integer overflow into a heap corruption is an exercise to everyone except Tencent, basically.

          SQLite isn’t an API that’s designed well for running untrusted queries, yet here we are with Web SQL…

        3. 1

          It’s interesting to me that people keep using SQLite as an exemplar arguing how C code can be safe. Even with its level of testing, there’s still RCE’s popping up. So, to answer your question, this announcement further corroborates the crowd saying to use safe, system languages. It also suggest these actions for SQLite itself:

          1. Don’t use it. Use a safer one instead. In realm of DB’s, there might not be a safer one. Search would start with an enumeration of SQL databases done in memory-safe languages. Preferably, concurrency-safe on top of that. If not, we at least have analyzers for some like Java.

          2. Use tech like Softbound+CETS that transforms existing C code into memory-safe code. That might block this one plus the next dozen.

          3. Use isolation architecture with trusted data separated from untrusted. Possibly two instances of the DB. Maybe add a monitor to the untrusted one to catch weird behavior.

          1. 7

            From the post above yours:

            SQLite isn’t an API that’s designed well for running untrusted queries,”

            Except I’d leave out “well”. Sqlite is very solid for doing what it is designed to do. It is not designed as a public front end.

            1. 1

              I agree with that. My point still stands on reliability, though, since the bugs found in testing and analysis were often preventable by a safe language like Ada.

              1. 8

                That list of “security vulnerabilities” is annoying as all hell. 99% of them are: someone built an application that takes untrusted user input and no permission control and incorporate into it a powerful SQL database and then decided to allow the untrusted users direct access to SQL commands and, shockingly, things are not safe. There are on the level of claiming the ADA compiler is unsafe because if you allow untrusted users to write and execute arbitrary ADA programs, someone bad can happen.

                1. 3

                  Sqlite is very solid for doing what it is designed to do. It is not designed as a public front end.

                  Yeah, that’s what I meant. Executing untrusted queries just was never a design goal of SQLite. If that truly is your usecase, it’s probably better to use a database with a real user permission model so you can lock down the attack surface to something smaller than “the whole database.”

                  1. 2

                    Great comparison haha.

          2. 9

            Shocking to find out that giving raw sql access to untrusted users is bad security.

            1. 2

              Read a few pages on this one around the web. Though the linked site is annoyingly vague, it seems that this is based on executing some well-crafted SQL. This shouldn’t affect most uses, since letting people execute arbitrary SQL against your DB is already a very bad idea for many reasons. Only matters here because of WebSQL.

              Don’t know if anyone else has tried to use WebSQL, but I did, and the API seems to be a half-assed undocumented hack. I’d be amazed if there are any sites out there actually doing something useful with it. Probably about time they pulled it out of Chrome. Especially because I doubt this is the only way someone executing arbitrary SQL can get a crash or RCE out of SQLite. Probably not a good idea to pass SQL between trust centers like this.