Grouper security issue announcement / summary
If you are running Grouper v5.5 and previous using LDAP Authentication you MAY be affected. Grouper v5.6+ is not affected.
There is a serious security vulnerability if you are using Grouper with LDAP authentication and the LDAP is deployed or configured in a certain manner. Generally, this vulnerability is with Grouper Web Services though it is possible to affect the User Interface. If you are affected, you can remediate in one of three ways: configure your LDAP to address the issue, upgrade Grouper, or apply a patch to your container.
Check this wiki for future updates. CVE-2024-39848
Request testing documentation
If you have questions, send a direct slack message to Chris Hyzer, the project lead (request to join InCommon SLACK). If you are not a member of the InCommon SLACK Workspace, or do not wish to join that workspace, then email mchyzer@yahoo.com.
Change log of this document
- 2024/06/25: Document created
- 2024/06/26: Added acknowledgment to Jeff Williams at UNCG
- 2024/07/07: Added testing steps
Might you be affected?
Certain LDAP vendors behave differently with authentication, so it is vendor specific, and it depends on the configuration of your LDAP / Active Directory.
To see if you have LDAP authentication in the Grouper Web Services:
- Look in all your environments (dev/test/prod/etc)
- If you have configuration in the User Interface screens, filter the grouper-ws.properties file
- If you do not have the configuration readable from the User Interface (old Grouper version), look in the file: grouper-ws.properties
- Look for the key: security.non-rampart.authentication.class
- See if it has the value: internet2.middleware.grouper.ws.security.WsGrouperLdapAuthentication
If you have LDAP authentication configured in Apache or another component upstream of Grouper you may also be affected.
If you have LDAP authentication, see testing information below
If you are affected or unsure if you are affected
Especially if your Web Services server is not protected by firewall (i.e. accepts requests from untrusted sources), you should turn off your Web Services server/container while you remediate. Filtering network traffic to your Web Services to trusted sources (e.g. with a firewall) reduces the risk of a security incident with this vulnerability.
Remediation methods
Pick the best remediation method for your circumstances. You only need to perform one remediation method. The same testing steps apply to all remediation methods.
Remediation method 1: configure your LDAP server
You do not need to make changes to Grouper if you can configure your LDAP server appropriately. Or if you have another LDAP server which is not affected by the issue you could configure Grouper to point to that LDAP for authentication instead of the affected one. Details for adjusting your LDAP server are in the testing steps below. Proceed at your own risk. Test the remediation with steps from the testing section below.
Remediation method 2: upgrade Grouper
Grouper v4.13.1 (for Web Services) is the same as v4.13.0 except that is fixes this vulnerability. If you are on v5 (below v5.6), then upgrade to at least v5.6. Test the remediation with steps from the testing section below.
Testing that container upgrade is installed correctly. If you are upgrading to v4.13.1, call the web service with
- user: M3vwHr
- pass: UyY29r
It should respond with a HTTP Response 401 with body: “Invalid username and password handled by valve; built-in valve is working”
You can do a simple postman GET with a URL like this (edit the domain, context, version, etc to point to your environment):
https://server.school.edu/grouper-ws/servicesRest/json/v4_0_0/subjects/test.subject.0
Note: if you have the patch and the upgrade at the same time you will get one or the other valid responses.
Note: see the testing section below for more thorough testing
If you are upgrading to v5.6+, follow the steps in the testing document as the valve is not needed. It is in v5.10.2+ as a best practice only.
Remediation method 3: patch the Grouper Web Services container
This patch can go in any Grouper component (Web Services, User Interface, Daemon), but is only required in the Web Services. This patch will work in most versions of Grouper. If you are on an old version of Grouper, you might need a variation on the remediation method since the patch will only work with Java8 and above. If you are on an old version of Grouper, carefully check your java version by checking the path of the java tomcat/tomee process and run:
/path/to/java -version
The specifics of applying the fix depends on if you are on a recent version of Grouper (i.e. if you are running in a container).
Step 1: download the valve jar
Download someValve.jar into your tomcat lib directory from:
https://software.internet2.edu/grouper/downloads/tools/someValve.jar
In recent Grouper versions this is: /opt/tomcat/lib
In previous Grouper versions this is: /opt/tomee/lib
Step 2: edit the Tomcat server.xml
Edit your tomcat config file: server.xml:
In recent Grouper versions this is: /opt/tomcat/conf/server.xml
In previous Grouper versions this is: /opt/tomee/conf/server.xml
Put this at the end of the Host section:
<Valve className="SomeValve" />
In Grouper v2.5.28+ you can edit your server.xml by adding this to your grouperScriptHooks.sh file or creating a /usr/local/bin/grouperScriptHooks.sh in your container
#!/bin/sh # called after the setupFiles functions is called, almost before the process starts grouperScriptHooks_setupFilesPost() { if [ $(grep -c 'SomeValve' /opt/tomcat/conf/server.xml) -eq 0 ]; then sed -i 's|</Host>|<Valve className="SomeValve" /></Host>|g' /opt/tomcat/conf/server.xml returnCode=$? echo "grouperContainer; INFO: (grouperScriptHooks.sh) Apply valve: /opt/tomcat/conf/server.xml, result: $returnCode" if [ $returnCode != 0 ]; then exit $returnCode; fi fi }
In previous versions of Grouper you can overlay that file (you may need to adjust some environment variables so Grouper does not re-process the config file).
Step 3: environment variable
Environment variable for colons in passwords
Check if you are configured to allow colons in passwords (the default is false). Look in the configuration in the UI (or in the config file if you have an old version of Grouper), in the grouper.properties file, key: grouper.authentication.splitBasicAuthOnFirstColon
If you are looking in the actual config file, and do not see it, look in grouper.base.properties. If this is false, then you do not allow colons in passwords, and the following environment variable will have no effect.
If this is true, then you do allow colons in passwords. To allow passwords to end with a colon, set this environment variable in the container:
GROUPER_BASIC_AUTH_ALLOW_COLONS_IN_PASSWORDS=true
This environment variable will take effect for patched containers, or v4 containers v4.13.1+, or v5 containers v5.10.2+.
Step 4: restart
Restart your Grouper Web Services
Step 5: test the install
Test that the valve is installed correctly
Call the web service with
- user: mF6uEZ
- pass: wNn2DA
It should respond with a HTTP Response 401 with body: “Invalid username and password handled by valve; patch valve is working”
You can do a simple postman GET with a URL like this (edit the domain, context, version, etc to point to your environment):
https://server.school.edu/grouper-ws/servicesRest/json/v4_0_0/subjects/test.subject.0
Note: see the testing section below for testing steps
Step 6: test the remediation
Test the remediation with steps from the testing section below
Acknowledgement
Thanks to Jeff Williams from UNCG for finding this error, reporting it thoroughly and discreetly, testing the patch by remediating his institution, and reviewing the docs
Vulnerability description
If the environment is affected, the web service (or less likely UI) can be invoked for an arbitrary existing user with no password. Grouper delegates the authentication to LDAP and if the LDAP is configured to or behaves by accepting “unauthenticated binds” (valid user with no password) then the WEB SERVICES call will be successful. The LDAP returns a success to a bind for an existing user and no password.
The remediation will intercept all requests to Grouper no matter which authentication method is used and reject calls with no passwords.
Adjust your LDAP server
Remediation option 1 is to configure your LDAP server to not accept unauthenticated binds. If you are certain that you do not need unauthenticated binds, many LDAP servers allow you to disable them. Proceed at your own risk. Another potential option is to point Grouper authentication to another LDAP server which does not accept unauthenticated binds.
Test your environments
Below are the testing steps to see if you are affected by the issue and to verify that the remediation is correct. You should test all your environments (dev/test/prod/etc).
To test, make a GET call like this to your WEB SERVICES in all environments (dev/test/prod etc). Adjust the https, domain name, context (grouper-ws), and version (v4_0_0) to fit your env. Adjust the basic auth “user” and the “password” per the test case. Use a browser or postman or curl or the WEB SERVICES client of your choice and hit any WEB SERVICES endpoint, e.g.
https://domain.edu/grouper-ws/servicesRest/json/v4_0_0/subjects/test.subject.0
Note: You cannot use the grouper client since it requires a password.
Note: Valid user means a Web Services user which is in the group specified by: ws.client.user.group.name, and is in LDAP
Note: When <none> is specified for password, leave it blank
Note: Error generally means it will return a 401 status code, but any 4XX or 5XX status code is fine.
Username | Password | Expected result |
Valid user | Valid password | Valid: 200 (though the response might contain no results) |
Valid user | <none> | Error: 401, response body states invalid user/pass handled by valve (this means you are remediated) If you are not remediated and you receive an error then you are not affected. If you get a 200, you are affected or the remediation is not correct If you are on v5.6 - v5.10 then you will get a response error but will not see the response body from the valve. This is expected and correct. |
Valid user | Valid (or invalid) password ending in colon : | If you do not have the environment variable set in your container: GROUPER_BASIC_AUTH_ALLOW_COLONS_IN_PASSWORDS true Then you do not need to test this. If you do NOT have the env var set, then this expects Error: 401, response body states invalid user/pass handled by valve If you do have the env var set, and it is a valid password that ends in a colon, then you should receive a success. If you do have the env var set, and it is an invalid password that ends in a colon, then you should expect to receive a failure other than response body that states invalid user/pass handled by valve |
Clear your shell history
If you were using curl via commands line with password in the command, edit or delete the history file (e.g. ~/.bash_history) and log out and log in and type: history and ensure any passwords are not stored in your OS.
What is next
If your remediation involves the patch to the container, then after you upgrade to a fixed container version you can remove the patch. It should not initially harm anything to leave the patch intact, but it is unnecessary and could cause confusion in the future.