Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в GnuPG"	+/–
Сообщение от opennews (?), 08-Июн-18, 22:31
Опубликован (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.ru/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.ru/opennews/art.shtml?num=48741
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

3. "Уязвимость в GnuPG"	+13 +/–
Сообщение от IronMan (?), 09-Июн-18, 01:14
Я правильно понимаю: 1. GPG является наиболее мощным и доступным средством шифрования на сегодня (да и в ближайшей перспективе)? 2. За все время существования GPG так и не был скомпрометирован или взломан? Можно не бояться за свои данные?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Уязвимость в GnuPG"	–9 +/–
	Сообщение от Аноним (-), 09-Июн-18, 14:19
	>> GPG является наиболее мощным и доступным средством шифрования на сегодня (да и в ближайшей перспективе)? >>SHA-3: SHA-3 is a completely new Ага 2015 год. >>... GnuPG doesn’t support it Зато супортит скомпроментированный SHA-1 >> GPG является наиболее мощным А может немощным? >>. За все время существования GPG так и не был скомпрометирован или взломан? Маня ты статью то прочитай.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	13. "Уязвимость в GnuPG"	+4 +/–
	Сообщение от Andrey Mitrofanov (?), 09-Июн-18, 15:50
	>скомпроментированный 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 так и не был скомпрометирован или взломан? >> Маня ты статью то прочитай. Сам пошёл.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "Уязвимость в GnuPG"	+/–
	Сообщение от Andrey Mitrofanov (?), 09-Июн-18, 15:53
	>>скомпроментированный SHA-1 > --Шнайер в 2005-ом. > И да, 13 лет  <<  anytime soon. Или https://www.schneier.com/cgi-bin/mt/mt-search.cgi?search=SHA... да. >>>> GPG является наиболее мощным >> А может немо > Ложь, наглая ложь и форумная "криптография". > Сам пошёл.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	24. "Уязвимость в GnuPG"	+/–
	Сообщение от анон (?), 11-Июн-18, 17:05
	Маня, ты хотябы разберись что такое шифрование, а что есть хеширование. перед тем как чтолибо писать.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

4. "Уязвимость в GnuPG"	–3 +/–
Сообщение от ALex_hha (ok), 09-Июн-18, 01:40
Я просто оставлю это здесь https://www.opennet.ru/opennews/art.shtml?num=48596
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Уязвимость в GnuPG"	+4 +/–
	Сообщение от Аноним (-), 09-Июн-18, 01:54
	Так там не в самом GnuPG была проблема.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Уязвимость в GnuPG"	+/–
	Сообщение от Аноним (-), 09-Июн-18, 07:57
	Там совсем не в гпг было дело, а тут с некоторой натяжкой можно сказать, что уязвимость в терминале. Кстати, вот припомнить бы, чем закончились прошлый новости на тему копипастинга невидимого из браузера в терминал.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	10. "Уязвимость в GnuPG"	+1 +/–
	Сообщение от Andrey Mitrofanov (?), 09-Июн-18, 11:07
	> Я просто оставлю это здесь http://www.fsf.org/blogs/community/how-to-defend-your-encryp...
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Уязвимость в GnuPG"	+1 +/–
Сообщение от Perlovka (ok), 09-Июн-18, 09:04
> Проблема пока устранена только во FreeBSD, а в дистрибутивах Linux пока остаётся неисправленной В gentoo устранена ;)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Уязвимость в GnuPG"	–2 +/–
	Сообщение от Аноним (-), 09-Июн-18, 12:00
	Чёт мне сдаётся они её починили, как MS - поддержку gopher в IE в своё время.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

8. "Уязвимость в GnuPG"	+/–
Сообщение от Аноним (-), 09-Июн-18, 09:39
С утра прилетела обнова на OpenMediaVault. Наверное таки в дебиан исправили уже.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Уязвимость в GnuPG"	+/–
Сообщение от Аноним (-), 09-Июн-18, 09:44
В слаке уже исправили
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Уязвимость в GnuPG"	–1 +/–
Сообщение от Аноним (-), 09-Июн-18, 17:21
Проблема эта общая для всех средств, работающих через типичный терминал. Для всех. Терминал в принципе небезопасен в этом смысле.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Уязвимость в GnuPG"	–1 +/–
	Сообщение от Аноним (-), 09-Июн-18, 18:00
	Достаточно было в баше ввести тип экранированных строк без всяких левых символов, для передачи данных - и этих проблем было бы в 100 раз меньше. Но поезд ушел, это надо было делать 30 лет назад, сейчас всё так привыкли жрать кактус, что не оттащить
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Уязвимость в GnuPG"	–3 +/–
	Сообщение от Кузя (?), 09-Июн-18, 18:47
	Ну такое решение бы вступило в конфликт с простотой использования скриптовых языков. Теперь же это такой эверест гуана, что подступаться к нему никто и не пытается. Вон, systemd сделали, попробовали загнать всю эту скриптовую жуть хоть в какое-то подобие рамок, так и то вони сколько со всех сторон.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	21. "Уязвимость в GnuPG"	+/–
	Сообщение от poiu5 (?), 10-Июн-18, 08:29
	А можно просто добавить управляющий символ "ограничить управляющие символы до завершения программы которая его отправила"? Или это уж слишком?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	22. "Уязвимость в GnuPG"	–1 +/–
	Сообщение от Жабер (?), 10-Июн-18, 14:28
	Не будет обратной совместимости. Гигатонны мезозойской перловки и баша перестанут работать.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	23. "Уязвимость в GnuPG"	+/–
	Сообщение от zomg (?), 11-Июн-18, 05:37
	printf '%q\n' 'This is a #&*$string'
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

25. "Уязвимость в GnuPG"	+/–
Сообщение от timur.davletshin (ok), 02-Сен-18, 14:41
test message
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема