Як Git впорався зіткненням SHA-1 на краплі?

Це, мабуть, ще не було в реальному світі, і може ніколи не трапитися, але давайте розглянемо це: скажіть, у вас сховище git, візьміть на себе зобов’язання, і вам стане дуже невдало: одна з крапок у кінцевому підсумку має той же SHA-1 як інший, який уже є у вашому сховищі. Питання в тому, як би Git впорався з цим? Просто не вдалося? Знайдіть спосіб зв'язати два краплі і перевірити, який з них потрібний відповідно до контексту?

Більше цікавить мозок, ніж актуальна проблема, але я вважав це питання цікавим.

Я зробив експеримент, щоб з’ясувати, як саме Git поводитиметься у цьому випадку. Це з версією 2.7.9 ~ rc0 + next.20151210 (версія Debian). Я в основному просто зменшив розмір хешу з 160-бітного до 4-бітного, застосувавши наступний розріз і відновлення git:

--- git-2.7.0~rc0+next.20151210.orig/block-sha1/sha1.c
+++ git-2.7.0~rc0+next.20151210/block-sha1/sha1.c
@@ -246,6 +246,8 @@ void blk_SHA1_Final(unsigned char hashou
    blk_SHA1_Update(ctx, padlen, 8);

    /* Output hash */
-   for (i = 0; i < 5; i++)
-       put_be32(hashout + i * 4, ctx->H[i]);
+   for (i = 0; i < 1; i++)
+       put_be32(hashout + i * 4, (ctx->H[i] & 0xf000000));
+   for (i = 1; i < 5; i++)
+       put_be32(hashout + i * 4, 0);
 }

Тоді я зробив кілька доручень і помітив наступне.

1. Якщо крап вже існує з тим самим хешем, ви взагалі не отримаєте попереджень. Здається, все нормально, але коли ви натискаєте, хтось клонується, або ви повернетесь, ви втратите останню версію (відповідно до того, що пояснено вище).
2. Якщо деревооб'єкт вже існує, і ви робите крапку з таким же хешем: все буде здаватися нормальним, поки ви не спробуєте натиснути або хтось не клонує ваше сховище. Тоді ви побачите, що РЕПО зіпсоване.
3. Якщо об'єкт фіксації вже існує, і ви робите крапку з таким же хешем: такий же, як №2 - пошкоджується
4. Якщо блоб вже існує, і ви робите об’єкт фіксації з тим самим хешем, він не вийде при оновленні "ref".
5. Якщо крапля вже існує, і ви робите об’єкт з дерева з таким же хешем. Це не вдасться при створенні комітету.
6. Якщо деревооб'єкт вже існує і ви робите об’єкт фіксації з тим же хешем, він не вийде при оновленні "ref".
7. Якщо деревооб'єкт вже існує, і ви робите об’єкт дерева з таким же хешем, все буде здаватися нормальним. Але коли ви здійснюєте, усі сховища посилаються на неправильне дерево.
8. Якщо об’єкт фіксації вже існує, і ви робите об’єкт фіксації з тим же хешем, все буде здаватися нормальним. Але коли ви здійснюєте, комісія ніколи не буде створена, і вказівник HEAD буде переміщений до старого.
9. Якщо об'єкт фіксації вже існує, і ви робите деревний об'єкт з таким же хешем, він не вдасться створити команду.

Для №2 ви зазвичай отримаєте подібну помилку під час запуску "git push":

error: object 0400000000000000000000000000000000000000 is a tree, not a blob
fatal: bad blob object
error: failed to push some refs to origin

або:

error: unable to read sha1 file of file.txt (0400000000000000000000000000000000000000)

якщо ви видалите файл, а потім запустіть "git checkout file.txt".

Для №4 та №6 зазвичай з’явиться така помилка:

error: Trying to write non-commit object
f000000000000000000000000000000000000000 to branch refs/heads/master
fatal: cannot update HEAD ref

при запуску "git commit". У такому випадку ви можете просто просто ввести "git commit" знову, оскільки це створить новий хеш (через змінену часову позначку)

Для №5 та №9, як правило, з’явиться така помилка:

fatal: 1000000000000000000000000000000000000000 is not a valid 'tree' object

під час запуску "git commit"

Якщо хтось спробує клонувати ваше корумповане сховище, він зазвичай бачить щось на зразок:

