FlawOpen

flawopen.com/AI Security/plugin4shell-ai-agent-plugin-sha-pin-bypass

● CWE-345 · Haute
Recherche · FlawOpen

Plugin4Shell : contournement du pin SHA

Quatre installateurs de plugins IA fixaient la révision Git sans vérifier le commit extrait. Plugin4Shell révèle le défaut : contrôlez le SHA final.[1]

💡 Explication en Langage Simple (ELI5)

Une bibliothèque réserve une édition précise d’un livre avec son numéro de catalogue unique. L’employé demande ce numéro, mais accepte un autre livre si une étiquette de rayon porte le même texte. Le pin SHA est ce numéro de catalogue ; l’installateur doit vérifier le commit réellement extrait avant de faire confiance au plugin ou de l’exécuter.[1]

Concepts Clés et Termes

Commit SHA
Empreinte qui identifie un objet commit Git précis. Un pinning sûr compare le checkout résolu à cette valeur.[1], [2]
Ambiguïté de ref Git
Git accepte des identifiants d’objet et des noms comme les branches comme expressions de révision. Dans certains cas, un nom ressemblant à un identifiant de commit peut désigner une ref.[1]
Marketplace de plugins
Catalogue qui distribue des extensions d’agent et peut enregistrer une révision vérifiée. Le client d’installation doit toujours faire respecter le pin.[1]
CWE-345
Vérification insuffisante de l’authenticité des données : le système utilise des données sans confirmer suffisamment qu’elles correspondent à la valeur attendue.[5]

Correspondances de référentiels

  • Référence CWE pour la faiblesse décrite dans ce guide : CWE-345

Déroulement de l'Attaque Étape par Étape

Étape 1

Le marketplace enregistre un commit vérifié

Une entrée de plugin désigne un dépôt et un SHA de commit précis que l’installateur est censé utiliser.[1]

Étape 2

Le propriétaire du dépôt peut modifier les refs

AIR Security rapporte que, sur les hébergeurs qui autorisent ces noms, le contrôleur du dépôt peut créer une branche par défaut portant le même nom que le SHA demandé. Pour Gemini CLI, la recherche décrit séparément un chemin de résolution par la ref FETCH_HEAD.[1]

Étape 3

L’installateur extrait sans vérifier HEAD

Avant le correctif, Codex transmettait le SHA demandé à <code>git checkout</code> et considérait la réussite de Git comme la preuve que le pin avait été respecté.[1], [2]

Étape 4

Le client accepte ou rejette l’arbre obtenu

Le correctif de Codex lit <code>git rev-parse HEAD</code> après le checkout et s’arrête en cas d’écart. Sans contrôle équivalent, du code substitué peut être installé et exécuté avec les permissions de l’utilisateur de l’agent.[2], [1]

Code Source : Vulnérable vs Sécurisé

Le chemin vulnérable confondait la résolution réussie d’un nom avec la preuve de l’identité de l’objet. Le patch compare le HEAD obtenu au pin du marketplace et refuse un autre commit. Cette comparaison reflète le correctif Codex ; les autres produits avaient des installateurs différents et il ne faut pas leur attribuer automatiquement ce même correctif.[2], [6]

IMPLÉMENTATION VULNÉRABLE
// Forme antérieure au correctif du PR #34644 d’OpenAI Codex
if let Some(target) = sha.or(ref_name) {
    run_git(&["checkout", target], Some(destination))?;
}
// Un checkout réussi était considéré comme la preuve que le SHA correspondait.
PATCH SÉCURISÉ ET ROBUSTE
// Correctif Codex : vérifier le commit résolu, pas seulement l’argument demandé
if let Some(sha) = sha {
    run_git(&["checkout", sha], Some(destination))?;
    let checked_out_sha =
        run_git_output(&["rev-parse", "HEAD"], Some(destination))?;
    if !checked_out_sha.eq_ignore_ascii_case(sha) {
        return Err(format!(
            "checked out Git SHA {checked_out_sha} does not match requested SHA {sha}"
        ));
    }
} else if let Some(ref_name) = ref_name {
    run_git(&["checkout", ref_name], Some(destination))?;
}

Liste de Contrôle de Sécurité pour l'Ingénierie

Sources

← AI Security Directory →