Алгоритм 379-летней давности помог эксперту взломать RSA-ключи принтеров

Алгоритм 379-летней давности помог эксперту взломать RSA-ключи принтеров

Алгоритм 379-летней давности помог эксперту взломать RSA-ключи принтеров

Ключи RSA, которые генерирует устаревший криптомодуль библиотеки SafeZone, можно легко вычислить, используя алгоритм факторизации Ферма. Благодаря этому открытию исследователь Ханно Бёк (Hanno Böck) смог выявить новую уязвимость в принтерах Canon и Fuji Xerox.

Специалисты по криптографии давно удостоверились, что выбор близких друг к другу простых чисел при создании RSA-ключей (к примеру, представления содержат по 500 одинаковых верхних битов) позволяет без особого труда найти эти множители по методу факторизации, предложенному Пьером Ферма в 1643 году. Если же оба случайных простых числа (их обычно обозначают как p и q) генерируются независимо, велика вероятность, что такой способ взлома окажется провальным.

Что касается решения SafeZone, то оно изначально не обеспечивало большой криптостойкости, и его перестали рекомендовать для использования. Однако с переходом разработчика (Inside Secure) под крыло ИТ-компании Rambus в 2019 году проект получил новую жизнь — в доработанном виде эти криптобиблиотеки сейчас продаются под новым брендом как FIPS Security Toolkit.

Тем не менее, Бёку удалось найти случаи использования криптомодулей SafeZone устаревших версий. Проверяя надежность публичных ключей RSA из своей обширной коллекции, исследователь обнаружил несколько образцов, легко подающихся взлому.

В частности, применение алгоритма факторизации Ферма позволило обнаружить слабость криптоключей, которые используют для TLS-связи некоторые принтеры Fujifilm (ранее Fuji Xerox) и Canon. Уязвимости, выявленной в ходе исследования, был присвоен идентификатор CVE-2022-26320, Fujifilm уже выпустила обновленные прошивки.

Бёк также нашел на SKS-серверах четыре уязвимых ключа PGP, но они имели пользовательский ID, то есть были созданы явно с целью тестирования.

Проводник Windows падал не из-за Microsoft, виноват оказался деинсталлятор

Инженер Microsoft Рэймонд Чен рассказал любопытную историю отладки загадочных падений Проводника. Сначала всё выглядело так, будто в Windows внезапно появился неприятный баг. Но виновником оказалась вовсе не Microsoft, а сторонний деинсталлятор.

Проблема проявилась как резкий всплеск сбоев Проводника. Инженеры начали изучать дампы и заметили странную деталь: падала 32-битная версия программы, запущенная на 64-битных системах Windows.

Такая версия Проводника всё ещё есть в Windows ради совместимости со старыми приложениями. Обычно современные системы почти не используют этот путь. Но в данном случае сторонний деинсталлятор каким-то образом заставлял систему обращаться именно к этому устаревшему компоненту.

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

Поскольку процесс повторялся в цикле, повреждение памяти постепенно накапливалось. В какой-то момент указатель стека уезжал в область активного кода, и Проводник падал.

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

Чен напомнил важную вещь: в экосистеме Windows с миллиардами устройств и огромным количеством приложений далеко не каждый сбой компонента Microsoft означает баг в Windows. Сторонние программы тоже могут ломать системные процессы, особенно если неправильно используют низкоуровневые API.

RSS: Новости на портале Anti-Malware.ru