Possible SSRF web terminal advertise_address
Problem and impact
Assuming a malicious runner specifies an internal host for it's [session_server]
, GitLab will attempt to connect/make outbound request to internal address space if specified in advertise_address
.
Impact here is likely limited since it's only a simple blind GET request. Due to time constraints, further impact was not determined. Below shows the client (GitLab) closing the TLS connection due to my runner session server having a bad certificate, perhaps further investigation or properly signed cert by a CA could lead to further impact.
PoC
-
In runner
config.toml
:advertise_address = "127.0.0.1:7777"
-
Open a web terminal.
-
On GitLab host:
root@gitlab:/# ncat -lvnp 7777 --ssl Ncat: Version 7.70 ( https://nmap.org/ncat ) Ncat: Generating a temporary 1024-bit RSA key. Use --ssl-key and --ssl-cert to use a permanent one. Ncat: SHA-1 fingerprint: 4DFC C238 4B87 AD3D 5B6E 87FE 8D17 8CFE E761 03EC Ncat: Listening on :::7777 Ncat: Listening on 0.0.0.0:7777 Ncat: Connection from 127.0.0.1. Ncat: Connection from 127.0.0.1:34126. Ncat: Failed SSL connection from 127.0.0.1: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate
Proposed solution
Utilize current GitLab SSRF prevention library on user input hosts/URIs: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/url_blocker.rb
Edited by Pedro Pombeiro