MongoDB is known for its reliability and ease of use, but sometimes even the best software can have critical issues. One such recent vulnerability is CVE-2024-8305, which impacts several versions of MongoDB in a pretty scary way: it can cause your secondary nodes to crash, break data consistency, and potentially leave your whole replica set without any primary available. This long read will explain what CVE-2024-8305 is, how it works, and what you can do about it.

What Exactly Is CVE-2024-8305?

CVE-2024-8305 is a vulnerability discovered in MongoDB's unique index creation logic, specifically in the prepareUnique index step. The root cause is that secondaries can incorrectly enforce unique index constraints during replication, leading to crashes. In the worst case, if multiple secondaries crash, there might be no node able to take over as primary, causing a service outage.

Unique Index Background

In MongoDB, a unique index forces all values of the indexed field to be different across documents. Normally, MongoDB ensures this rule only allows unique values.

Secondary Node Index Enforcement

When secondaries replicate from the primary, they must apply changes and enforce the same constraints—like unique indexes—as the primary. There is a prepareUnique phase when secondaries try to enforce the new unique index constraint.

The Bug

In vulnerable versions, secondaries sometimes incorrectly enforce these constraints. If the data already violates the unique index rule (for example, due to in-flight changes or oplog differences), the secondary will crash instead of handling the situation gracefully.

Imagine you have duplicate keys in a collection, and you try to create a unique index via the primary. The primary might succeed, but secondaries, during replication, could hit the duplicated data and crash.

If enough secondaries crash, there's a risk there won't be a majority in your replica set, and thus no primary can be elected—a scary prospect for high-availability databases.

Code Example: Reproducing the Crash

Below is a simplified way to illustrate this kind of failure. (Please do not run in production!)

// Step 1: Connect to your MongoDB replica set.

// Step 2: Insert duplicate documents
db.testCollection.insertMany([
  { _id: 1, email: "user@example.com" },
  { _id: 2, email: "user@example.com" }  // duplicate email
]);

// Step 3: On primary, try to create a unique index
db.testCollection.createIndex({ email: 1 }, { unique: true });

If secondary nodes receive this operation via oplog and already have duplicate emails, they could crash while trying to apply the unique index constraint, thanks to CVE-2024-8305.

Exploit Details

While this issue is more about crashing secondaries rather than leaking or directly corrupting data, attackers could exploit it to cause denial of service:

- Targeted DoS: An attacker with write access could inject duplicate data and force a unique index creation. When the primary replicates the index setup to secondaries, those with duplicates may crash.
- Replica Set Instability: Given enough disruption, the cluster could lose quorum, and no new primary would be elected, causing a full outage.

The crash log may show errors similar to

W STORAGE  [repl writer worker theReplicationBatchGroup] handleDuplicateKey error
F -        [repl writer worker theReplicationBatchGroup] Got an unexpected duplicate key error while applying oplog entry

MongoDB has acknowledged and patched this issue. Here are some resources

- MongoDB Security Advisory for CVE-2024-8305
- NVD Entry for CVE-2024-8305
- MongoDB Jira Ticket *(may require account)*

{ $match: { count: { $gt: 1 } } }

])

Summary

CVE-2024-8305 is a reminder that even replication logic requires careful handling of edge cases. MongoDB’s unique index logic on secondaries had a bug that could take down your replica set if triggered, potentially leading to service-wide outages. The best defense is to upgrade MongoDB to a safe version and to always test for duplicate keys before making fields unique.

For more in-depth details, check official resources, keep your systems patched, and audit your databases regularly.

Timeline

Published on: 10/21/2024 15:15:04 UTC
Last modified on: 11/07/2024 15:38:32 UTC