Уязвимости в GnuPG, позволяющие обойти верификацию и выполнить свой код

На проходящей в Германии конференции 39C3 (Chaos Communication Congress) раскрыты детали о 12 ранее неизвестных и остающихся неисправленными (0-day) уязвимостях в инструментарии GnuPG (GNU Privacy Guard), предоставляющем совместимые со стандартами OpenPGP и S/MIME утилиты для шифрования данных, работы с электронными подписями, управления ключами и доступа к публичным хранилищам ключей. Наиболее опасные уязвимости позволяют обойти проверку по цифровой подписи и добиться выполнения кода при обработке шифрованных данных в ASCII-представлении (ASCII Armor). Рабочие прототипы эксплоитов и патчи обещают опубликовать позднее. CVE-идентификаторы пока не присвоены.

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

Выявленные проблемы:

  • Ошибка в коде парсера зашифрованных данных, распространяемых в формате ASCII-Armor (текстовые файлы с блоком «BEGIN/END PGP ARMORED FILE»), приводящая к записи в область памяти вне границы буфера. Проблема может привести к выполнению кода при обработке в gpg специально оформленных данных. Уязвимость проявляется в функции armor_filter() и вызвана двойным увеличением счётчика «n» в цикле «for» — несмотря на указание «n++» в самом цикле, счётчик увеличивается и в теле цикла при записи данных в буфер «buf[n++]». В итоге за пределы буфера записывается лишний байт, а переменная с размером «ret_len» выставляется в значение, превышающее фактическое.
  • Возможность создания или перезаписи любого файла, насколько позволяют текущее права доступа, из-за некорректной обработки содержимого поля «filename» в пакете с данными. Уязвимость может использоваться для организации выполнения кода в системе при выполнении получателем команд «gpg —decrypt poc.enc» и «gpg poc.enc» для просмотра присланного атакующим файла poc.enc. Добиться выполнения кода можно, например, через создание файлов ~/.bash_completion или ~/.ssh/authorized_keys.
  • Возможность подмены открытого текста, показываемого пользователю при указании опции «—decrypt» и верификации с использованием отдельно поставляемых цифровых подписей (Detached Signature, создаются опцией «—detach-sig» и поставляются в отдельном sig-файле).
    Суть проблемы в том, что при раздельной отправке сообщения и sig-файла, атакующий, контролирующий промежуточный трафик (MITM), может внести в sig-файл изменения, после которых верификация останется успешной, но при просмоторе сообщения из sig-файла при помощи опции «—decrypt» будет выведено другое содержимое.

    
  echo Plaintext › plaintext
  gpg --detach-sig plaintext

  # изменение  plaintext.sig атакующим с добавлением дополнительного текста

  gpg --verify plaintext.sig plaintext # верифицировано
  gpg --decrypt plaintext.sig # верифицировано, но выводится другой текст
  • Возможность дополнения подписанного сообщения произвольными данными с сохранением успешной проверки подписи. Проблема возникает из-за обрезки данных по границе 20000 символов при вычислении хэша.
  • Некорректная проверка кодов аутентифицированного шифрования (MDC — Modification Detection Codes), позволяющая манипулировать зашифрованными пакетами так, что при расшифровке полученный контент будет обработан как другой тип пакета (например, воспринят как предназначенный для публикации открытый ключ).
  • Возможность подстановки дополнительных данных в CS-подписи (Cleartext Signature), созданные с использованием флага «—not-dash-escaped» или сконвертированные из отдельно подставляемых подписей (Detached Signature). Уязвимость может использоваться для создания у пользователя ложного впечатления о том, какие данные были фактически подписаны. Например, пользователь может загрузить из заслуживающих доверия источников корректный ключ для проверки цифровой подписи, но атакующий в ходе MITM-атаки может подменить загружаемый пользователем iso-образ и добавить в подпись к образу дополнительный хэш, таким способом, что верификация подменённого образа пройдёт успешно при наличии в системе проверочного корректного ключа.
  • Подстановка дополнительных данных в ASCII-представление CS-подписи (Cleartext Signature) через вставку символа с нулевым кодом. Уязвимость, например, позволяет вставить произвольный текст в заголовок Hash.
  • Некорректная интерпретация формата OpenPGP, из-за которой сообщение «One-Pass Signed Message» в ASCII-кодированном формате может быть обработано как сообщение «Cleartext Signature» при определённом изменении заголовка. Уязвимость позволяет заменить оригинальные подписанные данные на вредоносное содержимое, сохранив видимость успешной верификации.
  • Отсутствие явного разделения в выводе информации об успешности проверки цифровой подписи и содержимого сообщения, что позволяет создавать поддельные неподписанные сообщения, которые при выполнении «gpg —decrypt» выглядят как подлинные.
  • Возможность создания OpenPGP-сообщений, которые в gpg будут обрабатываться иначе, чем в других реализациях OpenPGP. Проблема вызвана особенностью обработки очень длинных строк в ASCII-представлени OpenPGP-данных.
  • Создание условий в процессе верификации цифровой подписи для отката алгоритма проверки хэша до небезопасного SHA1.
  • Возможность подстановки своих вторичных ключей (subkey) без их авторизации с использованием приватного компонента мастер-ключа. Атака осуществляется через добавление фальшивого хранилища ключей при помощи опции «—keyring».

Дополнительно выявлены две уязвимости в minisign, упрощённом инструментарии для создания и проверки по цифровым подписям. Обе уязвимости (1, 2) позволяют использовать управляющие последовательности терминала («e[1E») или спецсимволы («r») в поле с комментарием для модификации вывода программы, например, для замены информации о результате верификации.

Источник: http://www.opennet.ru/opennews/art.shtml?num=64517