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.
Это его девиз?
Tor-клиент использует системный OpenSSL? Почему только guard'ам, а не всем остальным? А расшифровать трафик между guard'ом и Tor-клиентом из-за этой ошибки нельзя что ли?
Когда же?! И зачем, если ошибка в системном OpenSSL, а не в самом TorBrowser? Чтоб лишние предупреждения, призывающие обновиться, выдавать юзерам?
Этого точно достаточно? Почитал топик на хабре, после этого обновил не только OpenSSL,1 но и SSH2 и libssl3 (Всё правильно обновилось? Смотрел /var/log/apt/history.log), причём я не уверен, что это полный список того, что следует в системе обновить... Надо делать тотальный upgrade? Как можно разом установить все обновления безопасности для всего в Debian?
Точна не слыщком, гаварыш?
1Upgrade: openssl:amd64 (1.0.1e-2, 1.0.1e-2+deb7u6).
2Upgrade: openssh-server:amd64 (6.0p1-4, 6.0p1-4+deb7u1), openssh-client:amd64 (6.0p1-4, 6.0p1-4+deb7u1).
3Upgrade: libcurl3:amd64 (7.26.0-1+wheezy3, 7.26.0-1+wheezy8), libcurl3:i386 (7.26.0-1+wheezy3, 7.26.0-1+wheezy8), libssl1.0.0:amd64 (1.0.1e-2, 1.0.1e-2+deb7u6), libssl1.0.0:i386 (1.0.1e-2, 1.0.1e-2+deb7u6).
комментариев: 11558 документов: 1036 редакций: 4118
Смотря какие клиенты. Standalone Tor использует системный; TBB — забандленный.
TBB использует собственную статическую библиотеку OpenSSL вместо системной.
Если те или иные пакеты не линкуются с openssl статически (чего во вменяемых дистрибутивах стараются не допускать именно по причине сложности обновлений), то достаточно обновить одну только уязвимую библиотеку.
Это правда? Вовремя обновили или просто версия OpenSSL на сервере была старой?
комментариев: 11558 документов: 1036 редакций: 4118
А в тексте новости:
Мне одному кажется, что здесь противоречие? Есть TBB-Tor и TBB-TorBrowser. Кто что из них использует? Является ли libnss полноценной заменой функционала openssl?
Только guard контактирует с клиентом, и только контактирующий может запросить ответить на heartbeat вопрос.
Никто трафик не трогает, копаются в памяти процесса. У атакующего нет возможности запросить конкретную область памяти, что попадёт то и получает. Игра в рулетку, где призом может стать
золотойключ, а может и не стать.Только она динамическая. Пересобирать весь бандл не нужно, можно поменять файлы с openssl (dll или so) на свежие, если не хочется ждать.
Которая тоже содержит этот же баг?
комментариев: 11558 документов: 1036 редакций: 4118
Это Firefox из бандла (и любой другой) использует NSS. Tor-клиент работает на OpenSSL. Так что, если в бандле не устаревшая версия OpenSSL, он так же уязвим, как и standalone-клиенты.
Torbrowser(Firefox) использует libnss, Tor использует openssl. Теоретически libnss можно использовать вместо openssl, в коде даже серверная часть есть. Но это потребует переписывания кода Tor, т.к. интерфейсы у библиотек разные, кроме того используются специфические возможности openssl. И главное ради чего?
Ради того, чтобы не сидеть на софте, написанном обезьянами. Полноценно форкнуть FireFox TorProject не может, поэтому Firefox просто патчится, а вот форкнуть криптолибу, возможно, им по силам. С другой стороны, как говорят, в OpenSSL находят так много дыр, потому что он повсеместно распространён, а GnuTLS смотрится лучше, возможно, в большей степени потому, что его мало ковыряют. Ну, это стандартная дилемма, неуловимым Джо можно все проблемы в безопасности продукта объяснить, но OpenSSL глобально лажается далеко не первый раз, критикуют его уже давно, и все кому не лень.
SSH использует криптографические функции OpenSSL, но не использует протокол, в котором была уязвимость, поэтому на SSH эта уязвимость никак не влияет. В прошлый раз уязвимость была другая, гораздо хуже. Тут — чтение памяти процесса, использующего протокол TLS v1.2; тогда — ГПСЧ был уязвим, что автоматически ломало все ключи, все сессии и вообще всё, что было. Потом, произвольное исполнение кода тут не получить, в чужой процесс из основного тоже не пролезть: если б было удаленное исполнение кода, то было бы можно, но только через чтение памяти — нельзя.
Тем не менее, все SSL-сертификаты всё равно настоятельно рекомендуется всем поменять. Если атакующий знал об уязвимости, он мог украсть приватные ключи до закрытия уязвимости. Все пароли, используемые для HTTPS-сайтов, по этой причине тоже рекомендуется поменять.
Если адаптировать цитату из той новости на этот случай, то будет примерно так:
Кстати, «правило двух лет» Вагнера точно выполнено для обеих уязвимостей. ☺
Прошло 9 лет.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
Версия старая не из-за даунгрейда в связи с уязвимостью, переход на 1.0.1 никогда не производился.
По-моему, всё верно.