git clone (one repo with collided blob,
d000000000000000000000000000000000000000 is commit,
f000000000000000000000000000000000000000 is tree)

Cloning into 'clonedversion'...
done.
error: unable to read sha1 file of s (d000000000000000000000000000000000000000)
error: unable to read sha1 file of tullebukk
(f000000000000000000000000000000000000000)
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

Що мене «хвилює», що у двох випадках (2,3) сховище стає корумпованим без будь-яких попереджень, а в 3 випадках (1,7,8) все здається нормальним, але вміст сховища відрізняється від того, що ви його очікуєте бути. Люди, що клонують або тягнуть, матимуть інший зміст, ніж те, що у вас є. Випадки 4,5,6 та 9 у порядку, оскільки вони припиняться з помилкою. Я припускаю, що було б краще, якби це не вдалося з помилкою принаймні у всіх випадках.

Оригінальна відповідь (2012) (див. shattered.ioЗіткнення SHA1 2017 нижче)

Ця стара відповідь Лінуса (2006) все ще може бути актуальною:

Ні. Якщо він має той самий SHA1, це означає, що коли ми отримаємо об'єкт з іншого кінця, ми не будемо перезаписувати об'єкт, який у нас уже є.

Отже, що трапляється, що якщо ми коли-небудь побачимо зіткнення, "раніше" об'єкт у будь-якому конкретному сховищі завжди виявиться переважаючим. Але зауважте, що "раніше", очевидно, є репозиторієм, в тому сенсі, що мережа об'єктів git генерує DAG, який не впорядкований повністю, тому в той час як різні сховища погоджуватимуться, що є "раніше" у випадку прямого походження, якщо Об'єкт потрапляв через окремі і не пов'язані між собою гілки, два різні репозиції, очевидно, отримали два об'єкти в різному порядку.

Однак "раніше буде переохолоджене" - це дуже те, що ви хочете з точки зору безпеки: пам’ятайте, що git-модель полягає в тому, що вам слід в першу чергу довіряти лише власному сховищу.
Отже, якщо ви робите " git pull", нові вхідні об'єкти за визначенням менш надійні, ніж об’єкти, які ви вже маєте, і як таке було б неправильно дозволити новому об'єкту замінити старий.

Отже, у вас є два випадки зіткнення:

• ненавмисний вид , де - то дуже - дуже пощастило, і два файли в кінцевому підсумку з тієї ж SHA1.
  У той момент, що трапляється, це те, що коли ви скористаєтесь цим файлом (або зробите " git-update-index" для переміщення його в індекс, але ще не здійснено), SHA1 нового вмісту буде обчислено, але оскільки він відповідає старому об'єкту, новий об'єкт не буде створений, і команда-індекс в кінці вказує на старий об'єкт .
  Ви не помітите одразу (оскільки індекс буде відповідати старому об'єкту SHA1, а це означає, що щось на зразок " git diff" буде використовувати перевірену копію), але якщо ви коли-небудь будете робити на рівні дерева різницю (або ви клонуєте або потягніть, або примусьте отримати замовлення) ви раптом помітите, що цей файл змінився на щосьзовсім інше, ніж те, що ви очікували.
  Таким чином, ви зазвичай помітили подібне зіткнення досить швидко.
  У пов’язаних новинах питання полягає в тому, що робити з приводу випадкового зіткнення.
  Перш за все, дозвольте мені нагадати людям, що випадковий зіткнення насправді насправді проклятий малоймовірним, тому ми, ймовірно, ніколи не побачимо його у всій історії. Всесвіту.
  Але якщо це трапиться, це ще не кінець світу: те, що ви, швидше за все, вам доведеться зробити, - це просто змінити файл, який зіткнувся трохи, і просто змусити нову команду зі зміненим вмістом (додайте коментар, що говорить " /* This line added to avoid collision */") і потім навчіть гніт про магію SHA1, яка виявилася небезпечною.
  Тому за пару мільйонів років, можливо, нам доведеться додати одне-два «отруєних» значення SHA1, щоб git. Це навряд чи буде проблемою з технічним обслуговуванням;)

