Security vulnerability in gitlab-shell (CVE-2013-4546)

We have learned about a second remote code execution vulnerability in gitlab-shell. This issue was fixed in gitlab-shell 1.7.4, so users who updated gitlab-shell after our recent security announcement are not affected.

Remote code execution vulnerability in the repository import feature of older versions of GitLab

There is a remote code execution vulnerability in the repository import feature of older versions of GitLab. This vulnerability has been assigned the CVE identifier CVE-2013-4546.

Versions affected: 5.0, 5.1, 5.2, 5.3, 5.4, 6.0, 6.1, 6.2

Not affected: 4.2 and earlier

Fixed versions: 5.4.1, Community Edition 6.2.3, Enterprise Edition 6.2.0 (all using gitlab-shell 1.7.4)

Impact

When creating a new project a GitLab user can specify that a remote repository should be imported into the new project. In affected versions the import URL text field can be used to execute code on the GitLab server. Only authenticated users can create new projects and import repositories.

This vulnerability was fixed in gitlab-shell 1.7.4. All users running GitLab 5.4 or newer should verify that they are using gitlab-shell 1.7.4 or newer (cat /home/git/gitlab-shell/VERSION) and upgrade gitlab-shell immediately if necessary.

Releases

Gitlab-shell 1.7.4 is available from https://gitlab.com/gitlab-org/gitlab-shell and https://github.com/gitlabhq/gitlab-shell . To upgrade gitlab-shell it suffices to run sudo su git -c 'git fetch && git checkout v1.7.4' in /home/git/gitlab-shell .

Workarounds

If you are unable to upgrade you can disable the repository import functionality in GitLab by deleting the following code block from app/contexts/projects/create_context.rb and restarting GitLab:

# Import project from cloneable resource
if @project.valid? && @project.import_url.present?
  shell = Gitlab::Shell.new
  if shell.import_repository(@project.path_with_namespace, @project.import_url)
    # We should create satellite for imported repo
    @project.satellite.create unless @project.satellite.exists?
    @project.imported = true
    true
  else
    @project.errors.add(:import_url, 'cannot clone repo')
  end
end

Credits

Thanks to Remy van Elst https://raymii.org/ for reporting the vulnerability to us.

GitLab CE 6.2 and 5.4 security releases

We have just released GitLab CE 6.2.3, CE 5.4.1 and EE 6.2.0. These releases fix two critical security issues that allow remote code execution. Both remote code injection attacks are only possible if you are logged in as a user on the GitLab server. We advise everyone to upgrade immediately or apply the two workarounds described below. When you are on 6.2 you can use the universal update guide for patch versions to upgrade.

Remote code execution vulnerability in the code search feature of GitLab

There is a remote code execution vulnerability in the code search feature of GitLab. This vulnerability has been assigned the CVE identifier CVE-2013-4489.

Versions affected: 5.2, 5.3, 5.4, 6.0, 6.1, 6.2

Not affected: 5.1 and earlier

Fixed Versions: 5.4.1, 6.2.3

Impact

The Grit gem which serves as the Git backend for GitLab has an unsafe code path for internal use which allows strings to be evaluated by the Bourne shell. In affected versions, the GitLab code search feature exposes this unsafe code path to user input from the search box. Code search in GitLab is only available for authenticated users.

All users running an affected release should upgrade immediately or disable code search using the workaround below.

Releases

The 5.4.1 and 6.2.3 releases are available from https://github.com/gitlabhq/gitlabhq and https://gitlab.com/gitlab-org/gitlab-ce .

Workarounds

If you are unable to upgrade, you can disable code search by deleting the following line from app/contexts/search_context.rb and restarting GitLab:

result[:blobs] = project.repository.search_files(query, params[:repository_ref]) unless project.empty_repo?

Credits

Thanks to joernchen of Phenoelit for reporting the vulnerability to us.

Remote code execution vulnerability in the SSH key upload feature of GitLab

There is a remote code execution vulnerability in the SSH key upload feature of GitLab. This vulnerability has been assigned the CVE identifier CVE-2013-4490.

