GitLab has addressed a security vulnerability that could have exposed private groups. The flaw existed in the Elasticsearch API that continued to show code after transferring GitLab public groups to private.
GitLab Elasticsearch API Flaw
A researcher Riccardo Padovani discovered a flaw in GitLab Elasticsearch API that risked private groups.
According to the details he submitted via the HackerOne bug report, the Elasticsearch API results continued to show code of projects in private groups after moving the group from public. It means that despite turning the information private, it was still accessible to everyone via search results.
However, this flaw didn’t affect individual projects being transferred from private to public group. Rather the glitch appeared only upon transferring the entire group.
He further elaborated on the glitch with the following example situation.
Alice creates the public group “Example”, and a public project named “Example-project” inside the group. In the readme of the project, Alice writes “Example”.
Now, Alice creates a private group called “private”, and transfer all the “Example” group to the “private” group.
If Bob (totally unrelated to Alice), search for “Example” instance-wide, will not find anything on the interface, but the count of the results will be “1”.
If he uses the APIs (e.g. http://localhost/api/v4/search?search=password&scope=blobs), he will receive the results back with the information that should be private.
The bug also affected wiki_blobs.
GitLab Patched The Bug
Padovani discovered and reported the bug to GitLab via HackerOne in November 2019. Shortly after his report, the GitLab security team started working on the flaw to develop a fix.
Eventually, the succeeded in addressing the bug and closing the report until December 2019. They rolled-out the patch with the release of GitLab version 12.5.4. It means the flaw no more affects any private groups.
The researcher marked this flaw as a medium severity bug considering its not so serious impact.
I set the severity as “medium” and not “high”, because any new action over the project issues a re-indexing (or some actions, not sure), so if the transfer is for “archiving” purposes it is a problem, but if after the transfer other activities happen, then it is not a problem, cause the project will be removed from the index.
The researcher won a $3000 bounty for it.
