abraxas/gitlab-gitea-import-ssrfGitLab - Élevé - SSRF d'import HTTPS Gitea - Abandon du pin UrlBlocker
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · gitlab-gitea-import-ssrf
GitLab CE 19.4.1 - GitLab Inc.
L'import Gitea appelle UrlBlocker.validate! une fois, puis pour https jette l'URI épinglée à l'IP et transmet à Faraday le nom d'hôte d'origine. Octokit UrlValidation valide à nouveau et ne réécrit pas env[:url]. Rebind le nom entre ces recherches et GitLab fait un GET sur la loopback comme s'il s'agissait de Gitea. Le JSON de la liste des dépôts revient sur GET /import/gitea/status.json. Les imports HTTP conservent l'épinglage. https://127.0.0.1 direct est bloqué.
Un utilisateur connecté qui peut ouvrir l'import Gitea sur son namespace personnel peut faire récupérer par GitLab un hôte qu'il rebind vers la loopback, et il obtient le corps de la réponse.
| ID | pas encore de CVE |
| CWE | CWE-918, CWE-367 |
| CVSS | Élevé : 7.7 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N |
| Produit | GitLab CE |
| Affecté | 19.4.1-ce.0 (26212baacadb sur l'arbre v19.4.1-ee) |
| Auth | utilisateur authentifié, import Gitea, namespace personnel |
| Licence | GNU Affero GPL v3.0 |
| Lab | 127.0.0.1 uniquement |
Définir l'URL de l'hôte Gitea sur https://<nom-qu-il-contrôle>/. UrlBlocker autorise le premier enregistrement A public. Les client_options HTTPS conservent ce nom d'hôte. Rebind vers 127.0.0.1. Faraday fait un GET sur le catcher via la loopback du worker GitLab. provider_repos dans status.json correspond à ce que le catcher a renvoyé.
Sur un omnibus tout-en-un, cela concerne Workhorse, Puma, les exporters et tout ce qui écoute sur le worker. Pas de RCE sur l'hôte. Pas non authentifié. L'URL d'hôte HTTP reste sur l'IP épinglée.
Même produit, restes similaires : Gitaly fetch omet resolved_address, webhook 0.0.0.0/8.
J'ai d'abord lu les notes de patch du 23 septembre 2026 pour 19.4.1 / 19.3.3 / 19.2.7, puis l'arbre v19.4.1-ee. Le RCE par regex dans la CI, le XSS dans le diff de MR, la lecture file.path de Workhorse sont fermés sur ce pin. L'SSRF d'import n'était pas terminé.
Import::GiteaController#client_options est le reste :
host: verified_url.scheme == 'https' ? provider_url : verified_url.to_s,
HTTP utilise verified_url (IP). HTTPS utilise provider_url (le nom saisi par l'utilisateur). LegacyGithubImport::Client construit l'api_endpoint Octokit à partir de cet hôte. Gitlab::Octokit::UrlValidation appelle validate! puis @app.call(env) sans réécriture.
J'ai déployé l'image standard gitlab/gitlab-ce:19.4.1-ce.0. Requêtes locales désactivées. CA du lab dans /etc/gitlab/trusted-certs car ssl.verify de Faraday est à true. DNS pour gitea.lab : les recherches 1-2 renvoient 1.1.1.1, les recherches suivantes renvoient 127.0.0.1. Le catcher partage le netns de GitLab sur :443. GET /import/gitea/status.json a renvoyé provider_repos nommé GITLAB-GITEA-IMPORT-SSRF-WITNESS. Log du catcher : GET /api/v1/user/repos peer=127.0.0.1 host=gitea.lab.
https://127.0.0.1/ direct : « Specified URL cannot be used ». http://gitea.lab/ en HTTP est resté sur le pin et n'a pas renvoyé le witness.
Fausses pistes déjà consignées : /users/sign_in avec Accept: application/json renvoie 404 (le HTML renvoie 200) ; le mot de passe seed CveLabRoot9! est rejeté car il contient root ; le bind-mount de la CA en ro donne EROFS après que la reconfiguration a lié le fichier ; les deux premières recherches puis la loopback à la recherche 2 font que UrlValidation bloque avant que Faraday ne se connecte. Le mode pairs (impair public, pair loopback) est ce qui a fonctionné. Un reverse shell. Du théâtre. L'oracle est le witness dans status.json plus le peer du catcher.
cd lab
./run.sh
Cible uniquement http://127.0.0.1:18400. GitLab CE demande plusieurs Go de RAM. Le premier démarrage est lent. Lab autorisé uniquement.
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
Utiliser verified_url.to_s pour https de la même manière que HTTP le fait déjà. Réécrire env[:url] dans Octokit UrlValidation vers l'IP épinglée.
gitea_controller.rb · legacy_github_import/client.rb · octokit/url_validation.rbGNU Affero GPL v3.0. Voir LICENSE. Lab loopback uniquement. Aucune garantie.