id: Гость   вход   регистрация
текущее время 22:39 02/04/2020
Владелец: unknown (создано 08/04/2014 11:32), редакция от 12/04/2014 17:52 (автор: unknown) Печать
Категории: софт, анонимность, криптоанализ, инфобезопасность, tor, ошибки и баги, уязвимости, стандарты, атаки, ssl, разное, события
https://www.pgpru.com/Новости/2014/УязвимостьВOpenSSLМожетПодвергатьОпасностиПользователейTorИДругихПрограмм
создать
просмотр
редакции
ссылки

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 и др. операционных систем после исправления уязвимости могут входить версии с таким же номером, но с добавлением номера патча из пакета. Проверьте установленную версию средствами своего пакетного менеджера.


Heartbleed (8 Кб)


Эта уязвимость, получившая название "Heartbleed" («кровоточащее сердце»), затрагивает множество программ, не только Tor — каждый, кто запускает https-сервер или клиент может быть потенциальным противником или жертвой: возможна утечка памяти всех процессов, использующих OpenSSL (например веб-сервера, VPN и др). Если вам нужна стойкая анонимность и приватность в интернете, то стоит подумать о прекращении использования интернета на ближайшие несколько дней до исправления уязвимости.


Уязвимость не была обнаружена с марта 2012 года.


Следующие сведения имеют отношения к компонентам Tor:


  1. Клиенты: Непосредственно браузер из состава Tor Browser Bundle не должен быть уязвимым, т.к. использует libnss, а не openssl. Но клиенты Tor способны отправлять информацию о том, какие сайты они посещали в пределах данной сессии своим входящим узлам. Для TBB будут незамедлительно выпущены новые версии Tor Browser 3.5.4 is Released; для пользователей системного тор-демона необходимо будет обновить OpenSSL и вручную перезапустить Tor.
  2. Релеи и бриджи: узлы Tor и бриджи могут производить утечку своих среднесрочных onion-ключей (меняющихся раз в неделю) или долговременных аутентификационных ключей узлов. Атакующий, который знает идентифицирующий ключ вашего релея, может опубликовать новый дескриптор сообщающий о смене вашего местоположения (не слишком опасная атака). Если при этом атакующий может перехватывать трафик до релея, знает onion-ключ, то он может перехватывать трафик от вас до вашего релея, подменяя его адрес на свой подставной. Из-за многохоповой конструкции Tor такая атака только на один узел также не слишком опасна. В любом случае, это требует обновления OpenSSL, обновления данных в DataDirectory узла и перезапуска Tor для генерации новых ключей.
  3. Скрытые сервисы: у них происходит утечка долговременных аутентификационных ключей к их гвард-узлам. Как и в предыдущем крупном баге в OpenSSL это не позволит атакующему определить местоположение скрытого сервиса, но знание его ключа позволит производить его подмену. По обновлённым сведениям IP-адрес скрытого сервиса также может быть раскрыт. Рекомендуется сменить адрес скрытого сервиса после обновления.
  4. Корневые авторизующие диектории: у них, помимо вышеописанных утечек узловых и мостовых ключей, может происходить утечка среднесрочных ключей подписи статистики. После обновления OpenSSL их владельцам потребуется создать новые ключи подписей. Долговременные ключи находятся в оффлайне и неподвержены атаке. Из-за прописывания отпечатков ключей в код клиентов пока не выработана стратегия смены ключей с минимальным ущербом для пользователей сети.
  5. Tails: использует Debian oldstable и неподвержен уязвимости.
  6. Orbot: уязвим; детали будут опубликованы позднее.
  7. Большинство серверов https://www.torproject.org потребуют обновлений и смены сертификатов.

![WWW] Как сообщает ведущий разработчик Tor, Роджер Динглдайн, последствия Heartbleed-уязимости для сети Tor до конца не выяснены. На данный момент установлено, что она позволяет раскрывать IP-адреса скрытых сервисов. Также подозревается существование возможности проведения Heartbleed-атаки на пользователя не только со стороны сторожевых узлов, но и производя MiTM в локальной сети — например со стороны провайдера или путём перехвата беспроводного соединения.

Источник: Torproject Blog.


 
На страницу: 1, 2, 3, 4, 5, ... , 11, 12, 13, 14, 15 След.
Комментарии [скрыть комментарии/форму]
— Гость (08/04/2014 19:16)   <#>

It really annoys me, when ...
... a bug was fixed after hours and hours of trouble shooting, only to stumble upon the next bug.

Это его девиз?


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).
— SATtva (08/04/2014 19:30)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Tor-клиент использует системный OpenSSL?

Смотря какие клиенты. Standalone Tor использует системный; TBB — забандленный.

Когда же?! И зачем, если ошибка в системном OpenSSL, а не в самом TorBrowser?

TBB использует собственную статическую библиотеку OpenSSL вместо системной.

Этого точно достаточно? ... Надо делать тотальный upgrade?

Если те или иные пакеты не линкуются с openssl статически (чего во вменяемых дистрибутивах стараются не допускать именно по причине сложности обновлений), то достаточно обновить одну только уязвимую библиотеку.
— Гость (08/04/2014 19:32)   <#>
Congratulations, The heartbeat extension was not found while fingerprinting your SSL Sever ( pgpru.com )!

Это правда? Вовремя обновили или просто версия OpenSSL на сервере была старой?
— SATtva (08/04/2014 19:39)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Старая версия.
— Гость (08/04/2014 19:41)   <#>

А в тексте новости:

Торбраузер не должен быть уязвимым, т.к. использует libnss, а не openssl.

Мне одному кажется, что здесь противоречие? Есть TBB-Tor и TBB-TorBrowser. Кто что из них использует? Является ли libnss полноценной заменой функционала openssl?

Unlike OpenSSL and GnuTLS, which are crypto and SSL libraries, NSS is a more complete system with key management support, PKCS#11 support, etc.
— Гость (08/04/2014 19:42)   <#>

Только guard контактирует с клиентом, и только контактирующий может запросить ответить на heartbeat вопрос.


Никто трафик не трогает, копаются в памяти процесса. У атакующего нет возможности запросить конкретную область памяти, что попадёт то и получает. Игра в рулетку, где призом может стать золотой ключ, а может и не стать.

Только она динамическая. Пересобирать весь бандл не нужно, можно поменять файлы с openssl (dll или so) на свежие, если не хочется ждать.
— Гость (08/04/2014 19:44)   <#>

Которая тоже содержит этот же баг?
— SATtva (08/04/2014 19:49)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
А в тексте новости:
Торбраузер не должен быть уязвимым, т.к. использует libnss, а не openssl.

Это Firefox из бандла (и любой другой) использует NSS. Tor-клиент работает на OpenSSL. Так что, если в бандле не устаревшая версия OpenSSL, он так же уязвим, как и standalone-клиенты.
— Гость (08/04/2014 19:50)   <#>

Torbrowser(Firefox) использует libnss, Tor использует openssl. Теоретически libnss можно использовать вместо openssl, в коде даже серверная часть есть. Но это потребует переписывания кода Tor, т.к. интерфейсы у библиотек разные, кроме того используются специфические возможности openssl. И главное ради чего?
— Гость (08/04/2014 20:02)   <#>
А воздействие на SSH каково? Также можно, в принципе, украсть ключи? Их лучше все перегенерировать?


Ради того, чтобы не сидеть на софте, написанном обезьянами. Полноценно форкнуть FireFox TorProject не может, поэтому Firefox просто патчится, а вот форкнуть криптолибу, возможно, им по силам. С другой стороны, как говорят, в OpenSSL находят так много дыр, потому что он повсеместно распространён, а GnuTLS смотрится лучше, возможно, в большей степени потому, что его мало ковыряют. Ну, это стандартная дилемма, неуловимым Джо можно все проблемы в безопасности продукта объяснить, но OpenSSL глобально лажается далеко не первый раз, критикуют его уже давно, и все кому не лень.
— Гость (09/04/2014 06:20)   <#>

