
GitLab - Alto - SSRF nell'importazione HTTPS di Gitea - Rimozione del pin di UrlBlocker
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · gitlab-gitea-import-ssrf
Write-up: https://abraxaslabs.tech/research/gitlab-gitea-import-ssrf
GitLab CE 19.4.1 - GitLab Inc.
L'importazione Gitea chiama UrlBlocker.validate! una sola volta, poi per https scarta l'URI con IP fissato e passa a Faraday il nome host originale. UrlValidation di Octokit esegue una seconda validazione e non riscrive env[:url]. Se il nome viene riassociato (rebind) tra queste due risoluzioni, GitLab esegue una GET verso il loopback come se fosse Gitea. Il JSON dell'elenco dei repository viene restituito su GET /import/gitea/status.json. Gli import HTTP mantengono il pin. Un https://127.0.0.1 diretto viene bloccato.
Un utente autenticato che può aprire l'importazione Gitea sul proprio namespace personale può far sì che GitLab recuperi un host che egli riassocia al loopback, e ne ottiene il corpo della risposta.
| ID | nessuna CVE al momento |
| CWE | CWE-918, CWE-367 |
| CVSS | Alto: 7.7 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N |
| Prodotto | GitLab CE |
| Affetto | 19.4.1-ce.0 (26212baacadb sull'albero v19.4.1-ee) |
| Auth | utente autenticato, importazione Gitea, namespace personale |
| Licenza | GNU Affero GPL v3.0 |
| Lab | solo 127.0.0.1 |
Impostare l'URL host di Gitea su https://<nome-sotto-il-loro-controllo>/. UrlBlocker consente il primo record A pubblico. Le client_options HTTPS mantengono quel nome host. Riassociare (rebind) a 127.0.0.1. Faraday esegue una GET verso il catcher sul loopback del worker GitLab. provider_repos in status.json è ciò che il catcher ha restituito.
Su un'installazione omnibus all-in-one si tratta di Workhorse, Puma, gli exporter e qualsiasi altro servizio in ascolto sul worker. Non è RCE sull'host. Non è non autenticato. L'URL host HTTP resta sull'IP fissato.
Stesso prodotto, residui affini: il fetch di Gitaly omette resolved_address, webhook 0.0.0.0/8.
Ho letto prima le note di patch del 23 settembre 2026 per 19.4.1 / 19.3.3 / 19.2.7, poi l'albero v19.4.1-ee. Su questo pin sono chiusi RCE tramite regex nella CI, XSS nel diff delle MR e lettura di file.path in Workhorse. L'SSRF nell'importazione non era stato completato.
Import::GiteaController#client_options è il residuo:
host: verified_url.scheme == 'https' ? provider_url : verified_url.to_s,
HTTP usa verified_url (IP). HTTPS usa provider_url (il nome digitato dall'utente). LegacyGithubImport::Client costruisce l'api_endpoint di Octokit da quell'host. Gitlab::Octokit::UrlValidation chiama validate! e poi @app.call(env) senza alcuna riscrittura.
Ho avviato l'immagine standard gitlab/gitlab-ce:19.4.1-ce.0. Local-requests disattivato. CA del lab in /etc/gitlab/trusted-certs perché ssl.verify di Faraday è true. DNS per gitea.lab: le risoluzioni 1-2 restituiscono 1.1.1.1, le risoluzioni successive restituiscono 127.0.0.1. Il catcher condivide il netns di GitLab su :443. GET /import/gitea/status.json ha restituito provider_repos con nome GITLAB-GITEA-IMPORT-SSRF-WITNESS. Log del catcher: GET /api/v1/user/repos peer=127.0.0.1 host=gitea.lab.
Diretto https://127.0.0.1/ : "Specified URL cannot be used". HTTP http://gitea.lab/ è rimasto sul pin e non ha restituito il witness.
Vicoli ciechi già registrati: /users/sign_in con Accept: application/json restituisce 404 (l'HTML restituisce 200); la password seed CveLabRoot9! è stata rifiutata perché contiene root; il bind-mount della CA in ro dà EROFS dopo che la riconfigurazione collega il file; primi-due-poi-loopback alla risoluzione 2 fa bloccare UrlValidation prima che Faraday si connetta. La modalità a coppie (dispari pubblico, pari loopback) è quella che ha funzionato. Una reverse shell. Teatro. L'oracolo è il witness in status.json più il peer del catcher.
cd lab
./run.sh
Prendi di mira solo http://127.0.0.1:18400. GitLab CE richiede diversi GB di RAM. Il primo avvio è lento. Solo laboratori autorizzati.
status.json status=200 ... provider_repos ... GITLAB-GITEA-IMPORT-SSRF-WITNESS
catcher GET /api/v1/user/repos peer=127.0.0.1 host=gitea.lab status=200 witness=True
negative-a https://127.0.0.1 blocked
negative-b http://gitea.lab no-witness
SUCCESS GITLAB-GITEA-IMPORT-SSRF status.json mode=pairs http=200 GITLAB-GITEA-IMPORT-SSRF-WITNESS
def client_options
verified_url, provider_hostname = verify_blocked_uri
{
host: verified_url.scheme == 'https' ? provider_url : verified_url.to_s,
api_version: 'v1',
hostname: provider_hostname
}
end
Usa verified_url.to_s per https nello stesso modo in cui HTTP già fa. Riscrivi env[:url] in UrlValidation di Octokit con l'IP bloccato.
gitea_controller.rb · legacy_github_import/client.rb · octokit/url_validation.rbGNU Affero GPL v3.0. Vedi LICENSE. Solo laboratorio su loopback. Nessuna garanzia.