Versions affected: 5.0, 5.1, 5.2, 5.3, 5.4, 6.0, 6.1, 6.2

Not affected: 4.2 and earlier

Fixed versions: 5.4.1, 6.2.3

Impact

The gitlab-shell SSH access endpoint manages the authorized_keys file for the git user. When a user adds a public key using the GitLab web interface a gitlab-shell command is invoked to add the public key to authorized_keys. In affected versions, the public key text entered by the user is exposed to the Bourne shell in a way that can be exploited to achieve code execution as the git user. Only authenticated users can upload an SSH key.

All users running an affected release should upgrade gitlab-shell immediately.

Releases

Gitlab-shell 1.7.4, available from https://github.com/gitlabhq/gitlab-shell, fixes the vulnerability and has been tested with GitLab 5.4.1 and GitLab 6.2.3.

Workarounds

If you are using GitLab 5.0 or newer and you cannot upgrade to GitLab 5.4.1 or GitLab 6.2.3 you should apply the following edit to gitlab-shell.

--- a/lib/gitlab_keys.rb
+++ b/lib/gitlab_keys.rb
@@ -29,8 +29,7 @@ class GitlabKeys
   def add_key
     $logger.info "Adding key #{@key_id} => #{@key.inspect}"
     cmd = "command=\"#{ROOT_PATH}/bin/gitlab-shell #{@key_id}\",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty #{@key}"
-    cmd = "echo \'#{cmd}\' >> #{auth_file}"
-    system(cmd)
+    open(auth_file, 'a') { |file| file.puts(cmd) }
   end
 
   def rm_key

Credits

Thanks to Nigel Kukard of AllWorldIT for reporting the vulnerability to us.

GitLab CE 6.2 released!

Hello everyone!

Today we release a new minor GitLab version, with new features, bug fixes and stability improvements. GitLab is open source software to collaborate on code. The main feature of the 6.2 release is fully browsable public projects.

Public projects

As of version 6.2 a user can visit public project pages (files, issues, wiki, etc.) without having a GitLab account. Make sure you do not store private information in a public project wiki or issue tracker. :)

User profile

In this version, we have made significant changes to the user’s profile.

• You are able to upload your own avatar
• The current password is required when changing your password
• The password settings have moved to a separate page
• In order to change your email address you must confirm it

UI improvements

We have a fresh sign-in page for GitLab 6.2. :)

Admin page

And much more. Just update to GitLab 6.2 and enjoy!

This release’s most valuable person (MVP) is Steven Thonus for contributing the avatar upload feature.

Changes

Project:

• Public projects are visible from the outside
• PivotalTracker integration (Johannes Becker)
• Flowdock integration (Boyan Tabakov)

Profile:

• Require current password to change one
• User must confirm his email if signup enabled
• User must confirm changed email
• Avatar upload on profile page with a maximum of 200KB (Steven Thonus)

API:

• Feature: Search for projects by name to api (Izaak Alpert)
• Feature: Remove group
• Feature: Remove project
• Feature: Download repo archive (Izaak Alpert)

Security:

• Add more security specs
• Extended User API to expose admin and can_create_group for user creation/updating (Boyan Tabakov)
• Store the sessions in Redis instead of the cookie store
• Respect authorization in Repository API

Misc:

• Group owner or admin can remove other group owners
• Make default user theme configurable (Izaak Alpert)
• Update logic for validates_merge_request for tree of MR (Andrew Kumanyaev)
• Rake tasks for web hooks management (Jonhnny Weslley)
• Fixed relative links in markdown

---

Links

For a full list of changes see the CHANGELOG.

If you are setting up a new GitLab installation follow the Setup Guide.

For update instructions see the Update Guide.

For LDAP group support and more have a look at the feature list of GitLab Enterprise Edition. Access to GitLab Enterprise Edition is included with a GitLab.com subscription. No time to upgrade or maintain Gitlab yourself? GitLab.com also offers upgrade and installation services as part of a GitLab.com subscription or alternatively on a consultancy basis.

Updated on October 22 2013 to add the MVP and a description of GitLab in the opening paragraph.