• Зломщик роду зіткнення , тому що хто - то зламав (або скотина-примусову) SHA1.
  Це очевидно набагато частіше, ніж випадковий вид, але за визначенням це завжди "віддалене" сховище. Якби зловмисник мав доступ до місцевого сховища, у нього були б набагато простіші способи викрутити вас.
  Тож у цьому випадку зіткнення - це зовсім не проблема : ви отримаєте "поганий" сховище, яке відрізняється від того, що нападник мав намір, але оскільки ви ніколи не використовуєте його об'єкт, що стикається, він буквально нічим не відрізняється від нападник просто взагалі не знайшов зіткнення, але лише за допомогою об'єкта, який ви вже мали (тобто це 100% еквівалент "тривіальному" зіткненню ідентичного файлу, що генерує той самий SHA1).

Питання про використання SHA-256 регулярно згадується, але не діє на на поточному (2012).
Примітка: починаючи з 2018 року та Git 2.19 , кодекс відновлюється для використання SHA-256.

Примітка (Гумор): ви можете примусити взяти на себе певний префікс SHA1 , використовуючи проект gitbrute від Brad Fitzpatrick ( bradfitz) .

gitbrute brute-примушує пару часових міток автора + фіксатора таким чином, щоб отримана команда git мала бажаний префікс.

Приклад: https://github.com/bradfitz/deadbeef

Деніел Дінніс вказує в коментарі до 7.1 Git Tools - Вибір редакції , який включає:

Існує більша ймовірність того, що в один і той же вечір кожен член вашої команди програмування буде нападений і убитий вовками в неспоріднених інцидентах.

Навіть недавно (лютий 2017 року) shattered.ioпродемонстровано можливість підробити зіткнення SHA1:
(дивіться набагато більше в моїй окремій відповіді , включаючи публікацію Google+ Лінуса Торвальдса)

• a / все ще вимагає понад 9,223,372,036,854,775,808 обчислень SHA1. Це зайняло еквівалентну обробну потужність, як 6 500 років обчислень з одним процесором і 110 років обчислень для одного GPU.
• b / створив би один файл (з тим самим SHA1), але з додатковим обмеженням його вміст і розмір призведе до отримання однакового SHA1 (зіткнення лише щодо вмісту недостатньо): див. " Як обчислюється хет-хет? ") : blob SHA1 обчислюється виходячи із вмісту та розміру .

Докладніше див. У " Життях криптографічних хеш-функцій " від Валері Аніти Аврори .
На цій сторінці вона зазначає:

Google витратив 6500 CPU років і 110 GPU років, щоб переконати всіх, хто нам потрібно припинити використання SHA-1 для критично важливих для безпеки програм.
Також тому, що це було круто

Дивіться більше в моїй окремій відповіді нижче .

За даними Pro Git :

Якщо у вас трапиться об'єкт, який хешируется на те саме значення SHA-1, що і попередній об'єкт у вашому сховищі, Git побачить попередній об’єкт вже у вашій базі даних Git і припустить, що він уже написаний. Якщо ви спробуєте перевірити цей об'єкт ще раз у якийсь момент, ви завжди отримаєте дані першого об’єкта.

Таким чином, він не вийде з ладу, але і ваш новий об’єкт не врятує.
Я не знаю, як це виглядатиме в командному рядку, але це, безумовно, бентежить.

Трохи далі той самий посилання намагається проілюструвати ймовірність такого зіткнення:

