Privilege escalation on LDAP sync

Customer incident report: https://gitlab.zendesk.com/agent/tickets/23090

---

On our production instance of GitLab Enterprise Edition 8.7.1-ee 30bca29 we have a serious security issue.

Certain users/groups are getting master permissions on every group.

---

Notes from Webex meeting

• May 4 updated from 8.6.x to 8.7.1
• starting May 6 logs show a lot of users being added to projects
• It seems too many users get access to projects

---

Problem summary: we have one example user (of many) who should have access to less than 10 groups but who suddenly has access to over 300 groups. We have an example of a GitLab group with two LDAP links; the example user is in neither of the linked groups.

This seems to happen on each LDAP sync (users having access to more and more groups/projects)

@jacobvosmaer-gitlab is investigating queries to run with the customer to reduce the scope of the problem.

cc/ @stanhu @DouweM

From @jacobvosmaer-gitlab comment:

I think I found the problem, it looks like https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/306/diffs#7595daf294d6eacfbcb4355d3217a67dd61df0dd_157_143 introduced a bug where each successive group remembers members from previously processed groups.

In the log output (the customer) sent us I can see how the length of the 'Resolved ... group member access:' lines grows (sometimes it goes down, but the trend is upward).

Milestone changed to 8.7

This is a major problem for everybody who uses EE LDAP group sync. The customer who reported it may be forced to shut down GitLab until the issue is fixed because they can no longer be sure that any project access controls are configured correctly.

I think we should release a new 8.7.x as soon as possible to fix this.

I will start working on a fix.

Reassigned to @jacobvosmaer-gitlab

Thanks @jacobvosmaer-gitlab

After discussing the schedule with @yorickpeterse I have told the customer in https://gitlab.zendesk.com/agent/tickets/23090 that if all goes well we can have a fix out at the end of the EU working day tomorrow.

Work in progress non-public MR: https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/499

Had a call with @dblessing to try and understand better what is going on. Drew came up with a one-line quick patch that we have offered to the customer as an option in the meantime while the official fix is not out yet. The MR with the official patch is now ready for review, we hope that it can go out tomorrow in a patch release.

MR is as good as ready, we can start the release process tomorrow morning (EU time) I hope.

Can we start it today @yorickpeterse ?

@pcarranza It's the end of my day, so I'll start doing things tomorrow.

cool, thanks! @yorickpeterse

(I had to ask :)

@yorickpeterse is now starting the release process. I have notified the customer of our progress via Zendesk.

Release post MR: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/2097

Status changed to closed

Removed confidentiality, closing as fixed.