Linus Torvalds: Himlen falder ikke ned på Git trods angreb mod hashfunktionen SHA-1

Illustration: leowolfert/Bigstock
Versionsstyringsprogrammet Git benytter den samme hashalgoritme, som Google og en forskergruppe netop har demonstreret et kollisionsangreb mod.

Git bør nok begynde at skifte til en mere sikker hashalgoritme end SHA-1. Så langt vil Linus Torvalds, skaberen af det udbredte versionsstyringsværktøj, gerne gå, men han maner alligevel til besindelse i en mail til Git-mailinglisten.

Google har i samarbejde med forskningsinstitutionen CWI i Holland demonstreret, at det er muligt at udføre et kollisionsangreb mod SHA-1-algoritmen. Det vil sige, at det er muligt at generere en tekst, der giver samme hashværdi, når den køres gennem SHA-1, som man får ud af en anden tekst.

Vel at mærke uden bare at prøve sig frem. Googles metode er 100.000 gange hurtigere end 'brute force', og krævede alligevel, hvad der svarer til 6.500 års beregninger, hvis man udført dem på én processorkerne.

Læs også: Google efter 6.500 CPU-år: Nu er kollisioner med SHA-1 virkelighed

»Jeg tvivler på, at himlen falder ned om ørerne på Git som versionsstyringsværktøj. Bør vi migrere til en anden hashalgoritme? Ja. Er det 'game over' for SHA-1, som folk siger? Formentligt ikke,« skriver Linus Torvalds.

Git benytter SHA-1 til at generere hashværdier for hver ændring, der laves i det, der ligger i et Git-repository. På den måde kan Git se, om to udgaver er ens, uden at skulle lave en sammenligning hver gang. Og i princippet kan hashværdien også bruges til at tjekke, at man har fat i den rigtige udgave.

Lettere med PDF

Med det menes også implicit, at man har fat i en udgave, som en ondsindet part ikke har ændret i. Googles metode kunne give anledning til, at man i et Git-repository med kode kunne ændre indholdet på en måde, hvorpå det både gjorde noget ondsindet og fik den samme hashværdi som den rigtige udgave.

Helt så let er det imidlertid ikke. Som Linus Torvalds påpeger, så har Google valgt at bruge dokumenter i PDF til demonstrationen, fordi PDF giver mulighed for at lave en fil med en fast dokumentheader samt noget indhold, der ikke bliver vist.

På den måde kan man lave mange forskellige mutationer af dokumentet, som for brugeren vil se normalt ud, men hvor der er ændret i skjult indhold for at få hashværdien til at blive noget bestemt.

Det er vanskeligere i Git, fordi Git også tager tekstens længde med i sin beregning. Man skal altså finde en kollision, hvor længden er den samme som før. Det var ikke nødvendigt i Googles PDF-forsøg, lyder forklaringen fra Linus Torvalds.

Læs også: Sådan kommer du i gang med at lære Git

Kollisioner vil udløse fejl

Det var Linus Torvalds, som skabte Git, men Git vedligeholdes i dag af Junio Hamano, som i samme tråd på mailinglisten henviser til et indlæg fra 2005 af Linus Torvalds. I indlægget forklarer Linus Torvalds, at selvom et kollisionsangreb mod SHA-1 skulle være muligt, så vil det være vanskeligt at bruge mod Git.

Versionsstyring bruges typisk til at give flere mulighed for at arbejde på de samme dokumenter - for Gits vedkommende især kildekode. Det betyder, at der som regel vil være flere kopier af indholdet.

Selv hvis man får ændret i master-kopien, som alle sender deres ændringer til og henter andres ændringer fra, så vil der være flere 'uskadte' kopier, der ligger hos de enkelte udviklere.

Linus Torvalds argument lød den gang, at det ville være usandsynligt, at man kunne skabe en ondsindet kopi, som ikke også ville indeholde nogle ændringer i forhold til tidligere versioner, som simpelthen ikke ville give mening.

Når en udvikler forsøgte at flette sine ændringer, lavet på den 'gode' kopi, sammen med den onde, ville der altså opstå fejl, som ville blive bemærket. Og selv hvis der ikke opstod synlige fejl, så ville det være muligt at markere den pågældende ondsindede version som ugyldig, når det på et tidspunkt blev opdaget.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Magnus Jørgensen

Iøvrigt skal de tegn der tilføjes til kildeteksten være udkommenteret som kommentarer og overholde reglerne for escape character sequences for den kode type der behandles og Man kan kun indsætte de bytes som kompiler/assembler/fortolker tillader.

Det er rimeligt utænkeligt at SHA-1 skulle være et problem for GIT.

  • 0
  • 0
Sune Marcher

Iøvrigt skal de tegn der tilføjes til kildeteksten være udkommenteret som kommentarer og overholde reglerne for escape character sequences for den kode type der behandles og Man kan kun indsætte de bytes som kompiler/assembler/fortolker tillader.


Husk på at Git tillader binære filer.

Et tænkeligt angreb (hvis det ellers passer med Gits datastrukturer) ville være at finde en interessant fil, og langt tilbage i historien indsætte en bagdørs-bug, som man har analyseret sig frem til ikke vil blive berørt at de næste 1000+ commits i history. Derudover tilføjer man en binær blob der får sha1'en for commiten til at passe, og erstatter repo med den taintede kopi. Eftersom sha1 passer, ødelægger man ikke "arvefølgen", og folk får ikke fejl når de pusher på deres nuværende commits.

Idéen skulle være at alle folk der arbejder med projektet har den gamle untainted fil checket ud, og ikke får den opdateret eftersom der ikke er ændringer - men et rent checkout på byggeserver ville få den taintede version.

Der er sandsynligvis nogle fejl i ovenstående scenarie, men pointen er ikke kun at tænke på modifikation+kollission direkte hvor man gerne vil have det, men hvor man ellers kan fifle...

(Derudover: ja, hvis du har force-push eller server-side fil-adgang til et main repository kan du muligvis lave værre ting end ovenstående :) )

  • 4
  • 0
Log ind eller Opret konto for at kommentere