Rejected reason: DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

Rejected reason: DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

An integer overflow can be triggered in SQLite’s concatws() function. The resulting, truncated integer is then used to allocate a buffer. When SQLite then writes the resulting string to the buffer, it uses the original, untruncated size and thus a wild Heap Buffer overflow of size ~4GB can be triggered. This can result in arbitrary code execution.

A vulnerability was found in SQLite SQLite3 up to 3.43.0 and classified as critical. This issue affects the function sessionReadRecord of the file ext/session/sqlite3session.c of the component make alltest Handler. The manipulation leads to heap-based buffer overflow. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-248999.

https://sqlite.org/forum/forumpost/5bcbf4571c https://sqlite.org/src/info/0e4e7a05c4204b47 https://vuldb.com/?ctiid.248999 https://vuldb.com/?id.248999

The sqlite3VXPrintf function in printf.c in SQLite before 3.8.9 does not properly handle precision and width values during floating-point conversions, which allows context-dependent attackers to cause a denial of service (integer overflow and stack-based buffer overflow) or possibly have unspecified other impact via large integers in a crafted printf function call in a SELECT statement.

Buffer Overflow vulnerability found in SQLite3 v.3.27.1 and before allows a local attacker to cause a denial of service via a crafted script.

sqlite-vec v0.1.1 was discovered to contain a heap buffer overflow via the npytokennext function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted file.

sqliter was a malicious module published with the intent to hijack environment variables. It has been unpublished by npm.

All, FYI:

DARPA and ARPA-H are running a research competition called the "AI Cyber Challenge" (AIxCC). Its goal is to create automated tools that find and fix vulnerabilities in software. General information is here: <https://aicyberchallenge.com/>

The AIxCC semifinal competition was last week at DEF CON 32 (2024). All competitors were given an identical set of Challenge Projects, which were real-world OSS projects seeded with synthetic vulnerabilities. The projects were Jenkins, Linux kernel, Nginx, SQLite3, and Apache Tika. There were 7 winners; each winner received $2 million US as a reward, and those teams will be allowed to compete in the finals at next year's DEF CON.

An official summary is here: <https://www.darpa.mil/news-events/2024-08-11>. Some other interesting links related to the semifinals include: <https://blog.trailofbits.com/2024/08/09/trail-of-bits-buttercup-heads-to-darpas-aixcc/> <https://www.youtube.com/watch?v=sQKGWZvuLko>

One of the competing teams, Team Atlanta, even found a real-world bug in SQLite3. This was reported to SQLite through their usual process; it's fixed in trunk. More info about that specifically is here: - <https://x.com/TeamAtlanta24/status/1822739301463130271> - <https://sqlite.org/forum/forumpost/81670d1056>

The tools must be released by next year as open source software, with an OSI-approved license, as a condition for accepting prize money or competing in the final competition. Exact text is in the "Open-Source Requirement" section in its rules <https://aicyberchallenge.com/rules/>. The challenge problems were all based on real-world OSS, and the hope is that in the long term such tools can automatically find & fix vulnerabilities in all software including OSS.

Full disclosure: I work for the Open Source Security Foundation (OpenSSF) and I have been working with DARPA & ARPA-H supporting this. That said, I thought others in this mailing list would want to know about it. No research is guaranteed to produce something leading to useful results, but I think this is a promising approach. We definitely could use tools that automatically find & fix vulnerabilities, if they're good enough!!

--- David A. Wheeler

Multiple unspecified vulnerabilities in SQLite before 3.8.10.2, as used in Apple iOS before 9, have unknown impact and attack vectors.

Multiple buffer overflows in the printf functionality in SQLite, as used in Apple iOS before 8.4 and OS X before 10.10.4, allow remote attackers to execute arbitrary code or cause a denial of service (application crash) via unspecified vectors.

SQLite before 3.8.9 does not properly implement the dequoting of collation-sequence names, which allows context-dependent attackers to cause a denial of service (uninitialized memory access and application crash) or possibly have unspecified other impact via a crafted COLLATE clause, as demonstrated by COLLATE"""""""" at the end of a SELECT statement.

The sqlite3VdbeExec function in vdbe.c in SQLite before 3.8.9 does not properly implement comparison operators, which allows context-dependent attackers to cause a denial of service (invalid free operation) or possibly have unspecified other impact via a crafted CHECK clause, as demonstrated by CHECK(0&O>O) in a CREATE TABLE statement.

