The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Энтузиасты воссоздали метод мгновенной генерации PDF-файлов с одинаковым хэшем SHA-1

25.02.2017 09:36

Не дожидаясь компании Google, которая на 90 дней отложила публикацию практических наработок в области подбора коллизий SHA-1, энтузиасты представили сразу несколько своих вариантов осуществления атаки, основанных на изначально доступном теоретическом описании и продемонстрированных компанией Google PDF-документах. В частности, запущен альтернативный сервис SHA1 collider, позволяющий загрузить два разных изображения и сразу получить на выходе два PDF-файла, имеющих одинаковый хэш SHA-1, но выводящих разные изображения. Также подготовлен Python-скрипт для приведения двух многостраничных PDF-документов к виду с одинаковыми хэшами SHA-1.

В случае предложенной атаки на PDF, для создания двух PDF-файлов с одинаковыми хэшами SHA-1 больших вычислительных ресурсов не требуется. Суть метода в использовании уже рассчитанной коллизии, позволяющей сохранить хэш SHA-1 при изменении нескольких байт в определённой позиции потока. Для атаки применяются типовые блоки PDF, включающие заголовок PDF, дескриптор потока JPEG и заголовки JPEG. Cодержимое документов для которых нужно создать PDF с одинаковыми хэшами SHA-1 преобразуется в многослойный JPEG, в котором присутствует изображение как первого, так и второго документа.

Наполнение для вызова коллизии включается в состав JPEG. Далее этот общий JPEG прикрепляется к готовым начальным блокам и завершается типовым фиксированным завершающим блоком, содержащим команды отображения PDF. По сути на выходе получаются два почти одинаковые файла, отличающихся только одним параметром в заголовке JPEG, который обеспечивает отображение разных данных в разных PDF-файлах через переключение активного слоя в сводном JPEG-изображении. При открытии первого PDF показывается первый слой, а при открытии другого - второй.

Для разного отображения слоёв применяются манипуляции с заголовками JPEG. В каждом заголовке JPEG имеется поле с комментарием, которое располагается в файле таким образом, чтобы сместить 16-разрядное значение длины поля в область возникновения коллизии. Так как параметр находится в зоне коллизии, его изменение не влияет на вычисленный хэш SHA-1. Манипуляция со значением длины комментария позволяет добиться того, что в первом PDF-файле блок с данными первого изображения попадает в область комментария и отображается второй набор данных, а во втором PDF-файле отображается первый набор данных, а второй игнорируется, так как находится за границей метки конца потока.