SSH использует криптографические функции OpenSSL, но не использует протокол, в котором была уязвимость, поэтому на SSH эта уязвимость никак не влияет. В прошлый раз уязвимость была другая, гораздо хуже. Тут — чтение памяти процесса, использующего протокол TLS v1.2; тогда — ГПСЧ был уязвим, что автоматически ломало все ключи, все сессии и вообще всё, что было. Потом, произвольное исполнение кода тут не получить, в чужой процесс из основного тоже не пролезть: если б было удаленное исполнение кода, то было бы можно, но только через чтение памяти — нельзя.
— Гость (09/04/2014 06:24)   <#>

Тем не менее, все SSL-сертификаты всё равно настоятельно рекомендуется всем поменять. Если атакующий знал об уязвимости, он мог украсть приватные ключи до закрытия уязвимости. Все пароли, используемые для HTTPS-сайтов, по этой причине тоже рекомендуется поменять.
— Гость (09/04/2014 06:47)   <#>

Если адаптировать цитату из той новости на этот случай, то будет примерно так:

Все пользователи Debian и Ubuntu должны исходить из того, что все шифровальные ключи для SSL, SSH и OpenVPN, сгенерированные ими в последние два года, скомпрометированы! Действуйте исходя из этого.

Кстати, «правило двух лет» Вагнера точно выполнено для обеих уязвимостей. ☺

Как ко всему этому относиться?
Это обычное дело. Ошибки в openssl по три раза подряд исправляют.

Прошло 9 лет.

Разбудите меня через 10 лет и спросите, что творится в ИБ, и я вам сразу отвечу: фатальные дыры в OpenSSL.
— unknown (09/04/2014 09:48)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Поправьте, если не так, но исходя из обрывочных сведений, я понимаю три вещи.

  1. Если бы Firefox/TorBrowser использовал OpenSSL, то злонамеренные https-сайты могли бы читать содержимое процесса браузера (пароли, куки, соседние вкладки — кому там не нравилось, что при «смене личины» TorBrowser сбрасывает всё внутреннее состояние? Даже без уязвимости сохранение набора открытых вкладок между сеансами приводит к профилированию на экситах.) Но, к счастью, сам патченный FF из торбраузера не использует OpenSSL. А вот Tor-клиент, который запускается торбраузером, привязан к OpenSSL. И злонамеренный гвард может покопаться в его памяти — выудить список цепочек сессии, адреса onion-сайтов, фрагменты нешифрованного трафика. При том, что гвард знает айпишник пользователя. Внешний наблюдатель (провайдер) этого сделать не может, так как вклиниться в соединение нельзя, читать данные можно только из установленного соединения. Но провайдер может украсть по этой дыре ключ от гварда, подменять его IP и также под его видом ковыряться в памяти Tor-клиента пользователя.
  2. Касательно сертификатов сайтов. Любой может соединиться с сайтом по https. Значит он может выудить закрытую часть его SSL-сертификата. Кроме того, при утечке памяти туда могут попадать в расшифрованном виде пароли соседних пользователей, куки, IP и пр. Это вообще касается не только веб, но и почтовых протоколов, мессенджеров, VPN с централизованно доступным сервисом, доступным при участии OpenSSL.
  3. У SSH нет прямого использования этого протокола. Но допустим, что он бы был. Если у пользователя только свой доверенный SSH-сервер на удалённом хосте, к которому нет доступа у других, то они не смогут приконнектится, не зная ключа/пароля и не смогут удалённо читать память. При попытке скана SSH, всех будет отрубать до того, как они могут что-то сделать.
— SATtva (09/04/2014 10:14)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Старая версия.

Тем не менее, все SSL-сертификаты всё равно настоятельно рекомендуется всем поменять.

Версия старая не из-за даунгрейда в связи с уязвимостью, переход на 1.0.1 никогда не производился.

Поправьте, если не так, но исходя из обрывочных сведений, я понимаю три вещи.

По-моему, всё верно.
На страницу: 1, 2, 3, 4, 5, ... , 11, 12, 13, 14, 15 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3