Уязвимость в GnuPG

08.06.2018 22:03

Опубликован выпуск инструментария GnuPG 2.2.8 (GNU Privacy Guard), совместимого со стандартами OpenPGP (RFC-4880) и S/MIME, и предоставляющего утилиты для шифрования данных, работы с электронными подписями, управления ключами и доступа к публичным хранилищам ключей. В новой версии устранена уязвимость (CVE-2018-12020), позволяющая исказить сообщение о результатах проверки цифровой подписи при использовании утилиты gpg. Уязвимость проявляется во всех версиях GnuPG и на всех платформах.

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

В случае вызова gpg из других программ сообщения со статусом проверки цифровой подписи создаются при помощи опции "--status-fd N", где N - файловый дескриптор. Если в опцию передан номер дескриптора 2 (по умолчанию), то сообщение будет выведено в стандартный поток stderr. Злоумышленник может воспользоваться данной особенностью и скомпоновать управляющие символы в имени файла для изменения выдаваемой gpg строки с результатами проверки цифровой подписи.

Проблема пока устранена только во FreeBSD, а в дистрибутивах Linux пока остаётся неисправленной (Debian, RHEL, Ubuntu, SUSE). Проблема не затрагивает приложения, которые для вызова функций GnuPG используют библиотеку GPGME, которая применяется в большинстве современных почтовых клиентов, включая GpgOL и KMail (пользователям Mutt следует проверить, что активен режим "set crypt_use_gpgme"). Проблема также не затрагивает приложения, которые вызывают gpg без опции "--verbose" (данный режим также должен быть отключен в файле конфигурации) или с указанием отдельно выделенного файлового дескриптора в опции "--status-fd" (по умолчанию для вывода лога используется stderr). В качестве обходного пути защиты рекомендуется явно указывать опцию "--no-verbose" при вызове gpg или перенаправить вывод лога в другой файл, например "--log-file /dev/null".

В выпуске GnuPG 2.2.8 также изменено поведение, касающееся применения режима аутентифицированного шифрования (MDC - Modification Detection Codes) с целью дополнительной защиты от подмены CFB-блоков при атаках на почтовые клиенты. Попытки расшифровки сообщения без использования MDC теперь будут приводить к выводу фатальной ошибки, даже при использовании устаревших шифров. Для переведения ошибки в разряд нефатальных предупреждений следует явно указать опцию "--ignore-mdc-error". При шифровании сообщений MDC теперь используется во всех случаях, независимо от настроек и алгоритмов (для отключения можно явно указать опцию "--rfc2440"). Опции "--no-mdc-warn", "--force-mdc", "--no-force-mdc", "--disable-mdc" и "--no-disable-mdс" отныне игнорируются.

Дополнение: Опубликован отчёт с примером практических методов эксплуатации уязвимости в Enigmail, GPGTools и python-gnupg.

исправить +10 +/–

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/48741-gnupg

Ключевые слова: gnupg, gpg

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (20)

1.3, IronMan (?), 01:14, 09/06/2018 [ответить] [﹢﹢﹢] [ · · · ]

+13 +/–

Я правильно понимаю:

1. GPG является наиболее мощным и доступным средством шифрования на сегодня (да и в ближайшей перспективе)?

2. За все время существования GPG так и не был скомпрометирован или взломан? Можно не бояться за свои данные?

2.12, Аноним (-), 14:19, 09/06/2018 [^] [^^] [^^^] [ответить]

–9 +/–

>> GPG является наиболее мощным и доступным средством шифрования на сегодня (да и в ближайшей перспективе)?
>>SHA-3: SHA-3 is a completely new

Ага 2015 год.
>>... GnuPG doesn’t support it

Зато супортит скомпроментированный SHA-1
>> GPG является наиболее мощным

А может немощным?

>>. За все время существования GPG так и не был скомпрометирован или взломан?

Маня ты статью то прочитай.

3.13, Andrey Mitrofanov (?), 15:50, 09/06/2018 [^] [^^] [^^^] [ответить]

+4 +/–

>скомпроментированный SHA-1

[I]" For the average Internet user, this news is not a cause for panic. No one is going to be breaking digital signatures or reading encrypted messages anytime soon. The electronic world is no less secure after these announcements than it was before. ""[/I]

--Шнайер в 2005-ом.

И да, 13 лет << anytime soon.

>>> GPG является наиболее мощным
> А может немо

Ложь, наглая ложь и форумная "криптография".

>>>. За все время существования GPG так и не был скомпрометирован или взломан?
>> Маня ты статью то прочитай.

Сам пошёл.

