Responsible disclosure: improper access control in Gitlab private project.
As I said back in September with regard to a responsible disclosure about Facebook, data access control isn’t easy. While it can sound quite simple (just give access to the authorized entities), it is very difficult, both on a theoretical side (who is an authorized entity? What does authorized mean? And how do we identify an entity?) and on a practical side.
Apr
19, 2019 | Riccardo Padovani | [email protected]
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 tomasterrole - 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.