#### 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](https://gitlab.com/gitlab-org/gitlab-ce/issues/29661) for more details.
This issue has been assigned [CVE-2017-0882](http://cve.mitre.org/cgi-bin/cvename.cgi?name=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
京公网安备 11010502034610号
暂无评论