A code execution vulnerability exists in the Statement Bindings functionality of Ghost Foundation node-sqlite3 5.1.1. A specially-crafted Javascript file can lead to arbitrary code execution. An attacker can provide malicious input to trigger this vulnerability.

In SQLite through 3.29.0, whereLoopAddBtreeIndex in sqlite3.c can crash a browser or other application because of missing validation of a sqlitestat1 sz field, aka a "severe division by zero in the query planner."

References: https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg116312.html https://www.sqlite.org/src/info/e4598ecbdd18bd82945f6029013296690e719a62

SQLite 3.30.1 mishandles certain SELECT statements with a nonexistent VIEW, leading to an application crash.

Reference and upstream commit: https://github.com/sqlite/sqlite/commit/527cbd4a104cb93bf3994b3dd3619a6299a78b13

Multiple flaws were found in sqlite. An attacker who is able to run arbitrary SQL statements could use this flaw to corrupt the internal databases, which can lead to arbitrary code execution as the user running sqlite.

This issue was fixed via sqlite-3.25.3 release at: https://www.sqlite.org/releaselog/3253.html

Also sqlite-3.36 introduced SQLITEDBCONFIGDEFENSIVE option which when added to the config file, could prevent attackers for corrupting the internal database files. This could however break applications which require users to write these database files. https://www.sqlite.org/releaselog/3260.html https://www.sqlite.org/c3ref/cdbconfigdefensive.html#sqlitedbconfigdefensive

exprListAppendList in window.c in SQLite 3.30.1 allows attackers to trigger an invalid pointer dereference because constant integer values in ORDER BY clauses of window definitions are mishandled.

Reference and upstream commit: https://github.com/sqlite/sqlite/commit/75e95e1fcd52d3ec8282edb75ac8cd0814095d54

zipfileUpdate in ext/misc/zipfile.c in SQLite 3.30.1 mishandles a NULL pathname during an update of a ZIP archive.

Upstream Fix:

https://github.com/sqlite/sqlite/commit/54d501092d88c0cf89bec4279951f548fb0b8618

ext/misc/zipfile.c in SQLite 3.30.1 mishandles certain uses of INSERT INTO in situations involving embedded '\0' characters in filenames, leading to a memory-management error that can be detected by (for example) valgrind.

References and upstream commits: https://github.com/sqlite/sqlite/commit/1e490c4ca6b43a9cf8637d695907888349f69bec https://github.com/sqlite/sqlite/commit/d8f2d46cbc9925e034a68aaaf60aad788d9373c1

multiSelect in select.c in SQLite 3.30.1 mishandles certain errors during parsing, as demonstrated by errors from sqlite3WindowRewrite() calls. NOTE: this vulnerability exists because of an incomplete fix for CVE-2019-19880.

Upstream commit:

https://github.com/sqlite/sqlite/commit/8428b3b437569338a9d1e10c4cd8154acbe33089

selectExpander in select.c in SQLite 3.30.1 proceeds with WITH stack unwinding even after a parsing error.

Reference and upstream commit: https://github.com/sqlite/sqlite/commit/a6c1a71cde082e09750465d5675699062922e387

In SQLite 3.31.1, isAuxiliaryVtabOperator allows attackers to trigger a NULL pointer dereference and segmentation fault because of generated column optimizations.

References: https://www.sqlite.org/cgi/src/info/4374860b29383380 https://www.sqlite.org/cgi/src/info/9d0d4ab95dc0c56e https://www.sqlite.org/cgi/src/info/abc473fb8fb99900

SQLite 3.30.1 mishandles certain parser-tree rewriting, related to expr.c, vdbeaux.c, and window.c. This is caused by incorrect sqlite3WindowRewrite() error handling.

Upstream fix:

https://github.com/sqlite/sqlite/commit/8654186b0236d556aa85528c2573ee0b6ab71be3

flattenSubquery in select.c in SQLite 3.30.1 mishandles certain uses of SELECT DISTINCT involving a LEFT JOIN in which the right-hand side is a view. This can cause a NULL pointer dereference (or incorrect results).

Upstream fix:

https://github.com/sqlite/sqlite/commit/396afe6f6aa90a31303c183e11b2b2d4b7956b35