Cause racine (3.6.23, lignes exactes)

Dans src/prefect/runner/storage.py :

Points d’injection (numéros de ligne de la version 3.6.23) :

• commit_sha :

  • pull_code() ~379 : ["git", "fetch", "origin", self._commit_sha]
  • pull_code() ~391 : ["git", "checkout", self._commit_sha]
  • _clone_repo() ~475 : ["git", "fetch", "origin", self._commit_sha]
  • _clone_repo() ~480 : ["git", "checkout", self._commit_sha]

• directories :

  • pull_code() ~360 : ["git", "sparse-checkout", "set", *self._directories]
  • _clone_repo() ~489 : ["git", "sparse-checkout", "set", *self._directories] (sans séparateur --)

Sur le chemin commit_sha, --upload-pack=<programme> est interprété par git fetch / git checkout comme le programme de pack à exécuter pour la connexion, donc le programme est exécuté localement sur la machine du worker. Ceci est vérifié de bout en bout (voir « Résultats vérifiés » ci-dessous).

Le chemin directories est une véritable injection d’arguments mais n’est pas un vecteur d’exécution de code via --upload-pack : git sparse-checkout set est une commande locale sans option --upload-pack, donc la charge utile est rejetée comme indicateur inconnu. Cette asymétrie se reflète dans le correctif en amont : commit_sha est rejeté de manière ferme, tandis qu’une entrée directories débutant par -- ne déclenche qu’un avertissement.

Fonctionnement de l’exploit

Le cœur est une astuce d’injection d’arguments Git sur le vecteur commit_sha.

1. Absence de validation. Dans la version 3.6.23, la valeur commit_sha est stockée textuellement (storage.py:181), sans autre vérification que l’exclusion mutuelle branch/commit_sha. Toute chaîne est acceptée.

2. Elle atterrit dans une position d’argument Git. Lorsque Prefect tire le code (pull_code() puis _clone_repo()), la valeur est placée dans une liste d’arguments Git :

Il s’agit d’une liste d’arguments (pas de shell), donc il n’y a pas d’injection de shell. Le défaut est qu’il n’y a pas de séparateur -- avant la valeur contrôlée par l’attaquant.

3. --upload-pack est interprété comme une option, non comme un argument. Git traite tout ce qui commence par - comme une option sauf si un séparateur -- le précède. La charge utile :

transforme la commande en :

--upload-pack=<programme> est une option légitime de git fetch / clone / ls-remote : elle nomme le programme que Git lance pour servir les packs. Lorsque le dépôt distant est local (file://) ou atteint via SSH/transport local, Git exécute ce programme sur la machine locale.

4. Résultat : exécution de code. Git lance /bin/sh -c '...' à la place du véritable assistant git-upload-pack, donc la commande de l’attaquant s’exécute sur le worker Prefect. Git échoue alors (sh ne parle pas le protocole Git), mais l’effet de bord (l’exécution de code) a déjà eu lieu, c’est pourquoi le PoC ignore l’exception résultante et ne vérifie que le fichier marqueur.

Pourquoi le nettoyage pré-test est important. Si la destination possède déjà un répertoire .git, Prefect emprunte le chemin « mise à jour du dépôt existant ». Le supprimer force le chemin complet _clone_repo(), qui a les appels fetch origin <valeur> + checkout <valeur> les plus directs, les meilleurs sites d’injection.

Pourquoi directories ne donne pas d’exécution de code. Cette valeur atterrit dans git sparse-checkout set <valeur>, une commande locale sans option --upload-pack, donc Git rejette la charge utile comme indicateur inconnu. C’est toujours une véritable injection d’arguments, mais pas un vecteur d’exécution de code avec cette charge utile.

Le correctif (3.6.25). commit_sha doit correspondre à ^[0-9a-fA-F]{4,64}$, donc une charge utile --upload-pack=... est rejetée avec ValueError: Invalid commit SHA au moment de la construction. Pour directories, le correctif ajoute le séparateur -- dans la commande Git (les valeurs ne peuvent plus être lues comme des options) ainsi qu’un avertissement.

Stratégie recommandée pour le PoC

1. Installez exactement prefect==3.6.23
2. Forcez le nettoyage du répertoire de destination avant chaque test (c’est la partie la plus importante)
3. Déclenchez via un appel direct à GitRepository(..., commit_sha=..., directories=...).pull_code()
4. Utilisez des marqueurs horodatés pour voir quel vecteur a fonctionné
5. Sur une version corrigée (>= 3.6.25), confirmez que le commit_sha malveillant est rejeté à la construction de GitRepository(...)

Configuration (environnement vulnérable)

Ou depuis les sources au tag vulnérable exact :

Exécuter le PoC

La méthode fiable et autonome (construit un dépôt local file:// et exécute les deux vecteurs) :

Vous pouvez aussi lancer poc.py directement :

Important : Git n’honore --upload-pack que sur les transports local et SSH. Contre le dépôt https par défaut, la charge utile est inerte, donc python poc.py ne signale aucun marqueur même sur la version vulnérable 3.6.23. Utilisez run_offline.sh (ou un POC_TARGET_REPO via file:// / ssh) pour voir l’exécution de code se déclencher réellement.

Le script effectue un nettoyage agressif (force_clean_destination) avant chaque vecteur afin d’atteindre de manière fiable le chemin de clonage (_clone_repo), qui effectue :

Charges utiles précises utilisées dans ce PoC (3.6.23)

commit_sha :

directories :

Ces valeurs atteignent les positions d’arguments brutes dans fetch / checkout et sparse-checkout set.

Résultats vérifiés

Reproduit de bout en bout, entièrement hors ligne (dépôt nu local file:// via run_offline.sh), sur Python 3.12 :

Contenu observé du marqueur lors de l’exécution vulnérable :

Nettoyage

Vérifier le correctif (sur >= 3.6.25)

Sur une installation corrigée, l’objet malveillant échoue à la construction, avant toute exécution Git :

Une entrée directories débutant par -- n’émet qu’un avertissement (la véritable protection est le séparateur -- ajouté à la commande Git).

Références

• Tag vulnérable : 3.6.23
• Commit du correctif : 6a9d9918716ce4ee0297b69f3046f7067ef1faae
• Parent avant correction : 21b2838054c7231cee8cbe196fdadc67ee6c1c6d

Utilisez de manière responsable (bien sûr !!! :PpPPpp) et uniquement sur des systèmes que vous contrôlez :-)