Created attachment 11235 [details] Reproduction script The Self-Service has the ability to reset ones password via providing a token. The endpoint for this ("/univention/command/passwordreset/send_token") can be called with invalid credentials, a database session to check the token is opened in any case. This quickly causes the limit of the postgres connections to be reached rendering the postgres DB unavailable for normal connections e.g. from Keycloak, OpenProject etc. until the self service (or it's related modules release the connections). But of course an attacker would just continue with the scripts execution. A script to reproduce is attached.
We could do in the XML definition of the UMC module: <module id="passwordreset" priority="50" version="1.0" python="3" singleton="1"> This not only greatly increases the performance, it also reduces the number of database connections to 1 throughout the runtime of the script. The README for UMC says: For each session (logged in user) and each module an own linux process is started, which serves a HTTP server via a UNIX socket. This is very memory consuming (at least 30 MB per process) and bad practice. Many modules wouldn't need this as they are designed stateless. A experimental untested flag to prevent this exists, via a flag `<module singleton="1" …>` flag in the XML definition. Especially modules with `allow_anonymous="true"` like the self service should use this, as they should be already independent of any session and these modules allow unauthenticated access, opening the way up for denial of service. So this would need thorough QA. But it seems to work. And we do have tests for the Self Service. Another option may be to kill the UMC module after each and every request.
Created attachment 11236 [details] Memory-usage at logins Additional information regarding the observed behavior
More details regarding this behavior: > I assume your devs already did an analysis, but just 2 more cents from me: I also use the password reset, when setting up new users in batch mode, there I just call the 2nd request on the endpoint > > /univention/command/passwordreset/send_token > > This can be used multiple dozen times without running into the issue. So I guess the problem comes from requesting the password reset methods: > > /univention/command/passwordreset/get_reset_methods proposed solutions: > As we only offer email anyway currently, you might introduce a config option that skips that request and just triggers the send_token with method email: { "options": { "username": <username>, "method": "email" }} > > The alternative would be (a more generic approach) to configure the password reset methods a site offers statically, as we anyway do not want to present unauthenticated users any information about a specific account (e.g. which password reset options have been configured on an account) that would also be the more secure solution. > > If I recall correctly: In the past users that did not exist or did not have configured a password reset email did not get to the 2nd stage of the password reset process at all. That was changed exactly for the reason to not reveal account specific information to unauthenticated users.
Added <module id="passwordreset" priority="50" version="1.0" python="3" singleton="1"> to the XML file of the process. A new test counts the number of UMC module instances after three requests (were: 3, now: 1) univention-self-service.yaml c2d454d64332 | Bug #57609: Make the UMC module a singleton univention-self-service (5.0.11-2) 3de31aac329f | Bug #57609: Make the UMC module a singleton ucs-test (10.0.23-9) 8d259adc9da5 | Bug #57609: Version bump ucs-test (10.0.23-8) 3b1fea89209b | Bug #57609: Make the UMC module a singleton c2d454d64332 | Bug #57609: Make the UMC module a singleton ucs-test (10.0.23-10) 3102ff29357b | Bug #57609: Fix 83_self_service/12_test_singleton to only run on roles that have the Self Service installed Merged to 5.1 and 5.2: univention-self-service (6.0.8) 83ea9ad2d8cb | Bug #57609: Changelog ucs-test (11.0.57) 83ea9ad2d8cb | Bug #57609: Changelog ucs-test (11.0.56) 5705940e48dc | Bug #57609: Make the Self Service UMC module a singleton; add a test univention-self-service (7.0.4) beb5261063c4 | Bug #57609: Changelog ucs-test (12.0.183) beb5261063c4 | Bug #57609: Changelog ucs-test (12.0.182) de333e734e27 | Bug #57609: Make the Self Service UMC module a singleton; add a test
Code Review of singleton=1: Ok Yaml: Ok Tests: Ok Manual tests: Ok
I had to restart the UMC in 83_self_service/08_service_specific_passwords.py because this test activates the Service Specific Passwords via UCR but the (now singleton!) UMC module is already running and thus does not yet allow using this function. Packages are built in 5.0-9 and 5.2
<https://errata.software-univention.de/#/?erratum=5.0x1133>