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
- In an Incognito Window, login as an administrator
- Go to the Admin section
- Click on "Users"
- Select any user
- Click "Impersonate"
-
Click on the "Stop Impersonation" icon in the upper right:
- 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.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback