Authentication Bypass Using an Alternate Path or Channel in GitLab

Vulnerability

In GitLab CE/EE versions 16.1 through 16.7.6, 16.8 through 16.8.3, and 16.9 through 16.9.1, the password reset flow fails to check whether a user is an LDAP user when a secondary email is used. Normally, LDAP users are prevented from using password authentication, but the check User#allow_password_authentication? is only applied before sending the reset email for primary email. For secondary emails, only the global password_authentication_enabled_for_web? setting is checked, allowing a reset email to be sent to an LDAP user with a confirmed secondary email. [1]

Exploitation

An attacker who is an LDAP user with a confirmed secondary email can initiate a password reset using that secondary email. The system sends a reset link. The attacker can then set a new password and sign in using direct password authentication, bypassing the LDAP server. No additional privileges or network position are required beyond having a valid LDAP account with a confirmed secondary email. [1]

Impact

Successful exploitation allows an LDAP user to gain direct password-based authentication to GitLab, bypassing LDAP authentication. This could lead to unauthorized access if the LDAP server enforces additional restrictions, or allow the user to maintain access even if their LDAP account is disabled. The confidentiality, integrity, and availability impact depends on the user's permissions within GitLab. [1]

Mitigation

GitLab has released fixed versions: 16.7.6, 16.8.3, and 16.9.1. Users should upgrade to these versions or later. As a workaround, disabling password authentication globally (setting password_authentication_enabled_for_web? to false) mitigates the vulnerability, as the reset email would not be sent. [1]