New technique for exploiting vulnerabilities in SQLite introduced

Researchers at Check Point uncovered at the DEF CON conference, details of a new technique for attacking applications using vulnerable versions of SQLite. The Check Point method considers database files as an opportunity for integrating vulnerability exploitation scenarios in various internal SQLite subsystems that are not available for exploitation on the forehead. Researchers have also prepared a technique for exploiting vulnerabilities with exploit coding in the form of a chain of SELECT queries in a SQLite database, which allows bypassing ASLR.

For a successful attack, it is necessary to be able to modify the database files of the attacked applications, which limits the method to an attack on applications that use the SQLite database as a format for transit and input data. The method can also be used to extend the local access already gained, for example, to integrate hidden backdoors into used applications, as well as to bypass protection mechanisms by security researchers when analyzing malware. Operation after the file substitution is carried out at the moment the application executes the first SELECT query to the table in the modified database.

As an example, the ability to run a code in iOS when opening an address book, the file from the database "AddressBook.sqlitedb" was changed using the proposed method, was demonstrated. The attack used a vulnerability in the fts3_tokenizer function (CVE-2019-8602, pointer dereference capability), fixed in the April update of SQLite 2.28, along with another vulnerability in the implementation of window functions. In addition, the application of a method for remotely seizing control over an attackers' backend server written in PHP, which accumulates passwords intercepted during the operation of malicious code (the intercepted passwords were transmitted in the form of a SQLite database), was demonstrated.

The attack method is based on the use of two techniques "Query Hijacking" and "Query Oriented Programming", which allow exploiting arbitrary problems that lead to memory corruption in the SQLite engine. The essence of "Query Hijacking" is to replace the contents of the "sql" field in the sqlite_master service table, which determines the database structure. The specified field contains the DDL (Data Definition Language) block used to describe the structure of objects in the database. The description is specified using standard SQL syntax, i.e. the "CREATE TABLE" construct is used,
which is executed during the initialization of the database (during the first run
sqlite3LocateTable function) to create table-related internal structures in memory.

The idea is that, as a result of replacing "CREATE TABLE" with "CREATE VIEW", it becomes possible to control any access to the database through the definition of its view. Using "CREATE VIEW" the "SELECT" operation is attached to the table, which will be called instead of "CREATE TABLE" and allows you to access various parts of the SQLite interpreter. Further, the easiest way to attack would be to call the "load_extension" function, which allows you to load an arbitrary library with an extension, but this function is disabled by default.

To carry out an attack in the conditions of the possibility of performing the SELECT operation, the Query Oriented Programming technique is proposed, which makes it possible to exploit problems in SQLite that lead to memory corruption. The technique is reminiscent of return-oriented programming (ROP, Return-Oriented Programming), but uses not existing fragments of machine code to build a chain of calls (β€œgadgets”), but inserts in a set of subqueries inside SELECT.

New technique for exploiting vulnerabilities in SQLite introduced

New technique for exploiting vulnerabilities in SQLite introduced

Source: opennet.ru

Add a comment