GitLab is built using the Ruby on Rails framework. The team behind Ruby on Rails has recently announced 9 possible security vulnerabilities.
This means that some of these Rails vulnerabilities could potentially be exploitable in GitLab.
We have released GitLab 8.4.1 to address these vulnerabilities.
Update: we have amended this blog post with more detailed information about the impact on GitLab.
None of yesterday's Rails vulnerabilities has been confirmed to affect any version of GitLab. However, due to the large number of Rails vulnerabilities and the large number of GitLab versions that could theoretically be affected it is hard for us to say anything definitive.
The simplest and safest thing to do is to upgrade to GitLab 8.4.1 or newer. In that version we are using a version of Rails 4.2 which is patched against all of the Rails vulnerabilities announced yesterday.
It is hypothetically possible that CVE-2016-0752 affects some version of GitLab prior to 8.4.1. If this is the case it could be bad because CVE-2016-0752 has the potential to be used for remote code execution. However we have been unable to find signs that any version of GitLab is affected by this vulnerability.
There are also three XSS vulnerabilities in the yesterday's set. We do not seem to be affected by them but it is not impossible. Generally speaking, the older your GitLab version, the more likely it has some (known) XSS vulnerability.
Below we will go into some more detail of the possible impact of yesterday's Rails vulnerabilities on GitLab.
Because a code execution vulnerability, if present, is very severe, we advise you to upgrade to 8.4.1 to prevent possible issues.
If you are an Enterprise Edition subscriber, please contact support with any questions.
Impact on GitLab
CVE-2015-7576 Timing attack vulnerability in basic authentication in Action Controller
GitLab does not use the HTTP Basic Authentication implementation from Action Controller. In addition we have had rate limiting on HTTP Basic endpoints since GitLab 7.6.
CVE-2016-0751, CVE-2015-7581 Denial of service
Both of these denial of service vulnerabilities involve memory exhaustion. Because GitLab has been using unicorn-worker-killer since GitLab 6.4 it is unlikely that these vulnerabilities can be exploited against GitLab. Note that the same may not be true if you use GitLab with a custom Ruby web server such as Puma or Passenger.
CVE-2015-7578, CVE-2015-7579, CVE-2015-7580 XSS vulnerabilities
It is hard to tell if GitLab is vulnerable to any of these. From the vulnerability disclosures we receive we do know that we have been and continue to be probed for XSS a lot.
CVE-2015-7577 Nested attributes rejection proc bypass in Active Record
This vulnerability needs a special allow_destroy: false
setting which
was not shipped in any existing GitLab version. In other words
it does not affect GitLab.
CVE-2016-0753 Possible Input Validation Circumvention in Active Model
This vulnerability only affects Rails 4 and newer, and the 'Strong
Parameters' paradigm introduced in Rails 4 counteracts it. GitLab uses
Rails 4 since version 7.1.0. None of the GitLab versions released since
7.1.0 use the ActiveRecord permit!
method in an unsafe way. It is very
unlikely that any released version of GitLab is affected by this
vulnerability.
CVE-2016-0752 Possible Information Leak Vulnerability in Action View
This vulnerability, when present, lets an attacker load an arbitrary file on disk to be interpreted by Rails as a template. Combined with user uploads (which GitLab offers) this creates the potential for remote code execution.
It is hard to search for this vulnerability in source code because
untrusted input may be assigned to a variable in one place, with the
variable being passed to render
in another place. We have not found
occurrences of unsafely passing a value directly from params
to render
in any released version of GitLab.
It is unlikely that any released version of GitLab is affected by this vulnerability.
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