SELECT code_execution FROM * USING SQLite: Eggheads lift the lid on DB security hi-jinks

DEF CON 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.

SQLite is built into all sorts of things, from web browsers to embedded devices to Android, Windows, iOS, various BSDs, and commercial software. An exploitable security hole found in SQLite would therefore be rather bad news because it could open up lots of stuff to potential attack.

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.

Inside the hack

SQLite databases include a master table that describes the database and its objects. One of the fields in the master table is the Data Definition Language, or DDL, that defines the structure of the SQLite database. And because these DDL statements exist as text in a database file, they can be easily replaced if the file is accessible.

Master table DDL statements, Gull explains in the paper, have to begin with the CREATE command. With that limitation in mind, the researchers found that they could change the CREATE command to a CREATE VIEW command and hijack any future queries. CREATE VIEW, essentially, can be used to trap an app’s legit queries and inject extra commands into them.

With the ability to patch the DDL and have it fire off extra subqueries, there’s the opportunity to interact with vulnerable code within SQLite. In other words, it is possible to alter an SQLite database file so that when it is accessed by an application or operating system, the SQL queries the software wanted to run are intercepted, due to CREATE VIEW, and instead, arbitrary queries that exploit holes within SQLite can trigger instead.

Seeing as SQLite is loaded as a library, or statically built in, once you have code execution in SQLite, you can hijack the running program or operating system component.

Demonstration

Gull and Herscovici chose to focus on Web SQL, an abandoned web API for interacting with client-side databases via a variant of SQL and JavaScript that can still be found in browsers. To demonstrate code execution, they turned to a still-unfixed four-year-old bug, CVE-2015-7036, an untrusted pointer dereference, in SQLite that can be achieved by abusing the fts3_tokenizer() function. Basically, they found it was possible to abuse this function from a hijacked SQL query to defeat ASLR, and hijack the CPU to make it execute arbitrary code.

In another demonstration of the potential of their approach, Gull describes how they replaced the iOS Contacts database, “AddressBook.sqlitedb,” with a malicious version that crashes. Another version could be crafted to potentially achieve code execution within the applications querying the address book, if you’re able to to replace the address book SQLite file.

“Contacts, Facetime, Springboard, WhatsApp, Telegram and XPCProxy are just some of the processes querying it,” Gull explains in his paper. “Some of these processes are more privileged than others. Once we proved that we can execute code in the context of the querying process, this technique also allows us to expand and elevate our privileges.”

The findings, he said, were responsibly disclosed to Apple, which were assigned CVEs (CVE-2019-8600, CVE-2019-8598, CVE-2019-8602, and CVE-2019-8577) and patched in May to close the holes. The SQLite team also patched its software in April. App developers should ensure they push a build of their software that includes the updated database code to users in order to protect them.

“Given the fact that SQLite is practically built-in to almost any platform, we think that we’ve barely scratched the tip of the iceberg when it comes to its exploitation potential,” Gull concludes. ®

Sponsored: Balancing consumerization and corporate control

READ MORE HERE