Ось приклад, щоб дати вам уявлення про те, що знадобиться для зіткнення SHA-1. Якби всі 6,5 мільярдів людей на Землі програмували, і щосекунди кожен виробляв код, який був еквівалентом всієї історії ядра Linux (1 мільйон об'єктів Git) і переміщав її в одне величезне сховище Git, це займе 5 років, поки це сховище містило достатньо об'єктів, щоб мати 50% -ву ймовірність зіткнення одного об'єкта SHA-1. Існує більша ймовірність того, що в один і той же вечір кожен член вашої команди програмування буде нападений і убитий вовками в неспоріднених інцидентах.

Щоб додати до моєї попередньої відповіді з 2012 року , зараз (лютий 2017, п’ять років пізніше), приклад фактичного зіткнення SHA-1 з shattered.io , де ви можете скласти два стикаються PDF-файли: тобто отримати SHA- 1 цифровий підпис на першому PDF-файлі, який також може бути зловживаний як дійсний підпис у другому файлі PDF.
Дивіться також " У двері смерті протягом багатьох років широко застосовувана функція SHA1 тепер мертва ", і цю ілюстрацію .

Оновлення 26 лютого. Лінус підтвердив такі пункти в публікації в Google+ :

(1) Спочатку - небо не падає. Існує велика різниця між використанням криптографічного хеша для таких речей, як підписання безпеки, і використанням одного для створення "ідентифікатора вмісту" для системи, адресованої вмістом, як git.

(2) По-друге, характер цієї конкретної атаки SHA1 означає, що насправді досить легко пом'якшити, і вже було два набори виправлень для цього пом'якшення.

(3) І нарешті, насправді є досить простий перехід до якогось іншого хешу, який не зламає світ - або навіть старі сховища git.

Щодо цього переходу див Q1 2018 Git 2.16, додаючи структуру, що представляє хеш-алгоритм. Реалізація цього переходу розпочалася.

Починаючи з Git 2.19 (Q3 2018) , Git вибрав SHA-256 як NewHash , і він перебуває в процесі інтеграції його до коду (мається на увазі, SHA1 все ще є за замовчуванням (Q2 2019, Git 2.21), але SHA2 стане наступником)

Оригінальна відповідь (25 лютого) Але:

• Це дозволяє підробляти крапку, однак SHA-1 дерева все одно зміниться, оскільки розмір кованої краплі може бути не таким, як початковий: див. " Як обчислюється хеш-гіт? "; блоб SHA1 обчислюється на основі змісту і розміру . Однак у
  нього є певне питанняgit-svn . А точніше із самим svn , як це видно тут .
• Як я вже згадував у своїй оригінальній відповіді , вартість такої спроби поки що непомітна (6 500 років процесора та 100 GPU років) Дивіться також Валері Аніту Аврору в " Життях криптографічних хеш-функцій ".
• Як зазначалося раніше, мова йде не про безпеку чи довіру, а про цілісність даних (дедуплікація та виявлення помилок), яку легко виявити git fsck, як згадує Лінус Торвальдс сьогодні. git fsckпопередить про повідомлення про фіксацію з непрозорими даними, прихованими після NUL(хоча NULвони не завжди містяться в шахрайському файлі ).
  Не всі включаютьсяtransfer.fsck , але GitHub робить: будь-який натиск буде перервано у випадку неправильного об'єкта або пошкодженого зв’язку. Хоча ... є причина, що вона за замовчуванням не активована .
• pdf-файл може мати довільні двійкові дані, які ви можете змінити, щоб створити зіштовхується SHA-1, на відміну від підробленого вихідного коду.
  Справжня проблема у створенні двох сховищ Git з однаковою головою здійснюють хеш і різний вміст. І навіть тоді напад залишається розгорнутим .
• Лінус додає :

  Вся суть СКМ полягає в тому, що йдеться не про разові події, а про суцільну історію. Це також принципово означає, що для успішної атаки потрібно працювати з часом, а не бути виявленим.
  Якщо ви можете один раз обдурити SCM, вставте свій код, і він буде виявлений на наступному тижні, ви насправді не зробили нічого корисного. Ви тільки спалили себе.

Joey Hess пробує ці файли у форматі PDF у Git repo та він знайшов :

Це включає два файли з однаковим розміром і SHA, які отримують різні краплі завдяки тому, що git попередньо заголовка вмісту.

joey@darkstar:~/tmp/supercollider>sha1sum  bad.pdf good.pdf 
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  bad.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  good.pdf
joey@darkstar:~/tmp/supercollider>git ls-tree HEAD
100644 blob ca44e9913faf08d625346205e228e2265dd12b65    bad.pdf
100644 blob 5f90b67523865ad5b1391cb4a1c010d541c816c1    good.pdf

Хоча додавання однакових даних до цих файлів, що стикаються, генерує інші зіткнення, попередні дані не роблять.

Отже, основним вектором нападу (кування вчинку) був би :

• Створити звичайний об'єкт фіксації;
• використовувати весь об'єкт фіксації + NUL як обраний префікс, і
• використовувати атаку зіткнення з однаковими префіксами для створення об'єктів, що стикаються з добрим / поганим.
• ... і це марно, оскільки добрі та погані предмети вчинення все ще вказують на одне дерево!

Крім того, ви вже можете виявляти криптоаналітичні атаки зіткнення проти SHA-1 у кожному файлі cr-marcstevens/sha1collisiondetection

Додаємо аналогічний чек у самому Git , виникла б якась обчислення .

Щодо зміни хешу, коментарі Linux :

Розмір хеша та вибір алгоритму хешу - це незалежні питання.
Що ви, мабуть, зробите, це перейти на 256-бітний хеш, використовувати це внутрішньо і в нативній базі даних git, а потім за замовчуванням показувати хеш як шістнадцяткову шістнадцяткову рядок (на кшталт того, як ми вже скорочуємо речі в багато ситуацій).
Таким чином, інструменти навколо git навіть не бачать змін, якщо не передаються в якомусь спеціальному " --full-hash" аргументі (або " --abbrev=64" чи будь-якому іншому - за замовчуванням ми скорочуємо до 40).

Проте план переходу (від SHA1 до іншої хеш-функції) все ще буде складним , але активно вивчається. Кампанія знаходиться в стадії розробки :
convert-to-object_id

Оновлення 20 березня: GitHub детально розповідає про можливу атаку та її захист :

Іменам SHA-1 можна присвоювати довіру через різні механізми. Наприклад, Git дозволяє криптографічно підписувати комітку або тег. Це підписує лише сам об'єкт фіксації або тегів, який, в свою чергу, вказує на інші об'єкти, що містять фактичні дані файлу, використовуючи їх імена SHA-1. Зіткнення в цих об'єктах може створити підпис, який видається дійсним, але який вказує на інші дані, ніж призначений підписант. У такому нападі підписант бачить лише одну половину зіткнення, а потерпілий бачить другу половину.

Захист:

Недавня атака використовує спеціальні методи для використання слабких місць в алгоритмі SHA-1, які знаходять зіткнення за набагато менший час. Ці методи залишають зразок у байтах, який можна виявити при обчисленні SHA-1 будь-якої половини пари, що стикається.

GitHub.com тепер виконує це виявлення для кожного обчисленого SHA-1 і припиняє операцію, якщо є докази того, що об'єкт є половиною пари, що стикається. Це заважає зловмисникам використовувати GitHub, щоб переконати проект прийняти "невинну" половину зіткнення, а також заважає їм приймати зловмисну ​​половину.

Дивіться " sha1collisiondetection" Марка Стівенса

Знову ж таки, з першого кварталу 2018 року Git 2.16 додав структуру, що представляє хеш-алгоритм, розпочато реалізацію переходу до нового хешу.
Як було сказано вище, новим підтримуваним Hash буде SHA-256 .

Думаю, криптографи святкували б.

Цитата зі статті Вікіпедії про SHA-1 :

У лютому 2005 року було оголошено про напад Сяоюн Ван, Ікюн Лізи Інь та Гонко Ю. Атаки можуть виявити зіткнення у повній версії SHA-1, що вимагає менше ніж 2 ^ 69 операцій. (Для пошуку грубої сили знадобиться 2 ^ 80 операцій.)

Існує кілька різних моделей атаки на хеші, як SHA-1, але зазвичай обговорюється пошук зіткнень, включаючи інструмент HashClash Марка Стівенса .

"Станом на 2012 рік, найефективнішою атакою проти SHA-1 вважається атака Марка Стівенса [34], орієнтовна вартість якої становить 2,77 млн ​​доларів, щоб розбити єдине хеш-значення шляхом оренди живлення процесора на хмарних серверах."

Як зазначали люди, ви можете змусити хеш-зіткнення з git, але це не перезапише існуючі об'єкти в іншому сховищі. Я думаю, навіть git push -f --no-thinне перезаписує існуючі об'єкти, але не на 100% впевнений.

Це означає, що якщо ви зламаєте віддалений сховище, то ви можете зробити свій хибний об'єкт старішим там , можливо, вбудувавши зламаний код у проект з відкритим кодом на github чи подібному. Якщо ви були обережні, то, можливо, ви могли б представити хакерську версію, яку завантажували нові користувачі.

Але я підозрюю, що багато речей, які могли б зробити розробники проекту, можуть або викрити, або випадково знищити ваш багатомільйонний хак. Зокрема, це багато грошей на збиток, якщо якийсь розробник, якого ви не зламали, коли-небудь запускає вищезгадане git push --no-thinпісля зміни файлів, що впливають, іноді навіть без --no-thinзалежних.