Опубликован (https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/0004...) выпуск инструментария GnuPG 2.2.8 (https://www.gnupg.org/) (GNU Privacy Guard), совместимого со стандартами OpenPGP (RFC-4880 (https://tools.ietf.org/html/rfc4880)) и S/MIME, и предоставляющего утилиты для шифрования данных, работы с электронными подписями, управления ключами и доступа к публичным хранилищам ключей. В новой версии устранена уязвимость (CVE-2018-12020 (https://security-tracker.debian.org/tracker/CVE-2018-12020)), позволяющая исказить сообщение о результатах проверки цифровой подписи при использовании утилиты gpg. Уязвимость проявляется во всех версиях GnuPG и на всех платформах.Проблема вызвана отсутствием должной проверки имени файла, которое может включаться в подписанное или зашифрованное сообщение в качестве информации об исходном файле. В процессе расшифровки и проверки цифровой подписи данное имя выводится на экран или в лог, но из-за отсутствия проверки может включать управляющие символы, в том числе перевод строки и команды для манипуляции терминалом. При удачной атаке уязвимость позволяет подменить сообщение об ошибке проверки на подтверждение достоверности при выводе в терминал или осуществить подстановку несуществующей строки в лог.
В случае вызова gpg из других программ сообщения со статусом проверки цифровой подписи создаются при помощи опции "--status-fd N", где N - файловый дескриптор. Если в опцию передан номер дескриптора 2 (по умолчанию), то сообщение будет выведено в стандартный поток stderr. Злоумышленник может воспользоваться данной особенностью и скомпоновать управляющие символы в имени файла для изменения выдаваемой gpg строки с результатами проверки цифровой подписи.
Проблема пока устранена только во FreeBSD (http://www.vuxml.org/freebsd/7da0417f-6b24-11e8-84cc-002590a...), а в дистрибутивах Linux пока остаётся неисправленной (Debian (https://security-tracker.debian.org/tracker/CVE-2018-12020), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-12020), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/CVE-2018-1...), SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2018-12020)). Проблема не затрагивает приложения, которые для вызова функций 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-блоков при атаках (https://www.opennet.dev/opennews/art.shtml?num=48597) на почтовые клиенты. Попытки расшифровки сообщения без использования MDC теперь будут приводить к выводу фатальной ошибки, даже при использовании устаревших шифров. Для переведения ошибки в разряд нефатальных предупреждений следует явно указать опцию "--ignore-mdc-error". При шифровании сообщений MDC теперь используется во всех случаях, независимо от настроек и алгоритмов (для отключения можно явно указать опцию "--rfc2440"). Опции "--no-mdc-warn", "--force-mdc", "--no-force-mdc",
"--disable-mdc" и "--no-disable-mdс" отныне игнорируются.
URL: https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/0004...
Новость: https://www.opennet.dev/opennews/art.shtml?num=48741
Я правильно понимаю:1. GPG является наиболее мощным и доступным средством шифрования на сегодня (да и в ближайшей перспективе)?
2. За все время существования GPG так и не был скомпрометирован или взломан? Можно не бояться за свои данные?
>> GPG является наиболее мощным и доступным средством шифрования на сегодня (да и в ближайшей перспективе)?
>>SHA-3: SHA-3 is a completely newАга 2015 год.
>>... GnuPG doesn’t support itЗато супортит скомпроментированный SHA-1
>> GPG является наиболее мощнымА может немощным?
>>. За все время существования GPG так и не был скомпрометирован или взломан?
Маня ты статью то прочитай.
>скомпроментированный SHA-1" 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. ""
--Шнайер в 2005-ом.
И да, 13 лет << anytime soon.
>>> GPG является наиболее мощным
> А может немоЛожь, наглая ложь и форумная "криптография".
>>>. За все время существования GPG так и не был скомпрометирован или взломан?
>> Маня ты статью то прочитай.Сам пошёл.
>>скомпроментированный SHA-1
> --Шнайер в 2005-ом.
> И да, 13 лет << anytime soon.Или https://www.schneier.com/cgi-bin/mt/mt-search.cgi?search=SHA... да.
>>>> GPG является наиболее мощным
>> А может немо
> Ложь, наглая ложь и форумная "криптография".
> Сам пошёл.
Маня, ты хотябы разберись что такое шифрование, а что есть хеширование.
перед тем как чтолибо писать.
Я просто оставлю это здесь
Так там не в самом GnuPG была проблема.
Там совсем не в гпг было дело, а тут с некоторой натяжкой можно сказать, что уязвимость в терминале. Кстати, вот припомнить бы, чем закончились прошлый новости на тему копипастинга невидимого из браузера в терминал.
> Я просто оставлю это здесьhttp://www.fsf.org/blogs/community/how-to-defend-your-encryp...
> Проблема пока устранена только во FreeBSD, а в дистрибутивах Linux пока остаётся неисправленнойВ gentoo устранена ;)
Чёт мне сдаётся они её починили, как MS - поддержку gopher в IE в своё время.
С утра прилетела обнова на OpenMediaVault. Наверное таки в дебиан исправили уже.
В слаке уже исправили
Проблема эта общая для всех средств, работающих через типичный терминал. Для всех. Терминал в принципе небезопасен в этом смысле.
Достаточно было в баше ввести тип экранированных строк без всяких левых символов, для передачи данных - и этих проблем было бы в 100 раз меньше. Но поезд ушел, это надо было делать 30 лет назад, сейчас всё так привыкли жрать кактус, что не оттащить
Ну такое решение бы вступило в конфликт с простотой использования скриптовых языков. Теперь же это такой эверест гуана, что подступаться к нему никто и не пытается. Вон, systemd сделали, попробовали загнать всю эту скриптовую жуть хоть в какое-то подобие рамок, так и то вони сколько со всех сторон.
А можно просто добавить управляющий символ "ограничить управляющие символы до завершения программы которая его отправила"?
Или это уж слишком?
Не будет обратной совместимости. Гигатонны мезозойской перловки и баша перестанут работать.
printf '%q\n' 'This is a #&*$string'
test message