Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 54.9k
    • Issues 54.9k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1.5k
    • Merge requests 1.5k
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #30376
Closed
Open
Issue created Jul 23, 2019 by James Ritchey@jritcheyDeveloper

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

Edited Oct 20, 2022 by Pedro Pombeiro
Assignee
Assign to
Time tracking