GitLab has just announced a fix for a number of important security issues, including a critical privilege escalation, and strongly recommends that all GitLab installations from version 8.2 onwards be upgraded immediately.
GitLab discovered a critical vulnerability that allowed any authenticated user to log in as any other user, including administrators. The vulnerability was introduced back in version 8.2 of GitLab, which brought an “impersonate” feature intended to allow an administrator to simulate being logged in as any other user.
This vulnerability affects all GitLab version from 8.2.0 through 8.7.0. GitLab engineer Douwe Maan described this vulnerability as possibly the worst they have had to date.
In addition to providing patched versions of its software, GitLab also disclosed several methods to patch a working GitLab installation by changing the web server configuration, the proxy server’s, or patching a ruby file. As an example, for installations using the Apache web server, the vulnerability fix consists in defining the following access rule:
<LocationMatch "^/admin/users/stop_impersonation">
Order Deny,Allow
Deny from all
</LocationMatch>
GitLab’s disclosure also included other vulnerabilities of minor criticality, including:
- privilege escalation via notes API, which allowed to post notes on merge requests, snippets, and issues that the user had no access to.
- privilege escalation via project webhook API, which allowed an authenticated user to read and delete webhooks from a private project.
- several XSS vulnerabilities and others leading to information disclosure.
InfoQ has spoken with GitLab’s Stan Hu, VP of Engineering, to learn more about this vulnerability announcement and GitLab’s general approach to the matter.
Could you shortly explain what impact, if any, the recently disclosed GitLab vulnerabilities have had?
As far as we know, there currently have been no known impacts. These vulnerabilities were all identified by code audits from both GitLab employees and security researchers.
GitLab routinely discloses vulnerabilities and follows an open policy about them. This is in itself a great plus, but some people are concerned at the sheer number of vulnerabilities and the frequency with which they are found in GitLab. Would you please comment on this?
GitLab has and will continue to be open about security vulnerabilities. We prioritize fixing security issues above everything else, and each time we receive a vulnerability report we try to address it as quickly as possible. We have hundreds of contributors, both paid staff members and volunteers, looking at our code every day.
Every month, we deliver a new release with many new features and bug fixes. Our overall code quality is generally high, and we do our best to review every line of code and include complete tests. Our presence on sites such as HackerOne has enabled even more security researchers to help identify potential problems with GitLab. Unlike proprietary software, being an open source project means that we have to be open with our security issues.
Any insight about the whole process from initial discovery through patch distribution?
As soon as we discovered CVE–2016–4340, we had an internal fix ready within an hour. We first patched GitLab.com and immediately began backporting a number of patches to all affected versions in a private repository. Via e-mail and our blog, we alerted our customers and the public about the date of the security update (Monday, May 2 at 23:59 UTC) to give people time to prepare for the update. We shared the patches with native package maintainers (e.g. Debian, FreeBSD, etc.), who all appreciated the advance notice. On Monday, May 2, we released the GitLab package updates along with a blog post detailing workarounds for users who were not able to update. We sent the full details of the CVE to MITRE. We publicly disclosed all the code and issues relating to the vulnerabilities.