GitLab Community Edition 6.1 released!

Hello everyone! Today we release a new minor GitLab version, with new features, bug fixes and stability improvements.

With GitLab 6.1 Community Edition you can now automatically close Issues using commit messages, see when an Issue was referenced in a commit or a comment, and add a description to a Merge Request. Moreover, Issue and Merge Request ID’s now start at 1 for each Project.

Automatically close issues using commit messages

When you create a commit with a message starting with ‘Fixes #1’ or ‘Closes #1’ and push it to master GitLab will close the issue you referred to. If you create a Merge Request targeting master with commits in it that will close Issues, GitLab will tell you which Issues will be closed.

See when an Issue was referenced in a commit or a comment

When you refer to an Issue in a commit message or a comment on a Merge Request or another Issue, GitLab shows you that the issue was referenced.

Issue and Merge Request ID’s start at 1 for each Project

The ID’s for Issues and Merge Requests now start at 1 for each Project. This means that bookmarked issue URL’s will change. Old issue URL’s are redirected to the new one if the issue ID is too high for an internal ID.

Add a description to a Merge Request

When you create a new Merge Request you can now add a description to it.

This release’s most valuable person (MVP) is Ash Wilson for contributing the automatic issue closing and issue reference linking features.

Changes

User Interface

• Project specific IDs for issues, mr, milestones
• Description field added to Merge Request
• Improved commit diff
• Link issues, merge requests, and commits when they reference each other with GFM (Ash Wilson)
• Close issues automatically when pushing commits with a special message
• Improve user removal from admin area
• Add event filter for group and project show pages
• Add links to create branch/tag from project home page
• Add public-project? checkbox to new-project view
• Improved compare page. Added link to proceed into Merge Request
• New landing page when you have 0 projects

API

• API: Sudo api calls (Izaak Alpert)
• API: Group membership api (Izaak Alpert)

Other

• Improved large commit handling (Boyan Tabakov)
• Rewrite: Init script now less prone to errors and keeps better track of the service (Rovanion Luckey)
• Invalidate events cache when project was moved
• Remove deprecated classes and rake tasks
• Send email to user when he was added to group

---

Links

For a full list of changes see the CHANGELOG.

If you are setting up a new GitLab installation follow the Setup Guide.

For update instructions see the Update Guide.

For LDAP group support and more have a look at the feature list of GitLab Enterprise Edition. Access to GitLab Enterprise Edition is included with a GitLab.com subscription. No time to upgrade or maintain Gitlab yourself? GitLab.com also offers upgrade and installation services as part of a GitLab.com subscription or alternatively on a consultancy basis.

GitLab 6.0 released!

Hi everyone!

Today we present a new major GitLab version. There are a lot of improvements to make GitLab even more awesome.

First and foremost are the improved groups.

From now on a group is not just a directory for projects. It also allows you to add users. After user is added to group – it automatically get access to all existing and new projects inside group. You can also have have multiple owners for a group who can manage members/projects. With this GitLab becomes more group oriented. That is why we no longer support global namespaces. Project can be part of group or user only.

Merge requests are now possible between a fork and the original project.

Another nice improvement comes from contributor Izaak Alpert. It allows you to use different workflow depending on your needs.

Still we have more things to present.

Now you can create or remove both git branches and tags with the GitLab UI.

It gives you ability to work with the web ui only. For example to create branch, fix something with the web editor and submit a Merge Request.

Also we polished our UI and made a lot of bug fixes.

Under the hood we refactored a lot of stuff and improved the performance. And one last piece of good news. The upgrade to 6.0 is not so complicated as it used to be for major versions. The only big change is that all projects must be part of a group or user. A bit of preparations, few commands – and you are running GitLab 6.

---

GitLab 6.0 will be the first release that will also be available in an Enterprise Edition, for more information please see the GitLab.com Blog

---

Links

For full list see CHANGELOG

For new setup follow Setup Guide

For update instructions see Update Guide

No time to upgrade or maintain Gitlab yourself? GitLab.com offers upgrade consulting services and support subscriptions.