The maintainers of the SQLite database engine have patched a high severity vulnerability that attackers could exploit to crash or control programs that rely on the software.
Developers of the software have offered The Daily Swig a convincing argument that the flaw would be difficult to exploit in practice. Even so, they have revised the software with a patch to defend against the flaw – rather than dismissing the issue as something that can be safely ignored.
SQLite is a popular open source C-language library that underpins many enterprise apps and services. Notable users of SQLite include Apple, Adobe, Google, Facebook, and Microsoft. There are billions of copies of SQLite deployed worldwide.
The SQLite team is quick to fix emerging vulnerabilities in the software due to their potentially wide-reaching impact. However, a vulnerability disclosed this month by Trail of Bits was introduced 22 years ago and highlighted how initially secure functionality could have unintended consequences much further down the line.
In a blog post dated October 25, Trail of Bits researcher Andreas Kellas said the vulnerability was introduced in SQLite version 1.0.12, a 2000 release that landed when the software was primarily based on 32-bit architectures. According to Kellas, the bug “may not have seemed like an error” at the time.
The high severity vulnerability is tracked as CVE-2022-35737, scoring a CVSS severity score of 7.5.
Trail of Bits said the bug impacts any app that relies on the SQLite library API.
The vulnerability is exploitable on 64-bit systems when large string inputs contain %Q, %q, or %w format substitution types that – in this scenario – might cause programs to crash or worse.
In the most severe cases – when the ! special character exists in the format string – it may be “possible to achieve arbitrary code execution, in the worst case, or to cause the program to hang and loop (nearly) indefinitely,” according to the researchers.
Root cause analysis
Speaking to The Daily Swig, the creator of SQLite, D. Richard Hipp, said the root cause of the problem was the use of signed 32-bit integers as a byte index into the input string and to compute the size of the output string. When an input string was large enough, the integer would overflow, and “all kinds of problems” ensued.
However, the potential impact of the flaw appears to be limited.
Hipp told us that it is not possible to reach the vulnerability for malicious purposes via SQL inputs or by passing SQLite a malformed database file. Instead, an attacker would have to abuse the use the sqlite3_mprintf() function – or “similar C-level interfaces with a format string that includes one of the non-standard [;…] conversion symbols, and then pass in a string that is over 2GB in size”.
The software developer added:
“Lots of applications use SQLite, but only a small percentage of those use the sqlite3_mprintf() API, and an even smaller percentage make use of %Q, %q, or %w. Of those that do, most do not provide a way for an attacker to arrange for a 2GB+ string to be passed into the argument to %Q, %q, or %w.”
Unearthing Fossil
In addition, while the project uses the Fossil control system and this software uses printf, the team couldn’t find a way to inject a 2GB string.
CVE-2022-35737 was reported to the Computer Emergency Response Team (CERT) Coordination Center by Trail of Bits on July 14. CERT confirmed the issue, reached out to SQLite maintainers, and the team fixed the bug in the software’s source code only three days later – a task accomplished by converting to the use of 64-bit integers.
The patched SQLite version, v3.39.2, was released on July 21.
“We are grateful for the responsible disclosure from the researchers who found it,” Hipp said. “It doesn’t hurt to upgrade to a newer release of SQLite. But very few if any real-world applications should be affected by this.”
The Daily Swig has reached out to Trail of Bits with additional queries and we will update this story as and when we hear back.
Source: https://portswigger.net/daily-swig/sqlite-patches-22-year-old-code-execution-denial-of-service-vulnerability
