Nearly everything uses SQLite, including cellphones, other computer languages, and battleships in the navy. There has a long history of the open-source database engine being particularly secure. Because of its extremely lenient license and portable, cross-platform nature, SQLite is the most extensively used database engine. It is built in C and may be converted into a library that exposes APIs for usage by application programmers or a standalone application.
The SQLite library API vulnerability, CVE-2022-35737, is being made public by Trail of Bits experts. Release 3.39.2 of SQLite, which was made available on October 17, 2000, addressed CVE-2022-35737 (released on July 21, 2022).
On 64-bit systems, CVE-2022-35737 is exploitable, and exploitability depends on how the software is compiled. When the library is compiled without stack canaries, arbitrary code execution is confirmed; when stack canaries are present, it is unconfirmed. Denial-of-service is confirmed in all circumstances.
When large string inputs are supplied to the SQLite implementations of the printf methods and when the format string contains the %Q,%q, or %w format replacement types, CVE-2022-35737 can be exploited on susceptible systems. This is sufficient to bring about the program’s failure. Team also demonstrate how, in the worst case scenario, arbitrary code execution or program hang and looping are both conceivable if the format string contains the ! special character to allow unicode character scanning (nearly).
100% of the branch tests have been run on SQLite. This vulnerability was found by experts despite the testing, which begs the issue of how the tests missed it.
The vulnerability cannot be exploited in the SQLite application since it has a 1GB internal memory limit. The idea that SQLite does not handle huge strings, which are essential to exploit this vulnerability, “defines away” the issue. Applications can directly contact the vulnerable routines because the C APIs offered by SQLite do not require that inputs comply to the memory limit. Application developers are unable to enforce input size restrictions on these methods because SQLite does not communicate with the API that huge strings are not permitted. Allocating 1GB strings as input was impossible when this code was initially built since the majority of CPUs only had 32-bit registers and 4GB of accessible memory. Allocating such huge strings is possible and the susceptible circumstances are achievable now that 64-bit computers are widely used.
On July 14, 2022, the Computer Emergency Response Team (CERT) Coordination Center was notified of a vulnerability.
On July 15, 2022, CERT/CC notified the SQLite maintainers of a vulnerability.
The vulnerability was confirmed on July 18, 2022, and the source code was updated.
On July 21, 2022, the developers of SQLite published version 3.39.2 with a patch.
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.