Github blokerer for forsøg på at snyde SHA-1

21. marts 2017 kl. 11:323
Github blokerer for forsøg på at snyde SHA-1
Illustration: Screendump.
Den teknik, som kan bruges til at skabe kollisioner med SHA-1, efterlader et aftryk, som kan spores. Det tjekker Github nu for, så Git-objekter på Github ikke kan angribes.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Det er i teorien muligt at få sneget ondsindet kode ind i et open source-projekt, som benytter versionsstyringsværktøjet Git, fordi Git benytter hashalgoritmen SHA-1, som der for nylig er blevet demonstreret en metode til at skabe kollisioner med.

Derfor har Github, som bruges af mange til at lagre og administrere deres Git-projekter og kode, nu implementeret en teknik, som skal beskytte mod denne type angreb.

En hashalgoritme generer en værdi af en fast størrelse ud fra et input af en vilkårlig størrelse. Det bruges blandt andet til at kontrollere, at en fil er intakt, når man kopierer den til et backup-system.

En god hashalgoritme gør det meget usandsynligt, at to forskellige filer giver samme hashværdi, men det ligger samtidig i hashfunktionen, at der er meget færre mulige hashværdier, end der er mulige input.

Artiklen fortsætter efter annoncen

Udfordringen, og dermed også sikkerheden i en hashfunktion, er, at det er meget vanskeligt at finde frem til to input, der giver samme hashværdi.

Demonstreret af Google

Angrebet mod SHA-1, som blev demonstreret i praksis af Google, indebærer en teknik, hvor man netop prøver at skabe en fil, der giver samme hashværdi som en bestemt fil. Teknikken betyder, at man tilføjer data til den nye fil og forsøger at ramme hashværdien.

Det er meget vanskeligt og kræver store mængder regnekraft, men det er mange gange lettere end det helt generelle brute-force-angreb mod SHA-1.

Til gengæld efterlader metoden et aftryk i den nye fil, og det er dette aftryk, som Github nu vil kigge efter ud fra en detektionsmetode, som er udviklet af Marc Stevens, hvis arbejde var med til at danne grundlag for det SHA-1-angreb, som er blevet demonstreret.

Github skriver, at der ikke er fundet nogen tegn på, at det teoretiske angreb er blevet udnyttet i praksis mod nogen Git-repositories på Github.

Et angreb via SHA-1-kollision mod Git er også lidt vanskeligt, fordi det kræver, at man kan overbevise én af de brugere med adgang til at acceptere commits om, at den kompromitterede version er dén, der skal bruges.

Udviklerne bag Git-værktøjet arbejder på at udfase SHA-1, der lige nu er hardcodet ind i Git som eneste hashalgoritme, så det bliver muligt at skifte til en nyere algoritme, der ikke er sårbar, og så det også i fremtiden bliver lettere at skifte algoritme, hvis de nye algoritmer alligevel viser sig at være sårbare.

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
22. marts 2017 kl. 09:41

Fordi Linus godt kan være lidt tung at diskutere med om den slags.

Han blev gentagne gange advaret helt tilbage da Git blev lanceret om at han skulle tag'e sine hashes med hvilken algoritme, men næhh-nej, det var bare spild af plads og X.509 i forklædning.

1
21. marts 2017 kl. 23:07

Vi har vidst at det bare var et spørgsmål om tid, før der blev fundet SHA-1 kollisioner, i flere år. Hvorfor er det først nu at git-udviklerne arbejder på en migration til en sikker hash?