BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News GitLab Discloses Critical Vulnerability, Provides Patch

GitLab Discloses Critical Vulnerability, Provides Patch

This item in japanese

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:

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.

Rate this Article

Adoption
Style

BT