08.04 // Уязвимость в OpenSSL может подвергать опасности пользователей Tor и других программ
Новая уязвимость в OpenSSL 1.0 — 1.0.1 может быть использована для раскрытия данных, находящихся в памяти клиента, соединяющегося с сервером — CVE-2014-0160. Верно и обратное — раскрытие данных в памяти сервера, использующего OpenSSL, если с ним способен установить соединение злонамеренный клиент.
Использование более старых версий OpenSSL безопасно.
Проверка системной версии (не из пакета TBB):
Уязвимые на данный момент версии: 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1, 1.0.2-beta1. В состав дистрибутивов Linux и др. операционных систем после исправления уязвимости могут входить версии с таким же номером, но с добавлением номера патча из пакета. Проверьте установленную версию средствами своего пакетного менеджера.
Следующие сведения имеют отношения к компонентам Tor:
- Клиенты: Непосредственно браузер из состава Tor Browser Bundle не должен быть уязвимым, т.к. использует libnss, а не openssl. Но клиенты Tor способны отправлять информацию о том, какие сайты они посещали в пределах данной сессии своим входящим узлам. Для TBB
будутнезамедлительно выпущены новые версии Tor Browser 3.5.4 is Released; для пользователей системного тор-демона необходимо будет обновить OpenSSL и вручную перезапустить Tor. - Релеи и бриджи: узлы Tor и бриджи могут производить утечку своих среднесрочных onion-ключей (меняющихся раз в неделю) или долговременных аутентификационных ключей узлов. Атакующий, который знает идентифицирующий ключ вашего релея, может опубликовать новый дескриптор сообщающий о смене вашего местоположения (не слишком опасная атака). Если при этом атакующий может перехватывать трафик до релея, знает onion-ключ, то он может перехватывать трафик от вас до вашего релея, подменяя его адрес на свой подставной. Из-за многохоповой конструкции Tor такая атака только на один узел также не слишком опасна. В любом случае, это требует обновления OpenSSL, обновления данных в DataDirectory узла и перезапуска Tor для генерации новых ключей.
- Скрытые сервисы: у них происходит утечка долговременных аутентификационных ключей к их гвард-узлам. Как и в предыдущем крупном баге в OpenSSL
это не позволит атакующему определить местоположение скрытого сервиса, но знание его ключа позволит производить его подмену. По обновлённым сведениям IP-адрес скрытого сервиса также может быть раскрыт. Рекомендуется сменить адрес скрытого сервиса после обновления.
- Корневые авторизующие диектории: у них, помимо вышеописанных утечек узловых и мостовых ключей, может происходить утечка среднесрочных ключей подписи статистики. После обновления OpenSSL их владельцам потребуется создать новые ключи подписей. Долговременные ключи находятся в оффлайне и неподвержены атаке. Из-за прописывания отпечатков ключей в код клиентов пока не выработана стратегия смены ключей с минимальным ущербом для пользователей сети.
- Tails: использует Debian oldstable и неподвержен уязвимости.
- Orbot: уязвим; детали будут опубликованы позднее.
- Большинство серверов https://www.torproject.org потребуют обновлений и смены сертификатов.
! | [WWW] Как сообщает ведущий разработчик Tor, Роджер Динглдайн, последствия Heartbleed-уязимости для сети Tor до конца не выяснены. На данный момент установлено, что она позволяет раскрывать IP-адреса скрытых сервисов. Также подозревается существование возможности проведения Heartbleed-атаки на пользователя не только со стороны сторожевых узлов, но и производя MiTM в локальной сети — например со стороны провайдера или путём перехвата беспроводного соединения. |
Источник: Torproject Blog.
До четверга ещё надо успеть доделать сайт с
кровищем и кишкамикомиксами про уязвимость.Тогда отбой тревоги, 1.0.2 не добралась ещё до дистрибутивов и бандлов.
Точно, коммерсам и полицям надо дать знать об уязвимости заранее, чтоб воспользовались, где можно.
Опубликовали. Заметка от opennet, но тот самый случай когда чтение через гугл-транслейт будет полезней.
В оригинале
Код уже исправлен в предыдущих версиях, анонс только повышает уровень опасности.
Судя по коду, самое актуальное в случае с тором (но почему-то moderate) это Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286). Segfault происходит при разыменовывании нулевого указателя.
+1, только без гугл-транслейта.
Или понижает, т.к. дополнительно мотивирует обновиться тех, кто этого ещё не сделал.
Обновляться всё равно надо, там много узявимостей, хоть и «moderate».
В Torbrowser 4.0.5 забили на обновление openssl до 1.0.1m. Вот она жизнь в упаковке, неожиданно навалились серьезные баги в одном компоненте (браузере) и на все оставшееся внимания не хватило.
Во-первых, по вашей ссылке ничего об этом нет. Тяжело было привести ссылку на changelog, где это сказано? Кстати, системному Tor'у это нестрашно, он цепляет системный OpenSSL.
Там же:
В этом changelog отображают все изменения, для примера из 4.0.4
комментариев: 511 документов: 2 редакций: 70
Теперь есть сайт
с кровью и кишками,всё как положено (https://weakdh.org/):Здесь есть рекомендации держателям серверов, что делать (в частности, для OpenSSH-серверов там тоже есть, что менять; правда, дефолты в самых новых версиях вроде бы таковы, что менять ничего не надо, там по умолчанию всё ОК):
По той же ссылке (JS нужен) проверил pgpru.com. Результат:
Ещё:
Есть официальная работа со всем исследованием. Её основной рекомендательный посыл в том, что самое правильное решение — всем бежать на ECC с Curve25519. Tor уже там:
Стр. 11:
Правда, непонятно, они вышеперечисленных заранее тайно предупредили ещё до публикации работы и анонса бага или наравне со всеми, одновременно.
Для OpenVPN информацию с рекомендациями на сайте не выложили.
TBB в честь logjam-атаки апдейтится до 4.5.2, но похоже, что только из-за TorBrowser'а, а OpenSSL и Tor к этой атаке непосредственного отношения не имеют.
P.S. Новость на opennet от 20-го мая.
А на ЛОРе уже LogJam версии 4.6.0.
комментариев: 511 документов: 2 редакций: 70
Файл moduli, судя по man moduli, используется только sshd, но опция KexAlgorithms есть как для ssh_config, так и для sshd_config. Непонятно, нужно ли её менять для обеих сторон — клиентской и серверной.
В moduli содержатся параметры для всех ключей от 1024-ёх до 8192-ух битов. После выполнения инструкции в файле остаются праймы (вручную сгенерированные) только для 2048-ми бит, для больших ничего не будет. Это тоже не очень хорошо.
комментариев: 511 документов: 2 редакций: 70
Хорошее разъяснение на эту тему и LogJam вообще от Ааронсона:
комментариев: 450 документов: 10 редакций: 13