CVE-2017-0882:GitLab信息泄露高危漏洞

GitLab 是一个使用 Ruby on Rails 开发的开源应用程序，实现了一个 Git 仓库管理平台，可通过 Web 界面进行访问公开的或者私有的项目，在企业中得到的广泛的使用。 2017年3月20日，GitLab官方发布了8.17.4、8.16.8和8.15.8版本（社区版和企业版），修复多个高危漏洞，其中包含一个针对关键信息泄露漏洞的更新补丁，针对SSRF攻击的防护，以及针对可导致Atom源中私有邮件地址泄露漏洞的补丁，ElasticSearch中私有库数据泄露的补丁等，攻击者可以通过这些漏洞来获取相应的用户权限，危害严重。

Today we are releasing versions 8.17.4, 8.16.8, and 8.15.8 for GitLab Community Edition (CE) and Enterprise Edition (EE).

These versions contain several security fixes, including an important security fix for a critical information disclosure vulnerability, protection against Server-Side Request Forgery (SSRF) attacks, a fix for some links vulnerable to tabnabbing, a fix for a flaw that could leak private email addresses in Atom feeds, and a fix for private repository data leakage into ElasticSearch (EE-specific). We strongly recommend that all affected GitLab installations be upgraded to one of these versions immediately.

Please read on for more details.

Information Disclosure in Issue and Merge Request Trackers

During an internal code review a critical vulnerability in the GitLab Issue and Merge Request trackers was discovered. This vulnerability could allow a user with access to assign ownership of an issue or merge request to another user to disclose that user's private token, email token, email address, and encrypted OTP secret. Reporter-level access to a GitLab project is required to exploit this flaw.

This vulnerability is the result of a bug in the serialization of a user object and was introduced in GitLab 8.7.0. Please see the issue for more details.

This issue has been assigned CVE-2017-0882.

Versions affected

• 8.7.0 through 8.15.7

• 8.16.0 through 8.16.7

• 8.17.0 through 8.17.3

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

Post-Upgrade Steps

Due to the nature of this vulnerability it is possible that sensitive user tokens have been cached by proxies or web browsers. We therefore recommend that administrators reset private tokens and incoming email tokens for all users. A rake task for performing token resets is included with this announcement.

Encrypted One-Time Password (OTP) secrets may also have been leaked by the vulnerability. These secrets are encrypted, require the key for decrypting the secret, and cannot be used on their own without a copy of the user password, however we are still recommending that all users who utilize One-Time Passwords disable and then re-enable their 2FA for all GitLab instances. This will reset the OTP secret.

Rake Task for Resetting User Tokens

After upgrading we recommended that all GitLab installations reset all user private tokens and email tokens. To do so please save the following rake task in the appropriate location.

For Omnibus: /opt/gitlab/embedded/service/gitlab-rails/lib/tasks/reset_token.rake

For Source: <gitlab_installation_dir>/lib/tasks/reset_token.rake

# lib/tasks/reset_token.rakerequire_relative'../../app/models/concerns/token_authenticatable.rb'STDOUT.sync=truenamespace:tokensdodesc"Reset all GitLab user auth tokens"taskreset_all: :environmentdoreset_all_users_token(:reset_authentication_token!)enddesc"Reset all GitLab email tokens"taskreset_all_email: :environmentdoreset_all_users_token(:reset_incoming_email_token!)enddefreset_all_users_token(token)TmpUser.find_in_batchesdo|batch|puts"Processing batch starting with user ID: #{batch.first.id}"batch.each(&token)endendendclassTmpUser<ActiveRecord::BaseincludeTokenAuthenticatableself.table_name='users'defreset_authentication_token!write_new_token(:authentication_token)save!(validate: false)enddefreset_incoming_email_token!write_new_token(:incoming_email_token)save!(validate: false)endend

Omnibus users would then run:

sudo gitlab-rake tokens:reset_allsudo gitlab-rake tokens:reset_all_email

Source users would run:

sudo -u git -H bundle exec rake tokens:reset_all RAILS_ENV=productionsudo -u git -H bundle exec rake tokens:reset_all_email RAILS_ENV=production

The rake file can be deleted after this task finishes.

Workarounds

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

Securing via patch

To temporarily patch just the critical vulnerability, change to the appropriate directory and apply the attached diff.

