SELECT code_execution FROM * USING SQLite: Eggheads lift the lid on DB security hijinks

At the DEF CON hacking conference in Las Vegas on Saturday, infosec gurus from Check Point are scheduled to describe a technique for exploiting SQLite, a database used in applications across every major desktop and mobile operating system, to gain arbitrary code execution. In a technical summary provided to The Register ahead …

[swm]

I don't think this is too serious as you need to be able to access the database file. If you can do that you probably can access lots of other stuff.

I am sure that the SQLite folks will patch this.

[The Mole]

I can see that this potentially can be used as a privilege escalation method. If the process runs with higher rights (and/or the file permissions are owned by a privileged user) it may well be the DB is world writable so other users can store data in it - with the assumption the worst damage they can do is erasing the data. An attacker might therefore have minimal privileges sufficient to attack the DB file but not anything else. If/when another higher privilege user executes the application (or process reloads db etc) then the attacker can escalate.

That said there are almost certainly plenty of other vectors if you have access to files.

[JoeySter]

Either way the pointer dereference should be fixed as that's most likely a bug. It's not just about security but integrity. There are occasional debates about trusting the data you lay down, though I wouldn't want file corruption to cause the application to crash that easily when it's such a write heavy process.

As far as privilege escalation goes, it wont effect a lot of people as basically is someone has access to the file system then you're already in trouble.

File permissions are a simple fix. A lot of such privilege escalations exist with just about anything that uses files, even when there isn't a bug allowing execution of arbitrary code.

[Anonymous Coward]

No. There are good chances a database file could be in a user accessible directory, which doesn't require high privileges to be replaced. Not system-wide databases, maybe, but per user databases could be. Then everything may depend on the privileges the application has.

Anyway, this highlight the inherent risks when too much software start to rely on the same code. Less competition means that once a vulnerability is found, almost everything is affected.

[Anonymous Coward]

But what happens if a privileged user access that database? e.g. system database dumping for backups, or "compress" ( I'm not sure what term sqllite uses) garbage collection?

[Ommerson]

Competitors for SQLite?

I'd be hard pressed to name any.

[Anonymous Coward]

Re: Competitors for SQLite?

I am a SQLite guy myself but there are plenty of competitors. I’ve used Sybase SQL Anywhere in the past, dunno if it still exists. Borland Interbase. Berkeley DB. SQL Server Compact/Express. I’ve heard of Derby but never used it.

Anyway SQLite is obviously the best!

[Anonymous Coward]

Re: Competitors for SQLite?

If you are in a J2EE environment (or whatever it's called these days, I retired a few years ago) Derby is excellent from a capability and deployment perspective. It can do automatic backup and restore from within the program. I have used it to maintain backups of the live database in removable storage and over networks. It makes a nice authentication database for Tomcat. Its file structure is page based and it has proven very robust against corruption. It is also fast. It's like an in-memory DB2, in fact, but with a very small memory footprint (excluding the actual data, of course). By contrast, SQLite is very lacking in features and capability.

However, its level of security if you gain access to the physical box is uncertain, which is why I asked the question below.

[Anonymous Coward]

Re: Competitors for SQLite?

Interbase is still around and there's also Firebird, the open source fork. There's an embedded version too.

SQL Anywhere still exist.

Anyway we've seen an increasing trend towards a monoculture where everybody uses the same pieces of software just because others do too. Then less incentives to improve, and fix bugs. And once one is discovered, too much software is suddenly vulnerable.

[c1ue]

Even if that is true (that SQlite people fix this quickly, which seems unlikely since the CVE on this is 5 years old), there will still be the problem of all of the SQlite installs patching/upgrading.

See: Apache Struts/Equifax for how well this works...

[unimaginative]

Which CVE is five years old? The four year old one was patched after a few months. The others are all recent.

This should not require manual patching or upgrading as in most cases (at least on *nix) all you need to is run routine updates and the shared library will get updated.

[Sloppy Crapmonster]

I, too, refuse to read the article or look into it myself.

[Anonymous Coward]

I wouldn't assume this isn't serious

Just because this particular exploit requires direct filesystem access, that doesn't mean this in combination with a separate exploit that let you feed data formatted in a certain way (remember little Bobby Tables) into the database couldn't allow you to take advantage of it without filesystem access.

Those Bobby Tables type exploits are probably easy to overlook if you have - or more to the point think you have - controlled/sanitized input to a database. I mean, why waste time fixing stuff like that when there are real bugs to fix? They don't become a problem until a second exploit like this new one comes along to weaponize it.

I'll bet it turns out this causes problems even where filesystem access is not possible.

[JoeySter]

Re: I wouldn't assume this isn't serious

Whether it's serious or not varies. For a lot of people it wont be. For those on shared platforms, it might be.

On a single platform, where multiple services are in play, you have to be careful of just how many security boundaries you put up.

You don't want a fend around everything, then another fence around each thing, then another fence around each thing with in that, etc. You sort of end up with a house looking like an onion and with thousands of tiny rooms and doors for each thing.

Containment can be too granular and in most systems, ultimately, everything has to be able to talk with everything else so it's hard top entirely prevent someone fully propagating the system.

[Anonymous Coward]

What about browsers?

Chrome, Firefox and I believe Safari all use SQLite, but obviously don't permit filesystem access where the db is stored. But couple it with an exploit that allows filesystem access via the browser (we've seen a few of those over the years) or one that lets you store unconstrained data in the db, and this bug could be leveraged for full code execution in the browser as the user running it.

That's going to be a problem for the owner of a smartphone, and if you couple it with privilege escalation exploit, something we see regularly on smartphones, then you have a way to completely p0wn a smartphone if you can get them to surf to your web page. Not quite enough to get $1 million from Apple (requires no user interaction so you'd need yet another exploit where you could e.g. send them a link via iMessage and cause the phone to open it without the user doing anything) but it would be worrying nonetheless.

