[security] All jobs on a runner share the same bridge 0 network, and can be accessed from any job on that runner
Intuitively one might believe that for a gitlab job containing several different services, that gitlab creates a dedicated network in docker for these services to communicate with each other.
However that is NOT what happens. Docker uses the legacy --link functionality. As a consequence of this all the services are create on the "bridge 0" default network. The main script can communicate with any services it has spun up via their name, however ANY JOB can communicate with ANY SERVICE via IP address. Even ones started by different users for instance.
A malicious attacker could exploit this in the following way:
- Create a long running job on a shared runner. Either a gitlab.com shared runner or one elsewhere.
- Scan the ip address range of the instance for other IP addresses that that are listening on 3306 for MYSQL. For gitlab shared runners the CIDR seems to be 172.17.0.0/16 so 65535 different addresses (since you skip your own).
- Once you find an open MYSQL port, try and authenticate against it using a table of common passwords. People often set a insecure password for their CI tests, since they operate under the assumption that no outsider can access that mysql instance over the network.
- If you can establish a connection you can then steal data from a third party.
- Only allow shared runners to be accessed by trusted users (which kinda ruins the point of shared runners)
- Disable services for shared runners, at least for gitlab.com (eek)
- Very strongly suggest that people should use a strong password for any service they have in a gitlab job (i guess)
- Allow shared runners to only run one gitlab job at a time. (might already work like this, might not)
Migrate away from the depreciated docker link functionality towards a dedicated docker network per pipeline. This would also fix https://gitlab.com/gitlab-org/gitlab-ce/issues/61689
I can attempt to simulate this attack if you wish, but it wouldn't be responsible to attempt this on a gitlab.com shared runner.