Комментарии 30
Понятно. Так же, как гит обходит эту проблему — поискать в файле один из двух известных блоков в коллизии. Заменить его на другой. Сейчас известно всего 2 блока, дающих коллизию.
Легко обходится перекодировкой видео, например. Не умеют генерить коллизию к произвольному блоку. Максимум, правоторговцы могут получить пару случайных блоков. Дальше их придется так же как в экзешнике, использовать в какой-то условной констиукции. Соотвественно, любое изменение файла перед раздачей ломает коллизию. Или эти странные условные конструкции можно легко вырезать.
В средем 0 колизий. Не умеют генерить колизии к блоку. Более того пару блоков без датацентра никак не сделать. Там алгоритм сильно ускоряет перебор, но все равно дофига получается. Все пртмеры атаки сейчас используют те 2 единственно известных блока.
Сгенерить коллизию к любому из десятков миллионов блоков, возможно, в 10 миллионов раз проще, чем к одному. Все равно, этого никто делать не умеет.
Как уже предложили, использовать более сильный хеш.
Либо, в оригинальной статье есть ссылка на workaround: https://github.com/cr-marcstevens/sha1collisiondetection .
Рассмотрим два случая:
1) У нас есть один хэш на 512 бит;
2) У нас есть два разных хэша, на разной математике, по 256 бит каждый.
Пока хэши не взломаны, стоимость перебора в первом случае 2^512, во втором — всего 2^257. Пока всё верно.
Но теперь допустим, что для первого хэша нашли закладку, снижающую стоимость перебора до 2^56 независимо от длины (такое бывало). В первом случае стойкость снизилась до 2^56 (дома не переберёшь, а вот в дата-центре можно), а во втором всего до 2^256. Почувствуйте разницу.
Опасность сильно преувеличена. Никто пока не умеет делать коллизию с произвольным блоком. Могут сделать 2 блока с одинаковым хешом. Т.е. оба экзешника сделаны вирусописателем.
Ситуация абсолютно аналогична сдедующей: есть вредоносный файл, который делает что-то полезное, но если вдруг решит, то расшифровывает вредоносную часть и исполняет ее.
Ничего нового. В худшем случае, будут бороться с пиратами и торентами, раздавая мусор. И то, это обходится обновлением протокола (давно пора) или перекодировкой медиа контента. Игры все равно приходится ломать, дак еще и проверку "сменного" блока придется отключать.
А раньше что мешало так делать? Обратите внимание, в атаке меняется не часть кода а какие-то мусорные данные. Потому что, опять же, коллизии генерируются не к заданному блоку, а парой — два случайных набора байт с одинаковым хешом. Этот "безобидный" лаунчер должен всю вредоносную нагрузку нести с собой.
Как уже говорили в другой ветке, Эта коллизия используется только как триггер. Заведомо вредоносный код уже в лаунчере. Да, это триггер, который отлавливает пользователей торрента. Все-равно, легко обходится. А встроить его не в исполняемые файлы весьма сложно. А даже если он там есть, его можно чуть ли не руками отключить.
1. Вредоносный код уже раздаётся в торренте, а коллизия лишь позволяет быть триггером атаки.
2. При загрузке, в силу того, что пиры качают куски у кого попало очень трудно проводить таргетированную атаку.
В целом: для срабатывания вредоносного кода можно использовать куда более простые триггеры. Например, ip компьютера жертвы.
Я представляю, что можно подобрать данные, которые выдадут такой же hash. Но насколько вообще реалистично написать НУЖНЫЙ ЗЛОУМЫШЛЕННИКУ код, и доделать блок таким образом, чтобы он не поломал работу в принципе, и выдал такой же hash?
Думаю шанс подделки хеша нужно умножить на шанс возможности вышеупомянутого, и спокойно отдохнуть еще пару десятков лет.
Атака BitErrant с коллизиями SHA-1: создаём разные .exe с одинаковым файлом .torrent