Rather than hackers taking over popular sites and defacing them, they could leave the site alone and have it p0wn phones. That would take the site owners longer to notice and correct, since defacement is pretty obvious.

Now granted what I'm talking about here depends on several other exploits since this SQLite exploit by itself doesn't do all that much, but chain exploits are what we really need to worry about especially for smartphones. Something like that will be the first widespread attack on smartphones that changes perceptions, like I.LOVE.YOU was for Windows. Maybe a month from now, maybe a year from now, maybe five years now, but someday hundreds of millions of people will have their phones p0wned within days of each other.

[Tom 7]

Mmmmmm

given that most access to SQLite is through code via a lot of different libraries I'm guessing pretty much all the stuff is vulnerable, A quick glance at Python3 suggests the code for the library hasn't been updated for 5 years.

[unimaginative]

Re: Mmmmmm

It does not matter if the Python library code has not been updates, as long as it is linked to an updated version of the sqlite library.

On most Linux distros packages (like Python) using SQLite will just depend on the OS sqlite library and that will be updated. This is why I far prefer the traditional Linux way of specifying package dependencies to statically compiling them it. One update fixes a shared library everywhere it is used.

For MacOS it comes with the OS, so should get fixed by an OS update. Not always true on MacOS because a lot of stuff is statically linked into apps, but in this case it should be fine (unless apps statically link a different version or similar).

That leaves Android (lots of people do not get OS updates) and Windows (likely to be statically linked) as the potential problems.

[Tom 7]

Re: Mmmmmm

But if SQLite has been updated and the library hasn't then surely the code is linked to the older version?

Not got into Python details properly - too many versions to know where to start.

[Anonymous Coward]

Apache Derby

Derby allows you to store Java classes in your database. Has anyone looked into that?

[Anonymous Coward]

Re: Apache Derby

No. Why?

1) Store classes? Objects surely.

2) Why would you store objects in a relational database rather than something more appropriate?

3) Nearly all Apache projects are over engineered / complicated for the average use case.

4) Java sucks. (partially due to 3 being a disease that infects Java developers)

[Anonymous Coward]

Re: Apache Derby

Well, IIRC it allows you to store classes and the use them to retrieve instances of them as objects. I'm sorry if I got that wrong. However, I wondered if anyone had looked into that as a security vulnerability.

I haven't used nearly all Apache projects so I can't comment on (3) but Tomcat is something I have used a lot and seems neither over engineered nor too complicated and other Apache projects I've used have done the job without stress. Hibernate now...

As for 4, we'll just have to disagree. Along with a number of large companies.

[Anonymous Coward]

Re: Apache Derby

Because Java. That’s what being exposed to Java does to people

[Thomas_Kent]

This reminds me of that xkcd classic: https://xkcd.com/327/

[Solarflare]

This doesn't remind me of Bobby Tables in any way, personally...

[Anonymous Coward]

SQLite usage

While other commentators are pointing out how varied the usage of SQLite is, they're missing the point regarding vulnerabilities - the vast majority of exploitable installs will be via browsers as it is used across Chrome/Edge/Firefox/Opera. BUT the browser sandboxes are designed to protect against direct file access so the scope is likely to be limited AND deploying fixes is likely to be relatively easy using existing browser update processes.

For non-browser installations, outside of IoT applications, I suspect the vulnerabilities are unlikely to be widely exploitable because of the variability of how SQLite access is deployed. Yes it needs patched, no it probably won't be before the application is retired...