Sep 24, 2014 - Jacob Vosmaer

Gitlab-shell is affected by Bash CVE-2014-6271

Gitlab-shell is affected by Bash CVE-2014-6271. Learn more.

Today a security vulnerability in Bash (CVE-2014-6271) was announced that can be exploited against the OpenSSH daemon. On GitLab servers where the default shell of the git user is Bash (or Bash masquerading as sh) this allows for remote code execution as the git user for attackers who have uploaded their SSH key to GitLab via the GitLab web interface.

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

Update 19:09 CEST: Added a mailing list link with details about the Bash vulnerability.

Update 19:33 CEST: Explain that attackers need a GitLab account.

Update 2014-09-25 9:40 CEST: Emphasize that updating Bash is the solution.

Update 2014-09-25 15:00 CEST: Updated for CVE-2014-7169.


Asssuming your SSH key is in GitLab, you can test for this vulnerability with the following command:

ssh  [email protected] '() { ignored; }; /usr/bin/id'

On affected GitLab servers, the output will look like this:

uid=1001(git) gid=1001(git) groups=1001(git)

If you see Not allowed command instead, your GitLab server is not affected by this vulnerability.


To address this vulnerability you need to update Bash to a safe version on your system.

# Debian/Ubuntu
sudo apt-get update
sudo apt-get install bash

# Centos
sudo yum update bash
sudo /sbin/ldconfig

Note that your GitLab server may still be affected by Bash CVE-2014-7169 until new Bash packages get released by your OS distribution; consider making sure the git user does not use Bash as described below.


If it is not possible to update Bash to a safe version on your GitLab server you can change the shell of the git user to csh. Dash, which is installed on Debian/Ubuntu by default, is also an option. Please note that updating the shell of the git user protects GitLab, but not the rest of your system.

You can check which shell is used by the git user as follows:

$ ls -l $(getent passwd git | awk -F: '{print $7}')
lrwxrwxrwx 1 root root 4 Sep 24 18:08 /bin/sh -> bash

Note that in the example above, the git user is at risk because their shell is Bash.

As a workaround, we can make Csh the default shell for the git user.

# Debian/Ubuntu
sudo apt-get install csh

# Centos
sudo yum install csh

If you are using omnibus-gitlab, add the following line to /etc/gitlab/gitlab.rb and run sudo gitlab-ctl reconfigure:

user['shell'] = '/bin/csh'

If you are using an installation from source you can change the shell for the git user with the following command:

sudo chsh -s /bin/csh git

Now test if you are no longer vulnerable with the command listed above under 'Detection'.

If changing the shell of the Git user is not an option for some reason you can also defend against this vulnerability by adding git to the DenyUsers in /etc/ssh/sshd_config and restarting SSH. Note that this will disable Git push/pull access via SSH to your GitLab server.

DenyUsers git

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

Share your feedback

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert
Edit this page View source