---
title: "Gitlab installations from source are affected by Bash CVE-2014-7169"
date: 2014-09-25 14:00 CEST
categories: releases
author: Jacob Vosmaer
---

A [new vulnerability in Bash
(CVE-2014-7169)](http://www.openwall.com/lists/oss-security/2014/09/24/32) has
come to light in the aftermath of CVE-2014-6271. This new vulnerability can be
exploited by a malicious GitLab user to perform a denial of service attack
against the Git SSH access provided by GitLab on server where GitLab was
installed from source.

If the attacker does not have an account with an SSH key on your GitLab server
then they cannot exploit Bash CVE-2014-7169 via GitLab.

<!--more-->

## Affected versions

Bash vulnerability CVE-2014-7169 can be exploited against GitLab installations
where the default shell for `git` is Bash (or `sh` symlinked to Bash) AND the
`/home/git/gitlab-shell/bin/gitlab-shell` executable is writable for the `git`
user.

Omnibus-gitlab installations are not affected because there the `gitlab-shell`
executable is owned by `root` instead of `git`. Installations from source (e.g.
using the installation guide or cookbook-gitlab) may be affected if they expose
an unsafe version of Bash.

## Impact

CVE-2014-7169 lets an attacker trick the Bash parser into interpreting
`command1 command2` as `command2 > command1`. When a malicious GitLab user
initiates an SSH connection with a GitLab server on which their SSH key is
installed they can trigger the command reordering, but they cannot choose the
command that gets executed because that is determined in `authorized_keys` by
an OpenSSH `command="..."` directive.

Normally when a GitLab user connects to `git@gitlab.example.com`, the following
hard-coded command would be executed by OpenSSH:

```
/path/to/gitlab-shell key-123
```

The number 123 would be the database ID that GitLab associated with the SSH
key.

Because of CVE-2014-7169, a malicious user can turn the intended command into
`key-123 > /path/to/gitlab-shell`. This will give an error because there most
likely is no executable in the PATH named `key-123`.

On omnibus-gitlab installations the command will also give a second error
because the `git` user is not allowed to write to the `gitlab-shell` executable
file, and no harm is done.

On installations from source however, the `gitlab-shell` script is owned by the
`git` user. That means that in this situation the `gitlab-shell` script gets
truncated to 0 bytes. Now that the `gitlab-shell` executable is corrupted,
nobody can connect to `git@gitlab.example.com` for `git clone`, `git push` etc
anymore: we have a denial of service.

For clarity, we would like to repeat that this vulnerability can only be
exploited against GitLab by attackers with a GitLab user account and an SSH key
on your GitLab server.

## Mitigation

Until a new version of Bash is released you should [make sure the git user uses
a safer shell than Bash](/blog/2014/09/24/gitlab-shell-and-bash-cve-2014-6271/#workarounds).

## Detection

To see if your GitLab server is affected, first check the shell used by the `git` user:

```
ls -l $(getent passwd git | awk -F: '{print $7}')
```

If you see `bash`, you may be affected. You can test for the presence of the
Bash vulnerability as follows.

```
mkdir test-CVE-2014-7169
cd test-CVE-2014-7169
env X='() { (a)=>\' bash -c 'echo date'
# If this prints the current date you are affected. If it says
# 'cat: echo: No such file or directory' you are not affected.
cat echo
```

## Recovery

You can check and recover the gitlab-shell executable on the GitLab server as
follows in case somebody used this vulnerability against your server.

```
sudo su - git
cd /home/git/gitlab-shell

# Check if bin/gitlab-shell was modified
git status

# Restore bin/gitlab-shell if necessary
git checkout -- bin/gitlab-shell
```