Signerte Git-commits kan få ny hash og likevel vise Verified på GitHub
onsdag 8. juli · KI-generert · Kilde: The Hacker News
Vis forsiktighet med Verified-merket: en signert Git-commit kan flyttes til en ny hash som fortsatt viser Verified på GitHub, uten tilgang til signeringsnøkkelen.
Store deler av programvareverdenen behandler en signert commits hash som et unikt, permanent navn på innholdet. Ny forskning viser at det ikke stemmer, melder The Hacker News. Gitt en hvilken som helst signert commit kan noen uten nøkkelen lage en ny commit med samme filer, forfatter, dato og en gyldig signatur, og GitHub stempler den fortsatt Verified.
Alt en anmelder ser etter, stemmer. Bare hashen er en annen. Årsaken er signatur-malleabilitet: hashen regnes over alt i commit-en, inkludert de rå bytene i signaturen, og mange signaturer kan skrives om til en annen, men fortsatt gyldig form. For ECDSA-nøkler snur du signaturen med litt kurvealgebra (bytt verdien s med n minus s). For RSA og EdDSA legger du til et ekstra, ignorert felt i den delen signaturen ikke dekker. Rutene dekker alle GPG-skjemaene GitHub verifiserer, pluss S/MIME.
«hash chain malleability» — Jacob Ginesin, doktorgradsstudent ved Carnegie Mellon og kryptografi-revisor i Cure53
Den konkrete svakheten: blokkerer du en ondsinnet commit på hashen, kan en angriper dytte samme innhold på nytt under en fersk, fortsatt Verified hash som blokklista aldri har sett. Dedup, proveniens-logger og reproduserbare bygg som nøkler på hashen arver samme svakhet. Dette er ikke en måte å snike inn annen kode forbi en signatursjekk, filene er identiske. Det finnes ingen CVE og ingen leverandøradvarsel, og fiksen hører hjemme på forgens side.
Hva bør du gjøre?
- Ikke bruk en Verified commit-hash alene som unik, varig identitet i blokklister, dedup eller proveniens, den kan reproduseres.
- Pin innhold på hash der du trenger akkurat de bytene: det er fortsatt trygt, siden filene er identiske.