Overview:
SQLite is one of the world’s most popular database engines used in servers, browsers, mobile apps, and even smart devices. In December 2023, security researchers found a critical heap-based buffer overflow vulnerability (CVE-2023-7104) in versions of SQLite3 up to 3.43., specifically in the way the sessionReadRecord function of sqlite3session.c handles input. That means attackers may exploit it to crash your app or possibly run rogue code.

Let’s dive into how this bug works, how you can identify vulnerable code, a sample exploit, and what you should do to stay safe—written for both newcomers and tech pros.

Bug: Heap-based Buffer Overflow

- Component: sessionReadRecord in ext/session/sqlite3session.c

Where’s the Bug?

The problem is in the function sessionReadRecord, used when SQLite is handling “session” related commands (think: tracking changes so you can sync or replicate databases). If someone crafts a specially constructed database blob, they can trick this function into writing past the allowed memory.

Here’s a simplified version (non-patched)

// sqlite3session.c (abbreviated for clarity)
static int sessionReadRecord(SessionInput *pIn, u8 *aBuf, int nBuf){
    // ...
    int nByte = get_varint(pIn);    // Reads size from data
    if (nByte > nBuf) {
        return SQLITE_CORRUPT_BKPT;
    }
    memcpy(aBuf, pIn->aData, nByte);   // <== Can overflow if nByte is too big
    // ...
}

The issue is if nByte (controlled by user data) gets larger than nBuf but isn't caught, memcpy will scribble data where it shouldn't. This can corrupt the heap, crash the system, or be used to run attacker’s code.

How can it be Exploited?

An attacker needs to provide a malicious session record — for example, feeding SQLite with a crafted replication or “all test” blob. In a server, app, integration, or test pipeline that accepts external database changes, this is dangerous.

Example Exploit (Python)

Here's a *conceptual* demo using Python, which could be used to trigger the fault (don't run on production):

import sqlite3

# Open or create a SQLite DB
conn = sqlite3.connect(':memory:')
cur = conn.cursor()

# Try to enable session extension (only available with extensions loaded)
conn.enable_load_extension(True)
conn.load_extension("libsqlite3session")  # May need correct path

# Now, inject a crafted session record (payload based on reverse-engineering)
# WARNING: This is a sample trigger, not a real exploit!
# Actual payloads could be generated using fuzzers or by manually crafting corrupted session files

malicious_blob = b'\xFD' * 500  # Overlarge blob for demonstration

try:
    # You'd normally use session APIs, but for demo:
    cur.execute("SELECT sqlite3session_changeset_apply(?, 'main')", (malicious_blob,))
except Exception as e:
    print("[!] Potential Crash or Overflow Triggered:", e)
finally:
    conn.close()

Note: The real-world version would require understanding the session format (sqlite3session) but this is the style of attack: Blobs that break expected size checks.

Upgrade Immediately:

Download the latest patch

Official CVE Record:

CVE-2023-7104 at NVD

SQLite Updates:

SQLite Release Notes

VDB-248999:

VulDB Entry

Original Disclosure:

oss-sec mailing list post

Patch (diff):

GitHub SQLite3 diff

Summary

- CVE-2023-7104 lets attackers overwrite heap memory in SQLite 3.43. and below if “session” features are used.
- Risk level is critical — patch ASAP if you use session/replication.

Stay safe, stay patched!

*Did this guide help? Spread the word and keep your stack secure. If you have further questions, head directly to the SQLite team or check CVE advisories for more updates.*

Timeline

Published on: 12/29/2023 10:15:13 UTC
Last modified on: 01/12/2024 14:15:49 UTC