На проходящей в Германии конференции 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" будет выведено другое содержимое.
• Возможность дополнения подписанного сообщения произвольными данными с сохранением успешной проверки подписи из-за обрезки данных по границе 20000 символов при вычислении хэша.
• Некорректная проверка кодов аутентифицированного шифрования (MDC - Modification Detection Codes), позволяющая манипулировать зашифрованными пакетами так, что при расшифровке полученный контент будет обработан как другой тип пакета (например, воспринят как предназначенный для публикации открытый ключ).
• Возможность подстановки дополнительных данных в CS-подписи (Cleartext Signature), созданные с использованием флага "--not-dash-escaped" или сконвертированные из отдельно подставляемых подписей (Detached Signature). Уязвимость может использоваться для создания у пользователя ложного впечатления о том, какие данные были фактически подписаны. Например, пользователь может загрузить из заслуживающих доверия источников корректный ключ для проверки цифровой подписи, но атакующий в ходе MITM-атаки может подменить iso-образ и добавить в подпись к образу дополнительный хэш, таким способом, что верификация подменённого образа корректным ключом пройдёт успешно.
• Подстановка дополнительных данных в CS-подписи (Cleartext Signature) в ASCII-представлении через вставку символа с нулевым кодом. Уязвимость, например, позволяет вставить произвольный текст в заголовок Hash.
• Некорректная интерпретация формата OpenPGP, из-за которой сообщение в ASCII-кодированном формате "One-Pass Signed Message" может быть обработано как сообщение "Cleartext Signature" при определённом изменении заголовка. Уязвимость позволяет заменить оригинальные подписанные данные на вредоносное содержимое, сохранив видимость успешной верификации.
• Отсутствие явного разделения в выводе информации об успешности проверки цифровой подписи и содержимого сообщения, что позволяет создавать поддельные неподписанные сообщения, которые при выполнении "gpg --decrypt" выглядят как подлинные.
• Возможность создания OpenPGP-сообщений, которые в gpg будут обрабатываться иначе, чем в других реализациях OpenPGP. Проблема вызвана особенности обработки очень длинных строк в ASCII-представлени OpenPGP-данных.
• Создание условий в процессе верификации цифровой подписи для отката алгоритма проверки хэша до небезопасного SHA1.
• Возможность подстановки своих вторичных ключей (subkey) без их авторизации с использованием приватного компонента мастер-ключа. Атака осуществляется через добавление фальшивого хранилища ключей при помощи опции "--keyring".
Дополнительно выявлены две уязвимости в minisign, упрощённом инструментарии для создания и проверки по цифровым подписям. Обе уязвимости (1, 2) позволяют использовать управляющие последовательности терминала ("\e[1E") или спецсимволы ("\r") в поле с комментарием для модификации вывода программы, например, для замены информации о результате верификации.
Уязвимости вызваны ошибками в коде для обработки данных и разбора форматов, и не связаны с брешами в криптоалгоритмах. Например, ошибка в парсере приводит к сбою при определении фактически подписанных данных и создаёт условия при которых проверяемые данные могут не совпадать с подписанными данными, что позволяет атакующему подменить открытый текст без доступа к приватному ключу.
Выявленные проблемы:
• Ошибка в коде парсера зашифрованных данных, распространяемых в формате 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-образ и добавить в подпись к образу дополнительный хэш, таким способом, что верификация подменённого образа корректным ключом пройдёт успешно.
• Подстановка дополнительных данных в CS-подписи (Cleartext Signature) в ASCII-представлении через вставку символа с нулевым кодом. Уязвимость, например, позволяет вставить произвольный текст в заголовок Hash.
• Некорректная интерпретация формата OpenPGP, из-за которой сообщение в ASCII-кодированном формате "One-Pass Signed Message" может быть обработано как сообщение "Cleartext Signature" при определённом изменении заголовка. Уязвимость позволяет заменить оригинальные подписанные данные на вредоносное содержимое, сохранив видимость успешной верификации.
• Отсутствие явного разделения в выводе информации об успешности проверки цифровой подписи и содержимого сообщения, что позволяет создавать поддельные неподписанные сообщения, которые при выполнении "gpg --decrypt" выглядят как подлинные.
• Возможность создания OpenPGP-сообщений, которые в gpg будут обрабатываться иначе, чем в других реализациях OpenPGP. Проблема вызвана особенности обработки очень длинных строк в ASCII-представлени OpenPGP-данных.
• Создание условий в процессе верификации цифровой подписи для отката алгоритма проверки хэша до небезопасного SHA1.
• Возможность подстановки своих вторичных ключей (subkey) без их авторизации с использованием приватного компонента мастер-ключа. Атака осуществляется через добавление фальшивого хранилища ключей при помощи опции "--keyring".
Дополнительно выявлены две уязвимости в minisign, упрощённом инструментарии для создания и проверки по цифровым подписям. Обе уязвимости (1, 2) позволяют использовать управляющие последовательности терминала ("\e[1E") или спецсимволы ("\r") в поле с комментарием для модификации вывода программы, например, для замены информации о результате верификации.