Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A missing corruption check in SQLite’s accessPayload function allows a compromised renderer to overwrite arbitrary cached b-tree pages in the browser process. This is reachable via the IndexedDB SQLite backend during blob write operations. This potential memory corruption can lead to remote code execution in the unsandboxed browser process.

Affected files:

• third_party/sqlite/src/src/btree.c
• content/browser/indexed_db/instance/sqlite/database_connection.cc
• content/browser/indexed_db/instance/sqlite/blob_writer.cc
• sql/streaming_blob_handle.cc
• third_party/sqlite/src/src/vdbeblob.c

Estimated timestamp from git blame: Unknown (Google3 checkout)

Summary

A potential vulnerability exists in SQLite’s B-tree implementation where the accessPayload function, specifically in write mode (eOp=1), fails to perform corruption checks before writing to overflow pages. This lack of validation allows for a scenario where a malicious overflow chain link can alias an existing, initialized b-tree page, leading to its overwrite. In Chromium, this is reachable from a compromised renderer via the IndexedDB SQLite backend, potentially resulting in a sandbox escape.

Root Cause Analysis

The issue resides in third_party/sqlite/src/src/btree.c. When accessPayload() is called with eOp=1 to write data to an overflow chain, it fetches pages using sqlite3PagerGet() but fails to verify their state:

// btree.c:5289
rc = sqlite3PagerGet(pBt->pPager, nextPage, &pDbPage,
    (eOp==0 ? PAGER_GET_READONLY : 0)
);
if( rc==SQLITE_OK ){
  aPayload = sqlite3PagerGetData(pDbPage);
  nextPage = get4byte(aPayload);
  rc = copyPayload(&aPayload[offset+4], pBuf, a, eOp, pDbPage); // eOp==1 triggers write
  sqlite3PagerUnref(pDbPage);
  offset = 0;
}

In contrast, other write paths like btreeOverwriteOverflowCell explicitly check for corruption using the page’s reference count and initialization status (around line 9322):

if( sqlite3PagerPageRefcount(pPage->pDbPage)!=1 || pPage->isInit ){
  rc = SQLITE_CORRUPT_PAGE(pPage);
}

Because accessPayload lacks this guard, it will write caller-supplied bytes into any page identified by nextPage. If a database is corrupted such that an overflow link points to a page currently initialized as a b-tree node by another active cursor, accessPayload will overwrite it without error.

Reachability in Chromium

This path is reachable from a compromised renderer through the IndexedDB SQLite backend (currently active under the IdbSqliteOnDiskRollout field trial):

1. Renderer Activity: A compromised renderer initiates an IndexedDB put() with a large Blob.
2. Mojo Data Stream: The browser process’s BlobWriter (in content/browser/indexed_db/instance/sqlite/blob_writer.cc) receives the data and uses a sql::StreamingBlobHandle to perform the write.
3. SQLite Blob Write: This triggers sqlite3_blob_write(), which invokes sqlite3BtreePutData() and subsequently accessPayload(eOp=1) in the browser process.
4. Aliased Overwrite: If the database file is crafted to alias an overflow page with a metadata page currently pinned by another IndexedDB cursor (on a different table), accessPayload will overwrite that page’s contents while the other cursor still treats it as a valid, trusted b-tree node.

Potential Exploitation Path

An attacker could potentially follow these steps:

1. Compromise a renderer process.
2. Provide or trigger the creation of a corrupted IndexedDB database file where a Blob overflow chain points to a b-tree leaf page of a sensitive table.
3. Open a cursor on the sensitive table to ensure the target page is cached and initialized in the browser process.
4. Write to the malicious Blob via the Mojo BlobWriter interface. This overwrites the cached b-tree page while leaving its MemPage metadata (cell counts, offsets) in a stale but “valid” state.
5. Continue the sensitive cursor operation. SQLite will parse the attacker-controlled data using the stale metadata, leading to heap out-of-bounds primitives or type confusion in the unsandboxed browser process.

Note: These are suggested steps based on source code analysis; a functional proof-of-concept has not been executed.

Suggested Fix

The accessPayload function should be updated to include the same corruption guards as btreeOverwriteOverflowCell. Specifically, when eOp is non-zero, the code should verify that the fetched page is not already initialized (!pPage->isInit) and that its pager reference count is exactly 1.

Evaluated with Chrome root at commit: 1a8d40fc44df2088d5945c0bf53584038aa1614a

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.