[SERVER-47429] authenticationMechanisms parameter is not validated Created: 09/Apr/20  Updated: 29/Oct/23  Resolved: 20/Apr/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.2.3, 4.3.4
Fix Version/s: 4.2.7, 4.4.0-rc4, 4.7.0

Type: Bug Priority: Minor - P4
Reporter: Oleg Pudeyev (Inactive) Assignee: Mark Benvenuto
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.4, v4.2
Sprint: Security 2020-04-20, Security 2020-05-04
Participants:

 Description   

If I start a server with authenticationMechanisms set to the empty string it fails:

 /usr/local/m/versions/4.2/mongod --dbpath /tmp/42 --setParameter authenticationMechanisms='' --auth 

However if I supply a bogus value for the mechanisms the server seems to start just fine:

 /usr/local/m/versions/4.2/mongod --dbpath /tmp/42 --setParameter authenticationMechanisms='!' --auth 

It even claims to have accepted ! for the mechanisms:

2020-04-08T22:04:45.981-0400 I  CONTROL  [initandlisten] options: { security: { authorization: "enabled" }, setParameter: { authenticationMechanisms: "!" }, storage: { dbPath: "/tmp/42" } }

This becomes a more significant issue when the mechanisms are valid but not for the version of the server that is being launched. For example, the following invocation tries to start 4.2 with the aws mechanism and succeeds (subsequently failing all aws auth authentication attempts):

/usr/local/m/versions/4.2/mongod --dbpath /tmp/42 --setParameter authenticationMechanisms=SCRAM-SHA-1,SCRAM-SHA-256,MONGODB-AWS --auth 

As a user of the server, I would like the server to validate authenticationMechanisms parameter when it starts so that I am informed when I requested mechanisms that the server does not support, so that I can efficiently remedy the misconfiguration.



 Comments   
Comment by Githook User [ 29/Apr/20 ]

Author:

{'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com', 'username': 'markbenvenuto'}

Message: SERVER-47429 Validate authenticationMechanisms server parameter

(cherry picked from commit 817a7f1951189b2a8c7c06fb5fb5361241c1cd57)
Branch: v4.2
https://github.com/mongodb/mongo/commit/09c727b590720420f3cb206fe53931810638c336

Comment by Githook User [ 29/Apr/20 ]

Author:

{'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com', 'username': 'markbenvenuto'}

Message: SERVER-47429 Validate authenticationMechanisms server parameter

(cherry picked from commit f85a6c4d38be2a36aec15f5a62a28f56fd2178bd)
Branch: v4.2
https://github.com/10gen/mongo-enterprise-modules/commit/335d6d5d33f514a0876192b7e0f6a9377eaceec8

Comment by Githook User [ 28/Apr/20 ]

Author:

{'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com', 'username': 'markbenvenuto'}

Message: SERVER-47429 Validate authenticationMechanisms server parameter

(cherry picked from commit f85a6c4d38be2a36aec15f5a62a28f56fd2178bd)
Branch: v4.4
https://github.com/10gen/mongo-enterprise-modules/commit/a62edd03c344c359cf20de3327f5cf5b213cca75

Comment by Githook User [ 20/Apr/20 ]

Author:

{'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com', 'username': 'markbenvenuto'}

Message: SERVER-47429 Validate authenticationMechanisms server parameter
Branch: master
https://github.com/mongodb/mongo/commit/817a7f1951189b2a8c7c06fb5fb5361241c1cd57

Comment by Githook User [ 20/Apr/20 ]

Author:

{'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com', 'username': 'markbenvenuto'}

Message: SERVER-47429 Validate authenticationMechanisms server parameter
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/f85a6c4d38be2a36aec15f5a62a28f56fd2178bd

Comment by Spencer Jackson [ 13/Apr/20 ]

Pretty much, yeah. An out-of-band parameter check seems fine.

The service context hook just seemed like an easy place to put the check, because other hooks are responsible for registering the factories, and the assertion has to be made after registration is complete.

Comment by Mark Benvenuto [ 13/Apr/20 ]

While we could add some sort of check via the ServiceContext hooks, do you want to just fassert if validation fails? This means we could not tie into the server parameter validation hooks and this would be a special out-of-band parameter check.

Comment by Spencer Jackson [ 13/Apr/20 ]

mark.benvenuto, what if we added another ServiceContext initialization action which occurred after all of the mechanism parameters were loaded, and validated that every configured name had a corresponding factory?

Comment by Mark Benvenuto [ 13/Apr/20 ]

Spencer.Jackson, This is not possible to fix today because command line/config validation occurs before the SASL mechanisms are registered. SASL mechanisms registered on the ServiceContext which is created after command line/config validation.

In order to fix this, we need to make the list of SASL mechanism available during command line validation which means moving the SASL mechanism registry off the Service Context. Let me know if this solution is acceptable or if you have another suggestion.

Generated at Thu Feb 08 05:14:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.