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.
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.
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.
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.
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.
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.
This vulnerability, when present, lets an attacker load an arbitray 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 occurences of unsafely passing a value directly from
render in any released version of GitLab.
It is unlikely that any released version of GitLab is affected by this vulnerability.