GitLab repairs critical flaw that lets users log in as admins

The fixes are available for all supported versions of GitLab Community Edition and GitLab Enterprise Edition

GitLab fixes critical flaw that lets users log in as admins
Credit: Thinkstock

GitLab patched multiple privilege escalation flaws, cross-site scripting bugs, and information disclosure vulnerabilities in both the open source and commercial versions of its self-hosted system for managing Git repositories. The most notable is a serious authentication flaw that enabled users to log in as other users.

The critical vulnerability was in GitLab's "impersonate" feature (CVE-2016-4340), which was introduced in GitLab 8.2 to let an administrator simulate being logged in as another user. However, the feature was not properly secured, so any authenticated user could log in as another user, even as administrators, GitLab said in its security advisory. The issue was discovered as part of an internal code review.

"I think this the worst vulnerability we've had to date," Douwe Maan, development lead at GitLab, wrote on the internal issue tracker.

Versions 8.7, 8.6.0 through 8.6.7, 8.5.0 through 8.5.11, 8.4.0 through 8.4.9, 8.3.0 through 8.3.8, and 8.2.0 through 8.2.4 for the CE (Community Edition) and EE (Enterprise Edition) are affected. All installations should be upgraded to versions 8.7.1, 8.6.8, 8.5.12, 8.4.10, 8.3.9, and 8.2.5 as soon as possible.

Administrators who can't upgrade their server installations right away can use a workaround to turn off impersonation. There are recommendations for securing installations using the bundled Nginix Web server, an external Web server, the HAProxy configuration, or the patch.

A privilege escalation flaw in the Notes API would allow attackers to send a specially crafted request to the GitLab API and post notes on merge requests, snippets, and issues without permission. The attacker would be able to craft a request from one project to add notes and other objects to the victim's private project.

"This vulnerability can be used to scare people because it looks like the unauthorized user has access to the issue, snippet, or merge request," wrote GitLab developer Robert Speicher.

The other privilege escalation flaw in the project webhook API lets attackers delete and read webhooks for all projects on a GitLab instance. Attackers can send API requests to the targeted project from a project they own to access subresources. "This is a bad vulnerability because these webhooks contain private (API) tokens most of the time," Speicher noted.

Among the four XSS bugs fixed, one could potentially enable attackers to execute arbitrary JavaScript and steal the victim's API token in order to take over the account. The API token can be used to access the user's projects, perform actions as the user, and gain access to potential confidential information stored in the project. The four information disclosure flaws also exposed private project information, including one in which private snippets posted to public projects were leaked through the GitLab API.

"It seems that private snippets may be used to hold private (API) tokens or similar confidential information. This can seriously damage to a company depending on what kind of information is shared," according to the description of the flaw.  

Users with projects on don't have to worry as the company takes care of maintaining the platform. For administrators managing GitLab CE or GitLab EE installed on their own hardware, GitLab advises updating to the latest versions immediately, especially because the impersonation flaw is very serious.

This story, "GitLab repairs critical flaw that lets users log in as admins" was originally published by InfoWorld.