Omnibus:

$ cd /opt/gitlab/embedded/service/gitlab-rails/$ git apply <path_to_diff>$ sudo gitlab-ctl restart unicorn

Source:

$ cd <gitlab_installation_dir/$ git apply <path_to_diff>

Patch:

diff --git a/app/controllers/projects/issues_controller.rb b/app/controllers/projects/issues_controller.rbindex 1151555..857d907 100644--- a/app/controllers/projects/issues_controller.rb+++ b/app/controllers/projects/issues_controller.rb@@ -129,7 +129,7 @@ class Projects::IssuesController < Projects::ApplicationController       end       format.json do-        render json: @issue.to_json(include: { milestone: {}, assignee: { methods: :avatar_url }, labels: { methods: :text_color } }, methods: [:task_status, :task_status_short])+        render json: @issue.to_json(include: { milestone: {}, assignee: { only: [:name, :username], methods: [:avatar_url] }, labels: { methods: :text_color } }, methods: [:task_status, :task_status_short])       end     enddiff --git a/app/controllers/projects/merge_requests_controller.rb b/app/controllers/projects/merge_requests_controller.rbindex 82f9b6e..677a8a1 100644--- a/app/controllers/projects/merge_requests_controller.rb+++ b/app/controllers/projects/merge_requests_controller.rb@@ -308,7 +308,7 @@ class Projects::MergeRequestsController < Projects::ApplicationController       end       format.json do-        render json: @merge_request.to_json(include: { milestone: {}, assignee: { methods: :avatar_url }, labels: { methods: :text_color } }, methods: [:task_status, :task_status_short])+        render json: @merge_request.to_json(include: { milestone: {}, assignee: { only: [:name, :username], methods: [:avatar_url] }, labels: { methods: :text_color } }, methods: [:task_status, :task_status_short])       end     end   rescue ActiveRecord::StaleObjectError

Verifying the workaround

1. Browse to a project

2. Open the project's issue tracker

3. Create an issue and assign ownership of the issue to another user

4. View the returned JSON and verify that no private information such as tokens are included

Other fixes in 8.17.4, 8.16.8, and 8.15.8

SSRF when importing a project from a Repo by URL

GitLab instances that have enabled project imports using "Repo by URL" were vulnerable to Server-Side Request Forgery attacks. By specifying a project import URL of localhost an attacker could target services that are bound to the local interface of the server. These services often do not require authentication. Depending on the service an attacker might be able craft an attack using the project import request URL.

This update blocks all import attempts from localhost and all bound server interfaces other than those assigned as GitLab web or SSH services (Typically ports 22 and 443). This update also blocks all import attempts from TCP ports below 1024 with the exception of ports 22, 80 and 443. 17286

Thanks to Strukt via HackerOne for reporting this vulnerability.

Links in Environments tab vulnerable to tabnabbing

edio via HackerOne reported that user-configured Environment links include target=_blank but do not also include rel: noopener noreferrer. Anyone clicking on these links may therefore be subjected to tabnabbing attacks where a link back to the requesting page is maintained and can be manipulated by the target server.

This update also includes patches for several other locations that might be vulnerable. 29081

Accounts with email set to "Do not show on profile" have addresses exposed in public atom feed

Several GitLab users reported that even with "Do not show on profile" configured for their email addresses those addresses were still being leaked in Atom feeds if they commented on a public project. 28058

Elasticsearch returns internal code, snippets, issues, wiki pages and MRs on public projects (EE only)

GitLab-EE Users have reported that when Elasticsearch was enabled for searching GitLab instances data from internal or private projects may be leaked in searches. 1067

All GitLab-EE instances with Elasticsearch enabled should run a rake task post-installation to configure privilege levels for Elasticsearch data.

Note: There is a bug in the rake task deployed with this security release. Users wishing to run this task should wait for GitLab 9.1 or apply the patch included with this merge request.

Omnibus users:

sudo gitlab-rake gitlab:elastic:add_feature_visibility_levels_to_project

Source users:

sudo -u git -H bundle exec rake gitlab:elastic:add_feature_visibility_levels_to_project RAILS_ENV=production

Upgrade barometer

These versions do not include any migrations and will not require 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-migrationsfile.

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.