GitLab permission leak Vulnerability, CVE-2017-0882）

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 OTP 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.rake
require_relative '../../app/models/concerns/token_authenticatable.rb'

STDOUT.sync = true

namespace :tokens do
  desc "Reset all GitLab user auth tokens"
  task reset_all: :environment do
    reset_all_users_token(:reset_authentication_token!)
  end

  desc "Reset all GitLab email tokens"
  task reset_all_email: :environment do
    reset_all_users_token(:reset_incoming_email_token!)
  end

  def reset_all_users_token(token)
    TmpUser.find_in_batches do |batch|
      puts "Processing batch starting with user ID: #{batch.first.id}"

      batch.each(&token)
    end
  end
end

class TmpUser < ActiveRecord::Base
  include TokenAuthenticatable

  self.table_name = 'users'

  def reset_authentication_token!
    write_new_token(:authentication_token)
    save!(validate: false)
  end

  def reset_incoming_email_token!
    write_new_token(:incoming_email_token)
    save!(validate: false)
  end
end

Omnibus users would then run:

sudo gitlab-rake tokens:reset_all
sudo gitlab-rake tokens:reset_all_email

Source users would run:

sudo -u git -H bundle exec rake tokens:reset_all RAILS_ENV=production 
sudo -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>

diff --git a/app/controllers/projects/issues_controller.rb b/app/controllers/projects/issues_controller.rb
index 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
     end
 
diff --git a/app/controllers/projects/merge_requests_controller.rb b/app/controllers/projects/merge_requests_controller.rb
index 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