Использование типового набора данных для вызова коллизии открывает двери для новых атак, порой неожиданных. Например, разработчики WebKit добавляя в код защиту от вызова коллизии в SHA-1, сами того не желая, обрушили Subversion-зеркало репозитория проекта. Проблема была вызвана тем, что добавив несколько коммитов, содержащих данные, вызывающие коллизию, код дедупликации в SVN-репозитории рассчитал для этих коммитов одинаковый хэш, что нарушило целостность репозитория и заблокировало добавление новых коммитов. Для Git уже вычисленная коллизия не представляет угрозы, но не исключена возможность расчёта новой коллизии, специально для создания конкретного поддельного репозитория Git.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Google продемонстрировал первую успешную атаку на алгоритм хеширования SHA-1
  3. OpenNews: Для взлома MD5 хэша нужно всего 8 часов
  4. OpenNews: Опубликованы исходные тексты программы для поиска коллизий в MD5
  5. OpenNews: Автор md5crypt подчеркнул небезопасность данного алгоритма и призвал перейти на более стойкие методы хэширования паролей
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/46102-sha1
Ключевые слова: sha1, pdf
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (32) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Анонимусик (?), 10:20, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А вот -- https://joeyh.name/blog/entry/SHA1_collision_via_ASCII_art/ -- коллизия SHA1 через ascii-арт. Дыра, чё.
     
  • 1.3, Kleemhead (?), 11:11, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    как красиво гугл общеголяли
     
     
  • 2.10, анонимим (?), 13:23, 25/02/2017 [^] [^^] [^^^] [ответить]  
  • +15 +/
    >> как красиво гугл общеголяли

    Используя материалы гугла, описывающие эту технику, которые гугл выложил добровольно, и умеющий делать это задолго до того, как его "общеголяли"? :)

     
     
  • 3.20, kleem_head (?), 18:26, 25/02/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    волшебное слово "мгновенный"
     
     
  • 4.54, Serg (??), 14:32, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    да, мне тоже "мгновенный" понравилось :-)
     
  • 3.42, EuPhobos (ok), 09:16, 26/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Именно, т.к. гуглу по их же материалам понадобился год с машиной со 100 GPU, а энтузиастам всего пара суток.
     
  • 2.37, qwerty123 (??), 22:32, 25/02/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > как красиво гугл общеголяли

    угу.

    --- BEGIN PDF ---
    if (херня > 1) {
      out(фигня)
    } else {
      out(другая_фигня)
    }
    --- END PDF ---
    HASH = 12345

    Новость:
    Энтузиасты представили сразу несколько своих вариантов осуществления атаки....


     

  • 1.4, Джо (?), 11:21, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Т.е. больше не требуется год работы сотни GPU чтобы сгенерировать коллизию?
     
     
  • 2.6, Скромное обаяние буржуазии (?), 11:46, 25/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, можно за год предварительные данные рассчитать, а затем за 5 минут миллион документов с одинаковым хешем сфабриковать ..
     
  • 2.50, Аноним (-), 10:59, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    чтобы "сгенерировать" коллизию по прежнему нужен год. а использовать ее затем можно многократно и достаточно быстро.
     

  • 1.7, Michael Shigorin (ok), 12:26, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да уж, subversion явно узрел своё "мене, мене, текел, фарес" на стене...
     
  • 1.8, Аноним (-), 12:52, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ах, даже не разное содержимое файлов, а просто "манипуляции с заголовками JPEG". Хороший фокус... Для детского утренника. Расходимся, посоны.
     
     
  • 2.9, Anonplus (?), 13:09, 25/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ах, даже не разное содержимое файлов, а просто "манипуляции с заголовками JPEG".

    То, что в каждом файле представлена полная копия данных двух файлов, не отменяет конечного эффекта, что каждый файл показывает разное содержимое.

     
     
  • 3.11, cmp (ok), 13:32, 25/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Если разные файлы показывают разное содержимое, то они разные, и контрольне суммы должны быть разными, манипуляции с заголовками пдф и жпег от лукавого. Если какаято софтина считает контрольную сумму разбирая содержимое и пропуская какието блоки, то это проблема софтины.
     
     
  • 4.39, Ordu (ok), 01:10, 26/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Контрольные суммы считаются по всему pdf файлу. Ты можешь это сам проверить, скачав те pdf'ки и посчитав на них SHA-1 такой программой, которую считаешь правильной.
     
  • 4.41, Lain_13 (ok), 03:56, 26/02/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Как бы тебе так объяснить, чтоб ты понял?

    Любой файл можно представить как одно очень большое число. Контрольная сумма же имеет фиксированную длинну и она практически всегда корое файла, для которого рассчитывается. Т.е. мы выражаем большее число через меньшее. Если мы будем перебирать все такие большие числа по порядку, то рано или поздно мы найдём ещё одно большое число, контрольная сумма от которого будет идентична ранее найденной. Это называется коллизией. Т.е. два больших числа (файла) у нас разные, а вот контрольная сумма у них идентичная.

    Возьмём набор чисел от 00 до 99 и самую простую контрольную сумму - сумму первого и второго разрядов до тех пор, пока не останется один разряд. Т.е. для 00 сумма будет 0, для 13 - 4, а для 99 - 9 (18 → 1+8). Всё просто? Но что произойдёт если рассчитать контрольные суммы для всех чисал? Как только мы дойдём до числа 10 мы наткнёмся на первую же коллизию с числом 01, 11 с 02, 12 с 03 и так далее.

    Ещё проще: невозможно однозначно выразить большее число через меньшее. Не существует такой функции рассчёта контрольной суммы фиксированной длинны, для которой не существует коллизий. Просто чем больше длинна контрольной суммы тем меньше вероятность такую коллизию найти случайно. Сложность намеренного поиска коллизий зависит от алгоритма функции.

    Тут всё ясно?

    Естественно прямой перебор занимает уйму времени, но в данном случае он нам и не нужен. Указанные манипуляции позволяют получать из двух картинок или pdf-файлов рызные по содержанию файлы (два разных больших числа), но с идентичной контрольной суммой. Никто ни какие блоки при рассчёте суммы не пропускает. Просто числа сформированы так, что для данной конкретной функции рассчёта контрольной суммы они дадут одинаковый результат. Если взять другую функцию рассчёта контрольной суммы (даже такой же длинны), то там, скорее всего, результат будет уже разный. Подобрать два числа выдающие коллизию на двух функциях значительно сложнее.

     
     
  • 5.43, cmp (ok), 11:05, 26/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да я как бэ в курсе. Просто заплутал в дебрях авторских дифирамб, может возраст уже не тот, а может качество подачи контента.

    Хотя все равно не понятно, зачем они так цепляются за жпег в пдфке, ну взяли бы тар архив подделали, отметить в нем файл как удаленный тоже пару бит поменять, ИМХО, было бы нагляднее - подменили архив на такойже по размеру и хэшу, но из которого не распаковывается патч, который латает дыру, на кой черт все эта возня со слоями.

     
     
  • 6.47, Lain_13 (ok), 17:39, 26/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну они ведь разобрали Гугловский пример. Что разбирали к тому и «прицепились».
     
  • 5.51, вытек глаз (?), 12:01, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > фиксированную длинну
    > фиксированной длинны
    > больше длинна
    > такой же длинны
    > Lain_13

    13 - это количество лет?
    Что интересно, слова "длинны" и "длинна" существуют, но, естественно, не с тем смыслом. А вот "длинну" появилось из влажных фантазий.

     
  • 2.45, Sabakwaka (ok), 14:43, 26/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> даже не разное содержимое файлов...

    Болеешь? Чем?

     

  • 1.12, lucentcode (ok), 14:38, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Это не последний подобный прокол. Будут и другие. В том числе и для других "безопасных" хэш-функций. Просто время SHA-1 кануло в лету. Пора распрощаться с SHA-1. Возможно, лет через 10, мы точно также попрощаемся с считающимися в настоящее время надёжными хэш-функциями. Главное что-бы это было сделано до того, как техника создания разных документов с одинаковым хэшем станет легко доступной широкой аудитории.
     
  • 1.13, Михаил (??), 15:43, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё-таки они не воссоздали способ (он давно опубликован, а через три месяца покажут и оптимизации при практической реализации), а автоматизировали применение одной конкретной коллизии для создания пар файлов.

    То, что после коллизии можно добавлять прозивольные данные и получать новые варианты той же коллизии — это-то как раз не новость, казалось бы.

     
     
  • 2.16, Аноним (-), 16:26, 25/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А где почитать про то, что ты говоришь? У Bruce Schneier или где?
     

  • 1.21, anonymous (??), 18:42, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    просто используйте SHA3-224, надеюсь скоро в git встроят команду апдейта существующего репозитория до SHA3-224
     
     
  • 2.40, NYMA (?), 03:21, 26/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Имеет смысл использовать SHA256, потому-что есть в реальном времени подбор частичных коллизий для него, и в случае чего, заблаговременно можно будет увидеть проблемы.

     

  • 1.44, Аноним (-), 12:28, 26/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Торрентов, каких мы их знали, скоро будет не скачать? Файковые сидеры, оплачиваемые копирастами, будут отдавать битые блоки с правильной sha1 суммой...
    И после скачивания образа какой-нибудь убунты привычным будет пройтись zsync-ом, дабы пофиксить преднамеренно испорченные блоки.
     
     
  • 2.46, 123 (??), 17:14, 26/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>Файковые сидеры, оплачиваемые копирастами, будут отдавать битые блоки с правильной sha1 суммой...

    "You are listening pirated album" снова появиться в закачках?

     
  • 2.48, Аноним (-), 01:14, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Всего пару дней назад читал комент об этом от мицгола
     
  • 2.49, chig00 (ok), 02:05, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    В обозримом будущем ничего не поменяется. Для поломки торрентов как мы их знаем надо не коллизионные атаки (как та которую осуществили), а атака нахождения прообраза, которую еще не осилили даже для md5.
    Проблемы могут возникнуть если сами копирасты будут создавать раздачи, но тогда им ничего не мешает засунуть туда мусор с самого начала.
     
     
  • 3.53, Аноним (-), 14:04, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А они так давно делают. Но нечасто. Неэффективно и создаёт юридические проблемы. Проще сразу запретить по DMCA.
     

  • 1.55, chinarulezzz (ok), 10:15, 05/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Для Git уже вычисленная коллизия не представляет угрозы, но не исключена возможность расчёта новой коллизии, специально для создания конкретного поддельного репозитория Git.

    http://www.metzdowd.com/pipermail/cryptography/2017-February/031623.html

     
     
  • 2.56, chinarulezzz (ok), 10:19, 05/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, или https://pbs.twimg.com/media/C5noqKfUsAAWOc3.jpg:large

    :)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру