Responsible disclosure: improper access control in Gitlab private project.

As I said back in September regarding a responsible disclosure about Facebook, data access control isn’t easy. While it can sound elementary, it is very difficult, both on a theoretical side and on a practical side.

| Published

This issue was firstly reported on HackerOne and was managed on the Gitlab issues’ tracker. Both links are now publicly accessible.

Summary of the issue

  • Rogue user is added to a private group with dozens of projects

  • The user’s role in some projects changes

  • Rogue is fired, and removed from the group: they still have access to projects where their role was changed

The second step could happen for a lot of different reasons:

  • rogue is added as master - knowing this vulnerability, they decrease their privileges to stay in some projects (this is the only malicious one)

  • rogue is added as developer, but they become responsible for some projects, and are promoted to master role

  • rogue is added as reporter, and then they are promoted for a project, and so on.

When an admin removes a user from a private group, there is no indication that the user still has access to private projects, if their role was changed.

Impact

User can still see all resources of a project of a secret group after they have been removed from the parent’s group.

Timeline

  • 29 January 2018: First disclosure to Gitlab

  • 9 February 2018: Gitlab confirmed the issue and triaged it, assigning a medium priority

  • 25 February 2018: I ask for a timeline

  • 27 February 2018: They inform me they will update me with a timeline

  • 16 March 2018: Almost two months are passed, I ask again for a timeline or suggest to go public since administrators of groups can easily check and avoid this vulnerability

  • 17 March 2018: They inform me they will update me with a timeline, and ask to do not go public

  • Somewhere around December 2018: the team think the issue has been fixed, and close the internal issue - without communicating with me

  • 17 January 2019: I ask for an update - they will never reply to this message

  • 25 January 2019: the security team sees this is still an issue

  • 31 January 2019: the fix is deployed in production and publicly disclosed, without informing me

  • 5 March 2019: I ask again for another update

  • 12 March 2019: Gitlab says the issue has been fixed and awards me a bounty

Bounty

Gitlab awarded me a $2000 bounty award for the disclosure.

If you follow my blog, you know I deeply love Gitlab: I contribute to it, I write blog posts, and I advocate for it any time I can. Still, I think this experience was awful, to say the least. There was a total lack of communication by their side, they thought they fixed the issue the first time, but actually, it wasn’t fixed. If they had communicated with me, I would have double checked their work. After that, they deployed the fix and went public, without telling me. I was not interested in the bounty (for which I am grateful), I reported the issue because I care about Gitlab. Nonetheless, my love for Gitlab is still the same! I just hope they will improve this part of communication / contributing to Gitlab: in the last couple of years the community around the project grew a lot, and they are doing amazing with it, maybe the Community team should step in and help also the security community?

For any comment, feedback, critic, leave a comment below, or drop an email at [email protected].

Regards,
R.

Comments