You better watch out, you better not cry. Better not pout, I'm telling you why: SQLite vuln fixes are coming to town

Google and other software developers have patched the SQLite component of their code after it was discovered it could be potentially exploited to inject malware into vulnerable systems. The security flaw was spotted and reported by researchers at Tencent's Blade Team, and is believed to be present in the SQLite library used by …

[really_adf]

A gold standard

"SQLite was considered a gold standard in terms of secure coding"

Well, given that "Microsoft patched 16 such remote code execution flaws in IE, Edge, and Office less than a week ago" I don't see much damage to that view.

[David Pearce]

The SQLite team have kept the project clean by not doing any feature creep, the focus is a single user database engine, nothing else.

Concentrating on bug fixing and performance improvement more than adding extra functions is very unusual.

[Mage]

IF you allow random internet users to run arbitrary SQL on your system, you should upgrade.

Only hardened servers with security maintained by experts should be allowing inward connections from internet and surely they should use MariaDB, MySQL, Oracle, MS-SQL, not SQLite which is really more a single user convenience?

Web Browsers are a problem. When are they going to have proper white & blacklisting of scripts built in instead of user having to install NoScript, Umatrix etc? When are they going to have proper sandboxing?

Why on earth does Chrome Web Browser need SQLite and have it accessible via the web page? I presume Chromium or anything else based on Chrome is vulnerable.

[Tim99]

Re: IF you allow random internet users to run arbitrary SQL on your system, you should upgrade.

I think you are underestimating the potential security problems of "MariaDB, MySQL, Oracle, MS-SQL” databases. SQLite works surprisingly well as an internet database because the web-server is acting as a single user to the DB (i.e. not a true multiuser system). From personal experience, SQLite can work well as a website database engine - See the "Websites" section in sqlite.org/whentous:-

"SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites). The amount of web traffic that SQLite can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.

The SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time."

[Mage]

Re: I think you are underestimating the potential security problems

Not at all. That's why I leave maintaining web facing servers to experts.

The point is not that the multiuser server based databases don't have vulnerabilities, but there is a big incentive to patch & secure them. Little Bobby Tables illustrates the more basic issues with inept deployment.

I use SQLite databases on my laptop (and I'd never have deployed Access, I used MSDE in my Windows days for a local database) but I struggle to understand why I'd not use MariaDB or whatever for a server.

[Tim99]

Re: I think you are underestimating the potential security problems

Funnily enough, I have deployed Access as a front-end client to MS SQL Server/MSDE on LANs, it generally worked well.

I am retired now and only fiddle with this stuff - I had some problems with Monty Widenius’ and MySQL going into MariaDB licensing with a product that we developed that was mostly used by not-for-profits and government users; so we normally used licenced MS or open source PostgreSQL and SQLite. It was relatively easy to move from a SQLite DB to Postgres; and not too difficult to move from Access prototypes to MSDE/SQL Server.

[Cem Ayin]

Not sure if I read this right...

So Crome allows arbitrary websites to run arbitrary SQL queries on local SQLight DBs? JavaScript's not bad enough, eh?

Oh, well... as a design study for a novel operating system, Chrome ist certainly "interesting", but it still lacks a decent browser, I must say.

[Lee D]

Re: Not sure if I read this right...

You'd be amazed at the places that use SQLite.

I've seen it everywhere from access control products to website to educational software.

It's usually bulletproof. Because even when you allow people to throw arbitrarily corrupted databases and any SQL query you like at it, if you properly secure it, it's almost invincible.

As stated, even this flaw isn't possible if someone bothers to read https://sqlite.org/security.html and follow its advice.

The question is not "OH MY GOD WE ALLOW PEOPLE TO EXECUTE SQL IN THE BROWSER!" - it's "what security model is it executing that in?". Fact is that running SQL inside the browser is a very popular, useful and desirable feature (just because you see the potential security problems with them , it doesn't mean that the FEATURE to be able to do things isn't desirable).

And SQLite is pretty rock-solid. That's the first ever serious flaw I've ever seen in SQLite ever mentioned. Look at their security page above... do they sound like they are messing around and just slapping things together?

No software is fully bulletproof. But SQLite comes damn close. And is incredibly useful. Why operating systems don't offer centralised database functionality as part of the OS, I never understood. Everything from users to configuration files to program installation manifests should really be a database, meaning something DESIGNED to be query and modified like a database. MSIs and things do contain databases but not in the same format. A generic, OS-wide, database feature (even down to filesystems, remember the WinFS promises?) is something sorely lacking.

Bookmarks in a browser already use such a database (Opera's bookmarks were a plain SQLite file for what? Nearly the last 20 years? Not much software has that kind of testing behind it). You may disagree with the concept of WebSQL but it's not a Chrome-exclusive feature, and if you're implementing it, I'd damn well rather they used SQLite than MySQL or (ARGH!) MS SQL!

Note: I've banged on the SQLite backends with some programs I've written myself. A school full of kids sitting tests in a custom bit of software, each client literally spin-locking a central network SQLite database to add and query their results on the fly. It worked like a damn dream and was rock-solid. I'd rather ditch the entire rest of Chrome and keep SQLite than the alternative, any day.

[Tim99]

Re: Not sure if I read this right...

@Lee D

"Why operating systems don't offer centralised database functionality as part of the OS, I never understood. Everything from users to configuration files to program installation manifests should really be a database, meaning something DESIGNED to be query and modified like a database. MSIs and things do contain databases but not in the same format. A generic, OS-wide, database feature (even down to filesystems, remember the WinFS promises?) is something sorely lacking."

As I recall, the Pick operating system from the 1970s offered something very similar. I spent a bit of time in the 1990s moving small multi-user businesses off Pick onto Windows [The users liked Pick, so not necessarily an improvement :-) - Their managers wanted Windows...].

The AS/400 OS was object-based and relied on a DB2 relational database. Even Netware (from 2.0 upwards?) included a database, but I think it only included file and user attributes; you could extend this with additional business functionality, but I'm not certain that it was used much - A very large public utility where I worked ran a version of XDB ES on top of Netware in the 80s, but I never saw it anywhere else.

[Aladdin Sane]

He's making a database

He's sorting it twice

SELECT * FROM contacts WHERE behaviour = 'nice' ;

SQL clause is coming to town.

[nowster]

There is danger also in that SQLite is the default backing store for Android apps. How many of those apps correctly use parameterized queries rather than folding untrusted external data into SQL statements?

[Mage]

danger also in that SQLite is the default backing store for Android apps

https://xkcd.com/327/

That danger is a separate problem to the vulnerability if you are talking about lack of sanitised input, any user or remote input needs to be properly sanitised. AFTER making sure you can't have buffer overflow.

[Justin Clift]

Bug is in the FTS3 module

As a data point, the bug in question is in the FTS3 module.

If you're using a version of SQLite which doesn't have the FTS3 module, then this bug won't be affecting you.