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.
комментариев: 9796 документов: 488 редакций: 5664
Пока официального подтверждения от OpenSSH нет, то нет смысла и поднимать панику. Если есть возможности смены ключей — пусть кто-то поменяет, хуже не будет. Но будем пока считать, что из Heartbleed не следует, что все веб и тор-серверы уязвимы ещё и по SSH.
комментариев: 9796 документов: 488 редакций: 5664
NSA Said to Exploit Heartbleed Bug for Intelligence for Years:
Очередные спекуляции на тему: «спецслужбы всё знали с самого начала». Источник сведений не приведён.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 1060 документов: 16 редакций: 32
А разве включения в handshake сообщения не обнаружатся после установления соединения?
RFC 4246:
Вроде ж проверка Hash(handshake_messages) тогда не пройдёт, или я что-то упускаю?
Это проверено на практике, опубликованные эксплоиты так и поступают, посылают heartbeat запрос сразу после получения server hello и до окончания согласования шифров. Судя по коду это верно и для запроса у клиента.
RFC прямо говорит НЕ ДОЛЖЕН посылать, но отвечать же не запрещает? В общем чудесная ошибка получилась.
Но память то уже прочитают. А соединение можно оборвать до завершения handshake. И тогда Tor клиент ничего не заметит, и предупреждений не выдаст.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 1060 документов: 16 редакций: 32
В rfc6520 ещё Hello Extenstion описан, мне сейчас интересно, как он обрабатывается.
Тогда это получается ошибка даже не в реализации, а в протоколе. Хэндшейки ещё не подтверждены, на их подлинность нельзя полагаться.
Троянский конь. Там ещё ведь и рандомные байты в нагрузку к ответу добавляют, стойкий PRNG этим не удивишь, но всё ж не спроста это.
В коде OpenSSL, умеющем heartbeat, нет проверки возможностей пира и содержимого расширения к hello сообщению, если будет запрос то будет и ответ, даже если пир использовал SSL3 протокол. Все проверки и учёт содержимого расширений находятся только в коде для запросов heartbeat, а не ответов. Всё строго по rfc6520, ага.
комментариев: 1060 документов: 16 редакций: 32
Таки нет, rfc говорит, что во время хэндшейка отвечать на heartbeet запросы не следует, этот случай явно оговорен:
Я так понимаю, в OpenSSL исправили только утечку данных из памяти, а на запросы во время хэндшейка она всё ещё
отвечает?