Impersonating an admin who impersonates yourself leads to a non-audited authenticated session

Procedure:

1. Have two or more admin users (Alice and Bob)
2. Log in as Alice (yourself)
3. Impersonate Bob
4. In that impersonation sessions, impersonate Alice
5. Stop impersonation
6. See that you are now logged in as Bob
7. However, you really are still Alice, but GitLab's interface no longer indicates that you are impersonating Bob, rather you are Bob.

Also reported and discussed at https://hackerone.com/reports/770997. @jeremy @lmcandrew This is clearly a bug, but the security impact is limited. Thank you @sirlatrom for the summary below:

The crux of the matter is that the admin would be able to as an existing user, which would look less suspicious in audit logs in e.g. an LDAP configured environment. That user would also potentially have a more believable creation date, commit history, etc. than a newly created instance-local user. Impersonation also allows this, but it is normally clear that impersonation is taking place.

We can process it as a regular ~bug and not as a security fix

the report is not public yet?

added priority4 security severity4 labels

added groupauthentication and authorization [DEPRECATED] + 1 deleted label

added devopsmanage label and removed 1 deleted label

Ping @wkariniemi who got the idea.

@jeremymatos: If you're sure you don't consider this a security issue, please mark the issue as non-confidential.

Making issue public

added typebug label and removed security label

made the issue visible to everyone

mentioned in issue #196462 (closed)

Setting ~"Category:Authentication and Authorization" based on ~"group::access".

added 1 deleted label

I do not agree that this is a bug. The security impacts the integrity of any system which uses LDAP or any other directory tool. It is possible for someone who has gained access to an admin account to promote any user to admin and then perform any number of nefarious actions. It brings to question if Gitlab admins have access to my admin account, similarly to how I have access to users below me, and the actions an unknown Gitlab admin could take inside my "secured" Gitlab world. There is no way of knowing if an action has been taken by the admin or by someone else, or by someone acting in the admins place. Or someone acting in the place of an admin, acting in the place of an admin, who has created a fake admin user. etc.

As an admin in a company, this is a huge security hole.

Correction: It is a bug. It is also a security vulnerability of high impact.

@wkariniemi What is the biggest concern for you ? It will help make sure we evaluate the priorities correctly.

1. That an admin can promote, via the admin dashboard, a regular user to admin
2. That an admin can impersonate another admin
3. That there is a "double impersonation" bug that could be abused by adminA to act maliciously on behalf of adminB (the scenario detailed in this issue).

When you talk about a GitLab admin, you mean a GitLab employee or the administrator of a self-hosted GitLab instance ?

hello. global admins would have access on GitLab cloud instance (correct me if I am wrong). On local instance, any admin can impersonate any person and submit code change is if they were that person, there would be no history to show this action taking place. for example, if an admin impersonated a person and then impersonated another person from that person. It creates a scenario which cannot be properly audited.

the ability to promote another user to admin can be abused maliciously, in the scenario described. the ability to promote, by itself is not a problem. combined with this untraceable history, it can be a tool for untraceable malicious action.

mentioned in issue #197796 (closed)

mentioned in issue #198977 (closed)

mentioned in issue #201613 (closed)

mentioned in issue #204650 (closed)

changed milestone to %Backlog

added [deprecated] Accepting merge requests label

This is a security vulnerability, must be fixed immediately.

The solution is, when you try to impersonate, it should call leave impersonation method first, then impersonate to the new user. Must be very easy to fix.

Also related: #19545 (closed) #26430 (closed)

added sectiondev label

added vintage label

Hi @sirlatrom ,

Thanks for raising this bug.

Contributions like this are vital to help make GitLab a better product.

We would be grateful for your help in verifying whether your bug report requires further attention from the team. If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please comment on this issue.

This issue has been inactive for more than 12 months now and based on the policy for inactive bugs, will be closed in 7 days.

Thanks for your contributions to make GitLab better!

added stale label

Hi @sirlatrom ,

Based on the policy for inactive bugs, this issue is now being closed.

If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please reopen this issue.

Thanks for your contributions to make GitLab better!

closed

added auto closed label