--- 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. ## 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 ```