Critical Security Release for GitLab 8.2 through 8.7

Today we are releasing versions 8.7.1, 8.6.8, 8.5.12, 8.4.10, 8.3.9, and 8.2.5 for GitLab Community Edition (CE) and Enterprise Edition (EE).

These versions contain a number of important security fixes, including one for a critical privilege escalation, and we strongly recommend that all GitLab installations be upgraded to one of these versions immediately.

Please read on for more details.

Privilege escalation via "impersonate" feature

During an internal code review, we discovered a critical security flaw in the "impersonate" feature of GitLab. Added in GitLab 8.2, this feature was intended to allow an administrator to simulate being logged in as any other user.

A part of this feature was not properly secured and it was possible for any authenticated user, administrator or not, to "log in" as any other user, including administrators. Please see the issue for more details.

This issue has been assigned CVE-2016-4340.

Versions affected

• 8.7.0
• 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
• 8.2.0 through 8.2.4

We strongly recommend that all installations running a version mentioned above be upgraded as soon as possible.

Workarounds

If you're unable to upgrade right away, you can secure your GitLab installation against this vulnerability using one of the workarounds outlined below until you have time to upgrade.

You only need to apply one of these workarounds. Each assumes you aren't using relative URLs; if you are, adjust the path accordingly.

Securing via Omnibus configuration

For Omnibus installations using the bundled Nginx web server, edit /etc/gitlab/gitlab.rb and add the following line:

nginx['custom_gitlab_server_config'] = "location ^~ /admin/users/stop_impersonation { deny all; }\n"

Then run sudo gitlab-ctl reconfigure for the changes to take effect.

Securing via web server configuration

If you are using an external web server with Omnibus or have installed GitLab from source, add the following lines to your web server's configuration file.

For Nginx:

location ^~ /admin/users/stop_impersonation { deny all; }

For Apache:

<LocationMatch "^/admin/users/stop_impersonation">
  Order Deny,Allow
  Deny from all
</LocationMatch>

Then reload the server for changes to take effect.

Securing via HAProxy configuration

Add the following lines to your configuration and restart the service:

acl is_stop_impersonation  path_beg         /admin/users/stop_impersonation
acl is_delete method DELETE
http-request deny if is_delete is_stop_impersonation

Securing via patch

diff --git a/app/controllers/admin/impersonation_controller.rb b/app/controllers/admin/impersonation_controller.rb
index bf98af7..8790018 100644
--- a/app/controllers/admin/impersonation_controller.rb
+++ b/app/controllers/admin/impersonation_controller.rb
@@ -1,4 +1,5 @@
 class Admin::ImpersonationController < Admin::ApplicationController
+  before_action :render_403, only: :destroy
   skip_before_action :authenticate_admin!, only: :destroy

   before_action :user

Verifying the workaround

1. In an Incognito Window, login as an administrator
2. Go to the Admin section
3. Click on "Users"
4. Select any user
5. Click "Impersonate"

6. Click on the "Stop Impersonation" icon in the upper right:

   

7. Verify you receive a 403 Forbidden error

Privilege escalation via notes API

By sending a specially-crafted request to the GitLab API, it was possible to post notes on merge requests, snippets, and issues that the user did not have access to. See the issue for more details.

Thanks to Jobert Abma of HackerOne for responsibly disclosing this issue to us.

Privilege escalation via project webhook API

The project webhook API was not sufficiently secured, and made it possible for an authenticated user to read and delete webhooks from a private project. See the issue for more details.

Thanks to Jobert Abma of HackerOne for responsibly disclosing this issue to us.

XSS vulnerability via branch and tag names

Git branch and tag names were not being properly escaped before being displayed on certain pages. See the issue for more details.

Thanks to Teun Beijers for responsibly disclosing this issue to us.

XSS vulnerability via custom issue tracker URL

Custom issue tracker service URLs were not being properly validated, making it possible to craft a specific URL that could be used in an XSS attack. See the issue for more details.

Thanks to Jobert Abma of HackerOne for responsibly disclosing this issue to us.

XSS vulnerability via window.opener

External links were not properly voiding the window.opener attribute, which could allow the external page to control the window object that opened it. See the issue for more details.

Thanks to Anirudh Anand of 0daylabs for responsibly disclosing this issue to us.

XSS vulnerability via label drop-down

Label names were not being properly escaped before being displayed in certain drop-downs. See the issue for more details.

Only the following versions are affected: 8.6.0 through 8.6.7, and 8.7.0.

Thanks to Gearlles Ferreira for responsibly disclosing this issue to us.

Information disclosure via milestone API

Confidential issues attached to a milestone were being leaked via the milestone API. See the issue for more details.

Only the following versions are affected: 8.6.0 through 8.6.7, and 8.7.0.

Thanks to Jobert Abma of HackerOne for responsibly disclosing this issue to us.

Information disclosure via snippet API

Private snippets were being exposed via the GitLab API. See the issue for more details.

Thanks to Jobert Abma of HackerOne for responsibly disclosing this issue to us.

Information disclosure via project labels

It was possible for an attacker to add labels from a private project to their own, possibly exposing sensitive information contained in a label's name or description. See the issue for more details.

Thanks to Jobert Abma of HackerOne for responsibly disclosing this issue to us.

Information disclosure via new merge request page

It was possible for an attacker to discover the namespace and name of a private project via the "new merge request" page. See the issue for more details.

Thanks to Jobert Abma of HackerOne for responsibly disclosing this issue to us.

Upgrade barometer

These versions do not include any new migrations, and should not require any downtime.

Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations file.

Updating

To update, check out our update page.

Enterprise Edition

Interested in GitLab Enterprise Edition? Check out the features exclusive to EE.

Access to GitLab Enterprise Edition is included with a subscription. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation services.