Git Hash Chain Malleability

Sintesi Tecnica: Malleabilità della Catena di Hash Git

Problematica
Il documento mette in discussione l'invariante ampiamente accettata negli ecosistemi Git secondo cui un hash di un commit identifica in modo unico e immutabile una specifica porzione di contenuto firmato. Sebbene la documentazione di Git affermi che gli hash crittograficamente sicuri permettano a terze parti di fidarsi dell'hash come indirizzo per l'oggetto firmato e i suoi riferimenti, questo documento dimostra che tale assunzione fallisce per i commit firmati. Nello specifico, un attaccante senza accesso alla chiave di firma privata, e senza violare la funzione di hash sottostante (SHA-1 o SHA-256), può generere un oggetto commit distinto con lo stesso albero, metadati e messaggio, ma con un hash di commit differente. Fondamentalmente, questo commit modificato mantiene una firma valida e riceve il badge "Verified" da forge come GitHub. Poiché l'hash del commit è una funzione deterministica del contenuto serializzato (inclusi i byte della firma), alterare i byte della firma cambia l'hash. Questo fenomeno, definito "malleabilità della catena di hash" (hash chain malleability), permette a un attaccante di creare un commit "fantasma" che è funzionalmente identico all'originale ma possiede un identificatore differente, causando cambiamenti a cascata a tutti gli hash dei commit dipendenti nella catena.

Metodologia
L'autore identifica che il divario tra "una firma valida" e "questa specifica codifica della firma" permette la malleazione. Identifica tre tecniche distinte per sfruttare questo divario, ognuna delle quali prende di mira un diverso livello della rappresentazione della firma all'interno dell'oggetto commit Git:

1. Malleazione Matematica (ECDSA): Sfrutta la simmetria algebrica delle firme ECDSA. Per una firma $(r, s)$ su una curva di ordine $n$, la coppia $(r, n-s)$ è anch'essa una firma valida per lo stesso messaggio. L'autore modifica il valore $s$ nel pacchetto OpenPGP, rincodifica l'intero e aggiorna gli header della lunghezza del pacchetto. Ciò preserva la validità della firma pur alterando la sequenza di byte.
2. Malleazione Strutturale (RSA e EdDSA): Prende di mira la struttura del contenitore OpenPGP piuttosto che il valore della firma stessa. L'autore appende un sottopacchetto ben formato e non critico (tipo 100, privato/sperimentale) alla regione non hashata del pacchetto della firma. Secondo l'RFC 4880, la regione non hashata non è coperta dalla firma crittografica. Aggiungendo dati qui e regolando la lunghezza del pacchetto, la firma rimane valida, ma la rappresentazione in byte dell'oggetto commit cambia.
3. Malleazione di Codifica (S/MIME): Sfrutta la differenza tra DER (Distinguished Encoding Rules) e BER (Basic Encoding Rules) in ASN.1. Le firme S/MIME sono strutture CMS che richiedono una codifica DER canonica. L'autore riscrive un campo di lunghezza all'interno dell'involucro CMS dalla sua forma breve canonica a una equivalente forma lunga non canonica (ad esempio, codificare la lunghezza 32 come 0x81 0x20 invece di 0x20). Sebbene ciò violi le rigide regole DER, rimane una validità BER. Il valore della firma e il contenuto firmato rimangono intatti, preservando la verifica.

Contributi Chiave

• Caratterizzazione delle Tecniche: Il documento definisce e dimostra tre percorsi di malleazione (matematica, strutturale e di codifica) che coprono tutti gli schemi di firma supportati dalla verifica GPG di GitHub (ECDSA, RSA, EdDSA e S/MIME/CMS).
• Validazione Lato Server: L'autore dimostra che queste non sono semplici anomalie dei parser locali. Il verificatore lato server di GitHub accetta tutte e tre le tecniche di malleazione. Di conseguenza, la forge emette record "Verified" indipendenti e persistenti sia per l'originale che per i commit malleati, basati sui loro hash distinti.
• Analisi dell'Impatto: Il documento analizza le conseguenze per i sistemi che si affidano agli hash dei commit come chiavi primarie indirizzabili tramite contenuto, tra cui:
  • Blocco basato su Hash: Gli strumenti di risposta agli incidenti che bloccano specifici hash di commit possono essere aggirati inviando il commit malleato "fantasma", che ha un hash diverso ma contenuto identico.
  • Pinning delle Dipendenze: Sebbene il pinning full-SHA (ad esempio, nei moduli Go o in Nixpkgs) mantenga l'integrità contro la sostituzione del contenuto, la malleabilità crea un aliasing a livello di contenuto firmato. I lockfile rigenerati da mirror potrebbero registrare l'hash "fantasma", portando a voci duplicate nella cache o a record di provenienza inconsistenti.
  • Build Riproducibili: I sistemi che trattano l'hash del commit come l'identificatore di revisione immutabile (ad esempio, SLSA Source Track, Sigstore Gitsign) risultano indeboliti. Un singolo pezzo di contenuto può generare molteplici ancoraggi "Verified" nei log di trasparenza, duplicando anziché difendere l'ancora di fiducia.
• Strumentazione Proof-of-Concept: L'autore fornisce una strumentazione open-source (interactive-malleator.py e setup-ghost.py) che automatizza queste tecniche, riscrive le catene di commit discendenti per mantenere la coerenza del grafo e verifica i risultati rispetto a forge locali e remote.

Risultati

• Verifica Locale: Tutte e tre le tecniche superano la verifica locale utilizzando git verify-commit per gli schemi basati su OpenPGP (ECDSA, RSA, EdDSA). Per S/MIME, i parser locali rigorosi (come gpgsm usando libksba) rifiutano la codifica DER non canonica, ma il parser più permissivo di GitHub la accetta.
• Accettazione da parte di GitHub: GitHub accetta tutti e tre i metodi di malleazione. La piattaforma non canonicalizza i contenitori di firma prima della verifica. Di conseguenza, un singolo commit logico può essere rappresentato da una famiglia illimitata di hash distinti nei byte, ciascuno contrassegnato come "Verified" e presentato come storia non correlata nelle viste di confronto (ad esempio, "1 commit avanti e 1 commit indietro").
• Persistenza: Lo stato "Verified" è duraturo. Anche se la chiave di firma viene ruotata o revocata, i commit malleati mantengono i loro record di verifica indipendenti perché la forge ancora il record allo specifico hash del commit, non al contenuto o allo stato della chiave.

Significatività
Il documento conclude che l'assunto che l'hash di un commit firmato e verificato sia un handle unico per uno specifico pezzo di contenuto è falso. L'attacco non si basa su collisioni di hash o falsificazione del contenuto, ma piuttosto sulla malleabilità della codifica della firma stessa. La significatività pratica è che i sistemi che si affidano agli hash dei commit per il blocco, il pinning delle dipendenze e la verifica delle build riproducibili sono vulnerabili all'equivocazione. L'autore sostiene che la fiducia non debba essere riposta nell'hash grezzo di un oggetto firmato la cui codifica è controllata da un avversario; al contrario, i sistemi devono canonicalizzare e verificare il contenuto prima di trattare l'hash come un identificatore unico. Il documento nota che, alla data di scrittura, il problema rimane non affrontato da Git o dalle principali forge Git.