Skip to content

Possible exposure of internal services via Kubernetes integration

Seems like a possible redux of https://gitlab.com/gitlab-org/gitlab-ce/issues/51490

Steps to reproduce (locally) :

  1. Get GitLab Ultimate plan so that we can access Pod Logs feature
  2. Create a new Project
  3. Create a new Environment. Enter any name, leave URL blank
  4. This will redirect to the environment page : /root/test-pod-log/environments/21
  5. Create a Kubernetes cluster. For API URL, enter the server, e.g. http://localhost:3123
  6. Start two servers.
  • while true; do { cat redirect.html; } | nc -l 3123; done
  • while true; do { echo -e 'HTTP/1.1 200 OK\r\n'; cat test.json; } | nc -l 1234; done
  1. Go to the following URL : /root/test-pod-log/environments/21/logs.json

You will now see the contents of test.json as :

Screen_Shot_2018-10-26_at_12.16.23_AM

{"logs":["CAT"],"pods":[]}

In theory we can easily redirect to say, http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true&alt=text

Resources

$ cat redirect.html
HTTP/1.1 302
Location: http://localhost:1234/
$ cat test.json
CAT

Fix

We will monkey patch kubeclient gem to not follow redirects.

This fix is working and tested in https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2575

And we have a production patch ready in https://dev.gitlab.org/gitlab/post-deployment-patches/merge_requests/110

Security issue: https://dev.gitlab.org/gitlab/gitlabhq/issues/2721

Edited by Mayra Cabrera