Hlavní navigace

Git 2.13 přidává obranu proti kolizi SHA-1

Sdílet

Roman Bořánek 12. 5. 2017

Verzovací systém Git vyšel ve verzi 2.13. Asi nejzajímavější novinkou je obrana proti potenciální kolizi v hešovacím algoritmu SHA-1. Jde o reakci na nález výzkumníků z Googlu, kterým se podařilo vyrobit dva rozdílné soubory se stejným hešem. Obrana spočívá zkrátka v tom, že Git kontroluje, zda objekt nevykazuje známky použití techniky, kterou je teoreticky možné docílit kolize. Takové objekty odmítne.

Podobnou funkci nedlouho po nalezení první kolize implementoval GitHub. Přestože je vytvoření kolize možné, v současnosti zůstává nepraktické a nerealistické. Za a) tak lze učinit jen u některých souborů s příhodnou strukturou a za b) je k tomu stále potřeba velmi vysoký (a drahý) výpočetní výkon. Vývojáři Gitu už dříve avizovali, že v dlouhodobém plánu je přechod na silnější algoritmus.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 12. 5. 2017 16:39

    tnr (neregistrovaný) ---.cust.vodafone.cz

    Ja to plne chapu proc takove reseni. Ale s prominutim, je to ojeb misto reseni. Spravne reseni by bylo GIT upravit tak,aby tyto chyby byly resitelne i v budoucnu podporou ruznych hash algoritmu (tzn. napr. prvni cast hashe urci algoritmus, zbytek hash variabilni velikosti). Nebo treba zavest nastaveni hash algoritmu do repozitare.

    Neni to v soucasne dobe na programu dne, ale tech problemu s SHA1 bude pravdepodobne pribyvat, takze by to chtelo v GIT vyresit jednou a provzdy, aby to bylo proti vsem podobnym utokum odolne v budoucnu (tzn. nefixovat se na jeden hash algoritmus jedne delky).

  • 12. 5. 2017 16:42

    Ondra Satai Nekola

    Doufejme, ze k tomu dojde. Ale asi o neni nic, co se da udelat za mesic, dva a lepsi workaround ted nez perfektni reseni za rok. Pokud za rok opravdu k workaroundu dorazi i to perfektni reseni.

  • 12. 5. 2017 17:09

    tnr (neregistrovaný) ---.cust.vodafone.cz

    To jsem samozrejme cetl. Ale to neni reseni. Silnejsi algoritmus to bude na jak dlouho ? Na rok? 5 let ? Proste toto je neresitelny problem.

    A povazuji za chybu svazat navrh verzovaciho systemu s jednim konkretnim hashem bez moznosti jednoduche zmeny v budoucnu (i kdyby to bylo jen pro nova data ci repozitare, to az tak nevadi)...

  • 12. 5. 2017 17:16

    Filip Jirsák

    Rozhodně je to řešení problému „nalezených chyb v SHA-1 bude přibývat“. A když už se bude algoritmus měnit, dá se předpokládat, že se ta změna udělá tak, aby bylo možné později relativně snadno přejít zase na jiný algoritmus. Bylo by hloupé to tak neudělat, když už teď vývojáři vědí, že potřeba změnit algoritmus přijde dřív, než by člověk čekal.

  • 12. 5. 2017 20:53

    . . (neregistrovaný) ---.aoj.io

    nesmíš obecné konstatování brát doslova. Samozřejmě podle diskuzí na mailing listu je v plánu umožnit volbu algoritmu, již nechtějí drátovat napevno. Rádi by nejprve umožnili používat více algoritmů a být zpětně kompatibilní.

    Problém ale je, že git implementuje přímo řada třetích nástrojů a každá změna uložených struktur může být pro ně destruktivní.

  • 12. 5. 2017 18:00

    Vít Šesták

    Tento workaround by měl smysl, i kdyby nový hashovací algoritmus již byl do Gitu implementován. Tak jako tak, přechod na novější verzi Gitu ještě neznamená, že nebudeme mít staré repositáře s SHA1 a že se nikdo nebude pokoušet referencovat commity pomocí SHA1 (třeba protože to je v nějakém starším skriptu).

    Výměna algoritmu s sebou přináší pár otázek ohledně kompatibility a bezpečnosti, někdy jdou požadavky proti sobě:

    * Bude možné repositář s novým hashem použít se starým Gitem? IMHO to dává smysl pro čtení, ale ne moc pro zápis.
    * Bude nový repozitář defaultně používat nový hashovací algoritmus?
    * Budou staré repozitáře migrovány automaticky, nebo jen na vyžádání?
    * Když bude starý repozitář zmigrován, bude možné referencovat staré commity podle starých id?
    * Když bude starý repozitář zmigrován a ponecháme možnost referencovat commity starým id, vytvoří se pro novou hashovací funkci nový kompletní strom?

    Možná jsou některé otázky už zodpovězené, dost možná jsou tu naopak některé další otázky. Ale není to úplně triviální a špatně udělaný přechod může bezpečnost podkopat jak primárně, tak sekundárně skrze to, že kvůli nekompatibilitě nikdo nebude chtít upgradovat. Celkem chápu postoj „do it right rather than right now“.

  • 12. 5. 2017 18:03

    Filip Jirsák

    Možnost identifikovat commity starým ID by měla zůstat zachována, protože ID commitů se nevyskytují jen v samotném repozitáři, ale i na mnoha jiných místech – třeba v systémech pro sledování chyb, v logu buildů, často se jimi i identifikují verze.

  • 12. 5. 2017 18:26

    Vít Šesták

    Souhlas. Zároveň tu však je legitimní důvod chtít zakázat – pokud má id commitu zajišťovat integritu. Dovedu si představit nějakou globální volbu allowLegacySha1Com­mitIds, kterou si nastavím na false, pokud se chci ujistit, že nikde omylem nepoužívám sha1.

  • 12. 5. 2017 20:21

    Filip Jirsák

    O volbě hashovací funkce nikdy nemůže rozhodovat přispěvatel, to musí vždy udělat správce repository – jinak by to byla bezpečnostní díra a nebylo by nutné zavádět novou hashovací funkci. To zachování starých ID bylo myšleno tak, že ty staré commity budou dále dohledatelné i podle starých ID – které ale už nebudou mít funkci ID, ale jenom jakési poznámky. Navíc tohle ID by bylo nutné i kvůli přechodu distribuovaných repository na novou hashovací funkci – když budu mít u sebe naklonované repository a udělám nějaké commity, mezi tím vzdálené repository přejde na novou hashovací funkci, musím být schopen svoje commity navázat na nová ID commitu ve vzdáleném repository.

  • 12. 5. 2017 22:03

    Vít Šesták

    > O volbě hashovací funkce nikdy nemůže rozhodovat přispěvatel, to musí vždy udělat správce repository – jinak by to byla bezpečnostní díra

    No, bezpečnostní díra samo o sobě asi ne, ale přinášelo by to komplikace. A souhlasím, že by to bylo nešťastné řešením.

    Otázkou ale třeba je, jak moc automatizovaně se má přecházet. Nechat vše pod starou hashovací funkcí zní jako riziko, že spousta projektů nemigruje. Automatický převod na novou hashovací funkci zase zavání problémy s kompatibilitou, zejména pokud různí vývojáři budou mít různé verze Gitu… Není úplně sranda skloubit kompatibilitu, bezpečnost a automatický přechod.

    Možná to dopadne tak, že v jedné verzi Gitu bude nová hashovací funkce pro ty, kdo si ji vyžádají, později bude automaticky pro nové repozitáře, později začne Git doporučovat přechod a po čase začne automaticky migrovat.

    > staré commity budou dále dohledatelné i podle starých ID – které ale už nebudou mít funkci ID, ale jenom jakési poznámky

    Takže by to fungovalo jako druhé id, jen by se preferovalo používání nového id. A vyžadovalo by to dva stromy, jeden sha1 a druhý s novou hashovací funkcí. Pokud by tu byl starý hash uložený jen jako poznámka, šlo by k libovolnému id commitu pod 40 hexaznaků vytvořit libovolný obsah repozitáře. Což by zde situaci oproti dnešku zhoršilo, dnes je potřeba vhodná kolize SHA1, což si klade jisté (nejen finanční) nároky.

  • 12. 5. 2017 22:59

    . . (neregistrovaný) ---.aoj.io

    Podle některých vývojářů se to musí udělat ve více krocích, nejprve přidat podporu, počkat "pár let" a poté začít používat nové hash funkce. Kvůli decentralizaci si moc nedokážu představit, že hash alg. bude určovat správce repa, co pak bude dělat s PR? Bude nutit je povinně přecommitovat s jeho hashem?

    Linus se nechal slyšet, že chce zachovat 160 bitovou velikost hashe a ideálně i všechny současné structs.

    "I don't think you'd necessarily want to change the size of the hash.
    You can use a different hash and just use the same 160 bits from it."

    Prozatím sha1 dostačuje a tyhle plány jsou podle všeho na 10+ let dopředu. Ošetřit kolize se dá i jiným způsobem včetně podobných kontrol jako tady ve zprávičce.

  • 13. 5. 2017 7:12

    Vít Šesták

    > hash alg. bude určovat správce repa, co pak bude dělat s PR? Bude nutit je povinně přecommitovat s jeho hashem?

    To by nemusel být problém – podobná situace jako konflikt, akorát rešitelná vždy automaticky.

    > chce zachovat 160 bitovou velikost hashe

    Hmm, takže z id nebude jasné, jestli je nové nebo staré… Nabízí se zde downgrade attack, na druhou stranu by zde obyčejná kolize SHA1 nestačila – kolize napříč hashovacími funkcemi by nejspíš nebyla o nic jednodušší než nalezení preimage, což je oblast, kde se dnes drží nejen SHA1, ale i skoro všechny ostatní hashovací funkce, včetně MD5.

  • 13. 5. 2017 12:57

    Filip Jirsák

    Kvůli decentralizaci si moc nedokážu představit, že hash alg. bude určovat správce repa
    Pokud nebude hashovací algoritmus určovat správce repository, není potřeba nic měnit a můžeme zůstat u SHA-1. Vždyť celá ta změna se dělá kvůli tomu, že dnes by mohl nějaký zákeřný přispěvatel vytvořit dva různé commity se stejným hashem. Když necháte volbu hashovací funkce na přispěvateli, zákeřný přispěvatel si zvolí SHA-1 – a jsem tam, co dnes.

    co pak bude dělat s PR? Bude nutit je povinně přecommitovat s jeho hashem?
    On by to ani správce repository dělat nemusel, prostě by si hash přepočítal sám. Ale jinak na tom nevidím nic divného – když někdo dává požadavek na přetažení, musí si zajistit, aby jeho požadavek navazoval na stav repository, do kterého chce commit přetáhnout. Když jsou konflikty v kódu, musí to dělat ručně – naproti tomu přeznačení commitů se udělá automaticky.

    zachovat 160 bitovou velikost hashe
    To je krátkozraké řešení. Délky hashovacích funkcí se postupně prodlužují, protože jak se postupně zvyšuje výpočetní výkon, dokážeme toho víc upočítat hrubou silou, i kdyby ta hashovací funkce jinak byla bezchybná. Takže za nějakou dobu se bude řešit, že 160 bitů je prostě málo entropie, ať je získáte jakkoli. Dá se to brát jako dočasný workaround – na SHA-1 už existuje postup prolomení, tak použijeme jinou hashovací funkci se stejně dlouhým výstupem. Ale trvalé řešení to není. Navíc tohle osekávání hashovacích funkcí je dost ošemetné – ty hashovací funkce na to nikdy nebyly navržené a testované, takže je to další potenciální vektor útoku. Zrovna SHA-2 mají i ořezané varianty, takže snad v tomto směru budou odolné – ale tyhle zásahy kryptologů–amatérů jsou nebezpečné.

    Prozatím sha1 dostačuje
    Záleží na tom, co se od gitovského repository vlastně požaduje. Já si taky myslím, že pokud někdo může v repository napáchat škody commitem s konfliktním hashem, může tam napáchat daleko větší škody commitnutím škodlivého kódu. Ale zaseknout se trvale na nebezpečné hashovací funkci je podle mne špatně. S SHA-1 je to podobné, jako s HTTPS – je zbytečné nutit uživatele neustále přemýšlet o tom, kde je „nebezpečná“ varianta dostačující a kde je potřeba použít něco bezpečného, když můžu všude používat ty bezpečné algoritmy a protokoly.

    Ošetřit kolize se dá i jiným způsobem včetně podobných kontrol jako tady ve zprávičce.
    To je rychlý hack, ne trvalé řešení. Pak jste pořád o krok za útočníky, na každý nový způsob vytváření kolizí musíte najít způsob jejich detekce a dodatečně je implementovat.

  • 13. 5. 2017 22:49

    . . (neregistrovaný) ---.aoj.io

    pokud se zasáhne do interních structs v gitu, vznikne s tím git2, tomu se chtějí autoři vyhnout a proto 160b.

    Git se v současné době touhle kolizí sha1 nerozbije. Využití kolize znamená absenci code review a gpg podpisů. Její ošetření je jen na úrovni fsck (takovou jsem viděl první implementaci, kód z 2.13 jsem ještě nekontroloval).

    Nejsem tak zkušený, abych mohl třeba Davida Langa (či Linuse) nazývat kryptologem amatérem nebo jeho teze rozporovat.

    Tenhle problém se aktivně řeší, všichni víme, že máme ještě pár let čas. Do diskuzí v mailing listech se může zapojit vesměs kdokoliv, ale je těžké s autory držet krok a názorů se tam objevilo několik. Vznikem git2 by se ale nevyřešil problém s gitem a jeho použití se také jen tak neeliminuje.

    Osobně chci git2, vše ostatní je pro mě složitější než zmigrovat těch pár stovek repositářů, s kterými pracuji. Varianta, kdy tohle bude určovat správce repositáře akorát zanese neskutečný bordel do kompatibility gitu, tomu se chci vyhnout, stejně řada "správců" nechává vše výchozí.

  • 13. 5. 2017 23:00

    Vít Šesták

    Co třeba podpis tagu? Neznám git přesně do detailů, ale pokud se jen podepíše commit id, mohlo by tudy jít omezeně škodit.

  • 13. 5. 2017 23:10

    Filip Jirsák

    Je normální, že se formáty dat (souborové formáty, souborové systémy, protokoly) vyvíjejí. Může se tomu říkat třeba git2, ale vyhnout se tomu podle mne nejde (i kdyby se zůstalo u 160 bitů, objeví se později něco jiného).

    Mimochodem, součástí gitového repository je i verze formátu repository, první verze byla 0, dnes se používá verze 1. Takže git na to je připraven.

    máme ještě pár let čas
    Záleží na tom, jestli ten problém vůbec chceme řešit. A pokud ano (já jsem pro), není důvod to odkládat a není důvod dělat to jen napůl.

    Varianta, kdy tohle bude určovat správce repositáře akorát zanese neskutečný bordel do kompatibility gitu, tomu se chci vyhnout, stejně řada "správců" nechává vše výchozí.
    Že o tom rozhoduje správce repozitáře jsme uváděl jako protiklad k tomu, že o použitém hashi rozhoduje přispěvatel. Tak to být nemůže, aby změna hashovací funkce měla smysl, musí o tom rozhodovat správce repozitáře. A technicky nezáleží na tom, zda to rozhodne konfigurací, nebo tím, zda použije git nebo git3.