Proper response to CVE-2022-1162 using LDAP auth

Looking at an upgrade to 14.x from 13.12.15-ee… I’m curious what the response to the CVE-2022-1162 vulnerability is, when my accounts are linked to Active Directory. Is the issue a backing credential in GitLab, or something else? Is the proper response to anything found by the published “script-to-identify-users-potentially-impacted-by-cve-2022-1162” in the blog to make users change their LDAP password? Or something else?

Is there something that can be done on the GitLab side rather than forcing a user to change his LDAP password?

Thanks.
-Alan

Hi Webminster :wave:

Looking at an upgrade to 14.x from 13.12.15-ee…

The only versions of GitLab affected by CVE-2022-1162 are:

  • 14.7.0 to 14.7.6
  • 14.8.0 to 14.8.4
  • 14.9.0 and 14.9.1

Since you’re not running one of the affected versions, there is no need to reset passwords, run the script, or take action to mitigate this.

When it comes time to upgrade, just be sure to use the latest patch version for GitLab minor releases. For example, if you want to upgrade to 14.9.x, upgrade to 14.9.2 (or newer) instead of upgrading to 14.9.0 or 14.9.1.

1 Like

Hello,

we have upgraded from 14.8.2 and I found 3 users with the script. They are all using Active Directory logins. Has gitlab created local vulnerable passwords for them? I’d appreciate guidance regarding the original question of this thread for people with vulnerable versions that sync their users from ldap/ad.

Thanks,
Alex

3 Likes

Hello,

we have the same question. We are using 14.7.0 and external ldap server. So we need asap to update and force users to change passwords? How we can deal with passwords more centralize and, perhaps, generate and change them only in gitlab database?

Hi Greg.

Thanks for the version brackets clarification.

Our current version v14.1.8 is thus not affected.
We actually never updated to any of the mentioned affected versions.

We still used the script find-impacted-users.rb for checking.
Running it, we found some users.
As far as I can tell, all the script actually does, is list all new users since the START_DATE that is hardcoded (Jan 20, 2022).

The bug was introduced with v14.7.0.
According to the repository, v14.7.0 was released on Jan 21, 2022.
So, any user created AFTER Jan 21, 2022, using one of the affected versions at user creation time, can be affected.

My conclusion is that the users listed by the script actually are totally NOT affected in my case, as we were running v14.1.8 until now.

Could you please confirm my conclusion ?

Thanks for your help,

Ahmed.

So, any user created AFTER Jan 21, 2022, using one of the affected versions at user creation time, can be affected.

Yes, that is correct. To be vulnerable to this, you must have been running one of the affected versions after Jan 20 and have at least one user register using OmniAuth (LDAP, SAML, OAuth, etc.) since then.

If you were never running an affected version, the script will still list users who were created after Jan 21, but these users would not be vulnerable as they wouldn’t have a hardcoded password set. This vulnerability only applies to these versions:

  • 14.7.0 to 14.7.6
  • 14.8.0 to 14.8.4
  • 14.9.0 and 14.9.1

If you were never running one of these versions, there’s no need to run the script.

If you are using OmniAuth for new users and you’ve been running one of these vulnerable versions since Jan 20, the script can help you identify which (if any) users could have hardcoded passwords.

Thanks @gitlab-greg, that answer is helpful. Sounds like I don’t need a special action since I was running 13.x during that period. And nothing to do to fix it during the upgrade path.

1 Like