FogBugz import attachment full SSRF requiring vulnerability in *.fogbugz.com

## Summary: Hi Team, a bit of a odd one here. The FogBugz import code uses `CarrierWave::Uploader::Base:download!` to download attachments from fogbugz.com when importing a FogBugz repository. `CarrierWave::Uploader::Base:download!` ultimately uses `Kernel.Open` to download the provided attachment URL. `Kernel.Open` permits URLs which resolve to, or redirect to `127.0.0.1`, making it vulnerable to SSRF issues. There is a check within the FogBugz import code which requires attachments to be downloaded with an `http` or `https` scheme from a fogbugz.dom subdomain: `app/services/projects/download_service.rb` ```rb WHITELIST = [ /^[^.]+\.fogbugz.com$/ ].freeze ... def valid_url?(url) url && http?(url) && valid_domain?(url) end def http?(url) url =~ /\A#{URI::DEFAULT_PARSER.make_regexp(%w(http https))}\z/ end def valid_domain?(url) host = URI.parse(url).host WHITELIST.any? { |entry| entry === host } end ``` If a vulnerability can be identified in a fogbugz.com subdomain which results in returning a crafted API response including an arbitrary attachment URL, a full read GET based SSRF would be exploitable on gitlab.com (or a gitlab instance). I've done some basic analysis on potential vulnerabilities which could trigger this issue, they include (but are by no means limited to): * URL parameter clobbering to force a 302 redirect on attachment download * Intercept and modify an unencrypted HTTP API response * Subdomain takeover / dangling sub domain to return an arbitrary API response * HTTP Request smuggling to modify an in-flight API response * Cache poisoning to poison a malicious API response * SQL Injection to replace an attachment URL * Code Execution to modify `api.asp` to return an arbitrary API response * Social engineering / malicious insider FogBugz employee Due to the third party nature of these issues it is not feasible to probe for, or disclose the potential existence of, any of these potential issues on fogbugz.com to GitLab. However, if any one of these issues exists now or in the future it would render gitlab.com vulnerable. ## Steps to reproduce: This issue can be simulated by placing an `/etc/hosts` entry on a GitLab server as follows: ``` 198.211.125.160 poc.fogbugz.com ``` This will point `poc.fogbugz.com` to a VPS I control, which responds with a crafted FogBugz API response designed to simulate the exploitation of a bug on a fogbugz.com domain. Importing the `SSRF Repository` FogBugz repository from this host will create a repository with a single issue which includes the SSRF result of requesting http://127.0.0.1:9090/api/v1/targets. {F1179855} ## Impact: A vulnerability in a fogbugz.com subdomain, which meets the above criteria, would result in a full GET based SSRF issue against gitlab.com. ## What is the current *bug* behavior? FogBugz import code uses `Kernel.Open` to download and store the result of an untrusted URL. ## What is the expected *correct* behavior? `GitLab::Http` should be used to download attachments to prevent SSRF attacks. ## Output of checks: ### Results of GitLab environment info ``` System information System: Ubuntu 20.04 Proxy: no Current User: git Using RVM: no Ruby Version: 2.7.2p137 Gem Version: 3.1.4 Bundler Version:2.1.4 Rake Version: 13.0.3 Redis Version: 5.0.9 Git Version: 2.29.0 Sidekiq Version:5.2.9 Go Version: unknown GitLab information Version: 13.8.1-ee Revision: e10a21e66ce Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 12.4 URL: http://188.166.97.195 HTTP Clone URL: http://188.166.97.195/some-group/some-project.git SSH Clone URL: [email protected]:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 13.15.0 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git ``` ## Impact A vulnerability in a fogbugz.com subdomain, which meets the above criteria, would result in a full GET based SSRF issue against gitlab.com.