[SERVER-36955] applyOps accepts invalid UUIDs for the create command Created: 31/Aug/18  Updated: 27/Oct/23  Resolved: 10/Oct/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: David Bradford (Inactive) Assignee: Tess Avitabile (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-32952 applyOps does not validate updates Backlog
Operating System: ALL
Sprint: Repl 2018-09-24, Repl 2018-10-08, Repl 2018-10-22
Participants:
Linked BF Score: 2

 Description   

The fuzzer generated the following applyOps entry, which ended up corrupting the system.version collection (newUUID was undefined):

{
        op: 'c',
        ns: 'admin.$cmd',
        ui: newUUID,
        o: { create: 'system.version' }
} 

There could be more validation in applyOps to ensure that the value 'ui' is correct.



 Comments   
Comment by David Bradford (Inactive) [ 10/Oct/18 ]

Closing. The problem the fuzzer hit here has to do with running applyOps in a situation that should never occur in the server.

Comment by David Bradford (Inactive) [ 10/Oct/18 ]

Sorry, I've been out. Taking a closer look now.

I think I looked at something backwards. The problem was that the UUID had a value, but the FCV was at 3.4. tess.avitabile It looks like you have already commented on BF-10067 that this is working as designed and that the fuzzer should be updated to avoid these type of commands on 3.6.

Comment by Tess Avitabile (Inactive) [ 10/Oct/18 ]

david.bradford, have you had a chance to look at this?

Comment by Tess Avitabile (Inactive) [ 03/Oct/18 ]

david.bradford, I am not observing this issue. It looks like the applyOps command does validate the type of the UUID:

> db.runCommand({applyOps: [{op: "c", ns: "test.$cmd", o: {create: "c"}, ui: undefined}]})
{
	"applied" : 1,
	"code" : 207,
	"codeName" : "InvalidUUID",
	"errmsg" : "uuid must be a 16-byte binary field with UUID (4) subtype",
	"results" : [
		false
	],
	"ok" : 0
}
> db.runCommand({applyOps: [{op: "c", ns: "test.$cmd", o: {create: "c"}, ui: null}]})
{
	"applied" : 1,
	"code" : 207,
	"codeName" : "InvalidUUID",
	"errmsg" : "uuid must be a 16-byte binary field with UUID (4) subtype",
	"results" : [
		false
	],
	"ok" : 0
}
> db.runCommand({applyOps: [{op: "c", ns: "test.$cmd", o: {create: "c"}, ui: 1}]})
{
	"applied" : 1,
	"code" : 207,
	"codeName" : "InvalidUUID",
	"errmsg" : "uuid must be a 16-byte binary field with UUID (4) subtype",
	"results" : [
		false
	],
	"ok" : 0
}
> db.runCommand({applyOps: [{op: "c", ns: "test.$cmd", o: {create: "c"}, ui: "bad"}]})
{
	"applied" : 1,
	"code" : 207,
	"codeName" : "InvalidUUID",
	"errmsg" : "uuid must be a 16-byte binary field with UUID (4) subtype",
	"results" : [
		false
	],
	"ok" : 0
}

Am I missing something in how I should try to reproduce this?

Comment by Tess Avitabile (Inactive) [ 04/Sep/18 ]

Please investigate what happens if you create a collection with an invalid UUID, and also whether any actions are being taken to prevent the fuzzer from doing this or if they are relying on this fix.

Generated at Thu Feb 08 04:44:34 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.