Submitted via IRC for AnonymousCoward
SELECT code_execution FROM * USING SQLite: Eggheads lift the lid on DB security hi-jinks
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 of their presentation, Check Point's Omer Gull sets out how he and his colleague Omri Herscovici developed techniques referred to as Query Hijacking and Query Oriented Programming, in order to execute malicious code on a system. Query Oriented Programming is similar in a way to return oriented programming in that it relies on assembling malicious code from blocks of CPU instructions in a program's RAM. The difference is that QOP is done with SQL queries.
[...] It must be stressed, though, that to pull off Check Point's techniques to hack a given application via SQLite, you need file-system access permissions to alter that app's SQLite database file, and that isn't always possible. If you can change a program's database file, you can probably get, or already have achieved, code execution on the system by some other means anyway.
Nonetheless, it's a fascinating look into modern methods of code exploitation, and a neat set of discoveries.
Related Stories
Distributed computing researcher, Murat Demirbas, has written a blog post about what he sees as the past, present, and future of SQLite.
This paper, which appeared in VLDB'22 a couple weeks ago, delves into analytical data processing on SQLite, identifying key bottlenecks and implementing suitable solutions. As a result of the optimizations implemented, SQLite is now up to 4.2X faster on the Star Schema Benchmark (SSB). This is a sweet little paper (befitting SQLite's fame). It is technically easy to read yet very fulfilling.
The paper also has an important theme. Throughout the paper, we see time and again how SQLite benefits from its informative profiling utilities and aggressive testing to identify and implement optimizations quickly. Performance and correctness monitoring is a prime factor in development velocity. The ease of profiling SQLite's execution engine enabled the team to pinpoint which virtual instructions were responsible for the bottlenecks, and also to watchout for performance regression issues. Their extensive test suite (consisting of fuzz, boundary value, regression, I/O, out-of mem testing) allowed them to quickly integrate the optimizations into a release build without worrying of breaking other components of the library.
SQLite is a widely used, single-node, online transaction processing (OLTP) database useful in many situations where SQL is relevant yet Postgresql or MariaDB are too heavy.
Previously:
(2019) SELECT Code_execution FROM * USING SQLite: Eggheads Lift the Lid on DB Security Hi-jinks
(2019) Remote Code Execution Vulnerability Impacts SQLite
(Score: 0) by Anonymous Coward on Monday August 12 2019, @03:22PM
That vulnerability is just a reminder that a SQLite file contains not only the data but it's definition and that those definition can contain executable statements (triggers and store procedures ) and that if you are using a publicly writable SQLite file assume that the process reading that file is controllable by anyone.
(Score: 2) by ikanreed on Monday August 12 2019, @03:42PM (2 children)
But there can't be any production applications that use sqllite for anything important. No developer is that stupid. Not even the ones who replaced the start menu with whatever it is Windows 10 has.
(Score: 0) by Anonymous Coward on Monday August 12 2019, @06:22PM
The browser and OS you posted that with probably uses SQLite. SQLite is probably the single, most widely deployed piece of software on the planet.
(Score: 2) by driverless on Tuesday August 13 2019, @03:39AM
It's also a great example of an airtight hatchway problem [microsoft.com], someone who can essentially add an interception proxy to SQLite can hack SQLite. It's a neat party trick, but not an actual security problem.
(Score: 3, Interesting) by rigrig on Monday August 12 2019, @04:03PM (2 children)
Instead of changing database files, I'm sure there are a bunch of applications that use a SQLite database as their file format, and are happy to open email attachments for you...
No one remembers the singer.
(Score: 1, Informative) by Anonymous Coward on Monday August 12 2019, @08:48PM (1 child)
Well, here is a short list of projects, that I know of, that use SQLite as their file format:
Apple, almost everywhere
Firefox, browser
Thunderbird, mail client
Lightroom, image editing software
Adobe AIR, Flash as local apps
Dropbox, file sync utility
Evernote, note and file sync
Skype, communication software
QuickBooks, accounting software
TurboTax, tax software
rpm, the RPM package manager
(Score: 0) by Anonymous Coward on Tuesday August 13 2019, @01:55AM
KODI
(Score: 0) by Anonymous Coward on Tuesday August 13 2019, @06:26AM (1 child)
Hmmm... there are a few things out of place here:
1) SQLite databases shouldn't be shared beween applications, it seems that developers are actually doing this. SQLite can't be blamed for being misused.
2) SQLite database file permissions should restrict only to readonly access or write access only to the user/program that owns the database file. OSes have file permissions for a reason, seems like someone doesn't care for them. If you open something globally accessable you should validate your input, before using it. Again, wrong permissions are a bug, not a feature.
that having said:
3) How does this work with in-memory databases? If it doesn't work with in-memory databases, it proves my points above.
(Score: 0) by Anonymous Coward on Tuesday August 13 2019, @07:46AM
You can share SQLite files between instances of different applications just fine. In fact, it is the preferred format for archiving databases and other relational data. In addition, it has widespread usage as various application file formats as an alternative to rolling your own or using a zip file full of other files. Not to mention both use cases are explicitly mentioned and supported in the official documentation.
Second, there are plenty of abuses that this can be leveraged to use in a single process. The most obvious being persistence across reboots, poisoning forked workers, or evading cleaning attempts. And that doesn't get into what the same user can do on many systems. Additionally, you really only need to get ACE in one process, as long as it is the right one.
Third, you could also use this to poison :memory: databases too. The barrier is much higher, but it is worth noting that not all of the methods require direct memory manipulation of the victim.