[SERVER-49165] endSessions command in Client.Disconnect causes an authorization failure for an unauthed connection on a host that requires authentication Created: 21/May/20 Updated: 08/Jan/24 Resolved: 25/Aug/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0, 4.4.2, 4.2.11, 4.0.22 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Julia Ruddy (Inactive) | Assignee: | Sara Golemon |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||
| Backport Requested: |
v4.4, v4.2, v4.0
|
||||||||||||||||
| Sprint: | Security 2020-08-10, Security 2020-08-24, Security 2020-09-07 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| Description |
|
Given an unauthed connection to a host that requires authentication, these connections still need to be closed, but when client.disconnect is called on those, disconnect runs the endSession which results in an authorization failure. Although this failure is not logged explicitly, it can still show up in the audit logs. It seems this would require a change to the sessions specification (https://github.com/mongodb/specifications/blob/master/source/sessions/driver-sessions.rst#endsession). This issue arose in the monitoring module in the mongodb agent because it creates both the unauthed and authed client connections for all new hosts, independent of if the host requires authentication. These failures are showing up in the audit logs and can be concerning for customers from a security perspective. |
| Comments |
| Comment by Githook User [ 23/Oct/20 ] |
|
Author: {'name': 'Sara Golemon', 'email': 'sara.golemon@mongodb.com', 'username': 'sgolemon'}Message: (cherry picked from commit 680eb5a61bc123d021a75b5ec5a997409ec0d36d) |
| Comment by Githook User [ 23/Oct/20 ] |
|
Author: {'name': 'Sara Golemon', 'email': 'sara.golemon@mongodb.com', 'username': 'sgolemon'}Message: (cherry picked from commit 48343d458c33553dc6e8b90d3a6221d8dee6a97f) |
| Comment by Githook User [ 23/Oct/20 ] |
|
Author: {'name': 'Sara Golemon', 'email': 'sara.golemon@mongodb.com', 'username': 'sgolemon'}Message: (cherry picked from commit 680eb5a61bc123d021a75b5ec5a997409ec0d36d) |
| Comment by Githook User [ 23/Oct/20 ] |
|
Author: {'name': 'Sara Golemon', 'email': 'sara.golemon@mongodb.com', 'username': 'sgolemon'}Message: (cherry picked from commit 48343d458c33553dc6e8b90d3a6221d8dee6a97f) |
| Comment by Githook User [ 22/Oct/20 ] |
|
Author: {'name': 'Sara Golemon', 'email': 'sara.golemon@mongodb.com', 'username': 'sgolemon'}Message: (cherry picked from commit 680eb5a61bc123d021a75b5ec5a997409ec0d36d) |
| Comment by Githook User [ 22/Oct/20 ] |
|
Author: {'name': 'Sara Golemon', 'email': 'sara.golemon@mongodb.com', 'username': 'sgolemon'}Message: (cherry picked from commit 48343d458c33553dc6e8b90d3a6221d8dee6a97f) |
| Comment by Githook User [ 25/Aug/20 ] |
|
Author: {'name': 'Sara Golemon', 'email': 'sara.golemon@mongodb.com', 'username': 'sgolemon'}Message: |
| Comment by Githook User [ 25/Aug/20 ] |
|
Author: {'name': 'Sara Golemon', 'email': 'sara.golemon@mongodb.com', 'username': 'sgolemon'}Message: |
| Comment by Spencer Jackson [ 26/May/20 ] |
|
The server doesn't, to the best of my knowledge, persist logical session state for unauthenticated users. Ending a session while not authenticated is a little weird, because the name of the user which owns the session is baked into the logical session's internal ID. If a session is used on a connection which has never been authenticated, "ending" such a such would just be a no-op. If a client-side session ID had ever actually been used however, then it will not be possible to end it without being authenticated as the user which created it. It also wouldn't be possible for unauthenticated clients to tell whether it has been used. Possible alternatives I could imagine:
mira.carey@mongodb.com do you have any other ideas? |
| Comment by Divjot Arora (Inactive) [ 24/May/20 ] |
|
john.morales Thanks for the background! The monitoring agent's use case definitely makes sense. I don't think this DRIVERS ticket is worth doing. It would require additional API to either close a client without running endSessions or to opt out of sessions when creating a client. Doing either of these across drivers and then documenting when a user might want them seems like more work than it's worth. The large majority of users aren't creating unauthenticated connections to servers that require auth, so sessions "just work" for them. jeff.yemin The server team can comment about the viability of making endSessions a no-op for this use case, but I think a server-side fix won't be enough for Cloud as they need to support already released versions of the server. This is the same issue we ran into when Cloud first upgraded to the 1.1.x branch and had to workaround a bug that was fixed and backported to 3.6, but existed in previous 3.6 releases. Given all of this, I think we should close out this DRIVERS ticket and possibly file a SERVER ticket depending on input from mira.carey@mongodb.com or spencer.jackson to allow this behavior in future releases. We can discuss either making a Go-specific fix or changing the monitoring agent to use lower-level driver APIs, but that discussion should be elsewhere. |
| Comment by Divjot Arora (Inactive) [ 21/May/20 ] |
|
For additional context, the Go driver does ignore errors from the endSessions command per the sessions spec, but the monitoring agent is a special use-case because it parses server logs, which show the unauthorized endSessions attempt. |