The consequences of a years-old SQLite vulnerability

In October 2022, researchers at Trail of Bits published a detailed breakdown of an SQLite DBMS vulnerability. The article discusses possible attacks via CVE-2022-35737, with consequences ranging from a simple application crash to arbitrary code execution. The rather trivial bug in the SQLite code is interesting and potentially dangerous for two reasons. Firstly, it has been in SQLite since October 2000 –  from almost the very beginning of development of this open source software. Secondly, SQLite’s features make it theoretically possible to attack a wide range of programs with SQLite inside them.

SQLite features

SQLite is a compact, open-source, embedded DBMS – first released 22 years ago (in August 2000). “Embedded” is the key definition here. SQLite is not installed as separate software. Instead, it’s used as a library for software developers who need to work with databases. SQLite is by default built into, for example: the Google Chrome, Firefox and Safari browsers; Android; network applications; and many release packages of operating systems based on the Linux kernel. SQLite gained popularity for its open license, reliability and… security: few serious flaws have actually been found in the DBMS’s code so far.

CVE-2022-35737 details

Experts detected a bug in the sqlite3_snprintf function’s code, which is used to interact with the database in programs written in C/C++. If you pass a very large string input (more than 2GB) to that function, it will cause the program to crash; i.e., a denial of service (DoS) attack becomes possible. In the sqlite3_snprintf code, an integer variable was used to calculate the size of the passed string. If the string passed is too large, the variable can take a negative value. This then causes a memory buffer to be allocated that’s too small to write the received string. A common buffer overflow error occurs.

The error was most likely entered into the code 22 years ago, since passing gigabytes of function parameters was unlikely due to the resource limitations of the day. This is no longer the case. A separate point of interest in the Trail of Bits report is an assumption about why such an error was missed during standard code testing. The testing procedure is primarily aimed at checking newly added or modified code, while the code here hasn’t been changed in more than two decades. It’s quite difficult to detect such vulnerabilities with fuzzing – which is feeding random parameters as function inputs. Common fuzzing methods don’t involve generating strings of such a large size. The authors of the research conclude that fuzzing can’t fully replace static code analysis, including that performed manually.

Foggy implications

Trail of Bits was able to “modernize” the original DoS attack so it could execute arbitrary code by carefully manipulating the content and size of the parameter passed. Although the authors of the paper have showed a working proof-of-concept demonstrating examples of attacks, those are a purely theoretical exercise in attacking SQLite itself. However, as mentioned above, SQLite is an embedded DBMS, so to do real harm someone would need to attack an application with embedded SQLite code.

It turns out that there are quite a lot of assumptions in the research, and the practical possibility of actually exploiting the vulnerability has yet to be proven. There are other limitations. According to data from SQLite developers, the bug is only relevant to the interface for C applications, and only if the code is compiled with certain parameters. The Trail of Bits researchers themselves point to the impossibility of an attack if SQLite was compiled using stack canaries. This is essentially an additional method of buffer-overflow attack protection – preventing the execution of arbitrary code even when the overflow itself is possible.

The vulnerability was closed in SQLite 3.39.2, released in July 2022. However, the patch has had little effect. Software developers using SQLite as part of their own code will most likely have to update their developments and distribute a new software version. Until then, the vulnerability will remain there. And don’t forget that many programs with SQLite inside are no longer supported.

It’s not yet clear how dangerous this vulnerability is – or whether it can be exploited in practice. Judging by the definition from the SQLite developers, the chance of an actual attack is small – but not zero. In the meantime, the bug’s been added to the collection of long-lived defects that could potentially cause headaches for software developers.