Gitlab installations from source are affected by Bash CVE-2014-7169

A new vulnerability in Bash (CVE-2014-7169) 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.

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 [email protected], 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 [email protected] 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.

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