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

24. februar 2017 kl. 14:313
Linus Torvalds: Himlen falder ikke ned på Git trods angreb mod hashfunktionen SHA-1
Illustration: arkiv.
Versionsstyringsprogrammet Git benytter den samme hashalgoritme, som Google og en forskergruppe netop har demonstreret et kollisionsangreb mod.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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.

»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.

Artiklen fortsætter efter annoncen

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.

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.

3 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
3
25. februar 2017 kl. 14:55

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 :) )

1
24. februar 2017 kl. 16:57

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.