-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication, Security
-
Major Change
-
v4.4, v4.2, v4.0
-
Repl 2021-03-08, Repl 2021-03-22
CVE-2021-20330
Title
Specific replication command with malformed oplog entries can crash secondaries
CVE ID
CVE-2021-20330
Description
An attacker with basic CRUD permissions on a replicated collection can run the applyOps command with specially malformed oplog entries, resulting in a potential denial of service on secondaries.
This issue affects MongoDB Server v4.0 versions prior to 4.0.27; MongoDB Server v4.2 versions prior to 4.2.16; MongoDB Server v4.4 versions prior to 4.4.9.
CVSS score
This issue's CVSS:3.1 severity is scored at 6.5 using the following scoring metrics:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Affected versions
MongoDB Server v4.0 versions prior to 4.0.27;
MongoDB Server v4.2 versions prior to 4.2.16;
MongoDB Server v4.4 versions prior to 4.4.9.
CWE
CWE-20 Improper Input Validation
Underlying operating systems affected
ALL
As of SERVER-25994, a user can run applyOps if they have the privileges to perform each individual operation specified in the the applyOps command. However, applyOps is more powerful than other commands in that it avoids certain input validation (see SERVER-27096, SERVER-32941, SERVER-32952, and SERVER-32305). This is done intentionally, since applyOps is supposed to behave similarly to oplog application, where the primary does all validation and the secondary applies the changes exactly as the primary specified without validation. This feature is important to products that mimic oplog application, such as mongomirror and mongorestore. However, users should not be able to bypass validation simply because they have permission to write to a collection. Instead, applyOps should require a special privilege for bypassing validation.
We will create a new privilege bypassing system-level invariants in applyOps. Today, this privilege will be required in order to run applyOps at all, since we have not implemented a version of applyOps that performs validation. The privilege will be included in dbAdminAnyDatabase, which is included in the custom role atlasAdmin and the temporary user that we create for Live Imports (mongomirror).
- is related to
-
SERVER-32952 applyOps does not validate updates
- Backlog
-
SERVER-33326 Remove use of applyOps/doTxn from sharding chunk operations
- Closed
-
SERVER-25994 Allow applyOps to validate authorization permissions at the operation level
- Closed
- related to
-
SERVER-50381 3 way deadlock between applyOps cmd, prepared transaction and secondary oplog fetcher initiated find command
- Closed
-
SERVER-53674 Do not run applyOps commands in the fuzzer
- Closed
-
SERVER-58247 Using createIndexes in applyOps with the oplog application mode set on primary should uassert, not fassert
- Closed
-
SERVER-66651 Role "restore" not sufficient for `mongorestore --preserveUUID`
- Closed