[SERVER-20362] JS Scopes may leak between synthetic users with '@' in name and database Created: 10/Sep/15  Updated: 13/Feb/20  Resolved: 13/Feb/20

Status: Closed
Project: Core Server
Component/s: JavaScript
Affects Version/s: 3.1.7
Fix Version/s: 4.3.1

Type: Bug Priority: Major - P3
Reporter: Spencer Jackson Assignee: Sara Golemon
Resolution: Done Votes: 0
Labels: spidermonkey
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-20365 "authentication failed, storedKey mis... Closed
related to SERVER-20558 AuthorizationSession::getAuthenticate... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Create two users:
The first shall be named 'x@y' and will exist on 'z'.
The second shall be named 'x' and will exist on 'y@z'.

In window 1:

> use z
switched to db z
> db.createUser({user: "x@y", pwd: "pwd", roles: []})
Successfully added user: { "user" : "x@y", "roles" : [ ] }
> db.auth("x@y", "pwd")
1
> use dbx
switched to db dbx

In window 2:

> use y@z
switched to db y@z
> db.createUser({user: "x", pwd: "pwd", roles: []})
Successfully added user: { "user" : "x", "roles" : [ ] }
> db.auth("x", "pwd")
2015-09-10T17:51:49.902-0400 I ACCESS   [conn1] Successfully authenticated as principal x on y@z
1
> use dbx
switched to db dbx
> db.col.insert({})
WriteResult({ "nInserted" : 1 })
> db.col.find({$where: "globalThing = \"B\"; return true"})

Back in the first window:

db.col.find({$where: "print(globalThing); globalThing = \"A\"; return true"})

Mongod will print "B".

Sprint: Security 15 (06/03/16), Security 2020-02-10, Security 2020-02-24
Participants:

 Description   

The ScopePool identifies the scope it should acquire from its map by creating a key with the following structure:

<db><JSOperation>[\0<user>@<db>]

As '@' is a legal character in both <user> and <db>, it is possible to construct two users so as to cause a collision.



 Comments   
Comment by Sara Golemon [ 13/Feb/20 ]

This was fixed by SERVER-20558 last August.

Comment by Mira Carey [ 15/Sep/15 ]

After a little digging, this actually comes down to the way we make userTokens in AuthorizationSession::getAuthenticatedUserNamesToken.

Basically, we store user@db in the mongo::UserName, along with the index of the split point, but we lose it when building up the authenticated user names token.

This probably needs a lower lying auth ticket to actually get fixed.

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