4.14, Andrey Mitrofanov (?), 15:53, 09/06/2018 [^] [^^] [^^^] [ответить]

+/–

>>скомпроментированный SHA-1
> --Шнайер в 2005-ом.
> И да, 13 лет << anytime soon.

Или https://www.schneier.com/cgi-bin/mt/mt-search.cgi?search=SHA-1&__mode=tag&Incl да.

>>>> GPG является наиболее мощным
>> А может немо
> Ложь, наглая ложь и форумная "криптография".
> Сам пошёл.

3.24, анон (?), 17:05, 11/06/2018 [^] [^^] [^^^] [ответить]	+/–
Маня, ты хотябы разберись что такое шифрование, а что есть хеширование. перед тем как чтолибо писать.

1.4, ALex_hha (ok), 01:40, 09/06/2018 [ответить] [﹢﹢﹢] [ · · · ]	–3 +/–
Я просто оставлю это здесь https://www.opennet.ru/opennews/art.shtml?num=48596

2.5, Аноним (-), 01:54, 09/06/2018 [^] [^^] [^^^] [ответить]	+4 +/–
Так там не в самом GnuPG была проблема.

3.6, Аноним (-), 07:57, 09/06/2018 [^] [^^] [^^^] [ответить]	+/–
Там совсем не в гпг было дело, а тут с некоторой натяжкой можно сказать, что уязвимость в терминале. Кстати, вот припомнить бы, чем закончились прошлый новости на тему копипастинга невидимого из браузера в терминал.

2.10, Andrey Mitrofanov (?), 11:07, 09/06/2018 [^] [^^] [^^^] [ответить]	+1 +/–
> Я просто оставлю это здесь http://www.fsf.org/blogs/community/how-to-defend-your-encrypted-emails-agains

1.7, Perlovka (ok), 09:04, 09/06/2018 [ответить] [﹢﹢﹢] [ · · · ]	+1 +/–
> Проблема пока устранена только во FreeBSD, а в дистрибутивах Linux пока остаётся неисправленной В gentoo устранена ;)

2.11, Аноним (-), 12:00, 09/06/2018 [^] [^^] [^^^] [ответить]	–2 +/–
Чёт мне сдаётся они её починили, как MS - поддержку gopher в IE в своё время.

1.8, Аноним (-), 09:39, 09/06/2018 [ответить] [﹢﹢﹢] [ · · · ]	+/–
С утра прилетела обнова на OpenMediaVault. Наверное таки в дебиан исправили уже.

1.9, Аноним (-), 09:44, 09/06/2018 [ответить] [﹢﹢﹢] [ · · · ]	+/–
В слаке уже исправили

1.15, Аноним (-), 17:21, 09/06/2018 [ответить] [﹢﹢﹢] [ · · · ]	–1 +/–
Проблема эта общая для всех средств, работающих через типичный терминал. Для всех. Терминал в принципе небезопасен в этом смысле.

2.16, Аноним (-), 18:00, 09/06/2018 [^] [^^] [^^^] [ответить]	–1 +/–
Достаточно было в баше ввести тип экранированных строк без всяких левых символов, для передачи данных - и этих проблем было бы в 100 раз меньше. Но поезд ушел, это надо было делать 30 лет назад, сейчас всё так привыкли жрать кактус, что не оттащить

3.17, Кузя (?), 18:47, 09/06/2018 [^] [^^] [^^^] [ответить]	–3 +/–
Ну такое решение бы вступило в конфликт с простотой использования скриптовых языков. Теперь же это такой эверест гуана, что подступаться к нему никто и не пытается. Вон, systemd сделали, попробовали загнать всю эту скриптовую жуть хоть в какое-то подобие рамок, так и то вони сколько со всех сторон.

4.21, poiu5 (?), 08:29, 10/06/2018 [^] [^^] [^^^] [ответить]	+/–
А можно просто добавить управляющий символ "ограничить управляющие символы до завершения программы которая его отправила"? Или это уж слишком?

5.22, Жабер (?), 14:28, 10/06/2018 [^] [^^] [^^^] [ответить]	–1 +/–
Не будет обратной совместимости. Гигатонны мезозойской перловки и баша перестанут работать.

6.23, zomg (?), 05:37, 11/06/2018 [^] [^^] [^^^] [ответить]	+/–
printf '%q\n' 'This is a #&*$string'

1.25, timur.davletshin (ok), 14:41, 02/09/2018 [ответить] [﹢﹢﹢] [ · · · ]	+/–
test message

игнорирование участников | лог модерирования

Добавить комментарий

Текст: