id: Гость   вход   регистрация
текущее время 22:20 28/03/2024
Владелец: 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, ... , 4, 5, 6, 7, 8, ... , 15 След.
Комментарии [скрыть комментарии/форму]
— unknown (11/04/2014 16:11)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Пока убрал эту вставку из новости. Где-то были обсуждения, что в нормальном случае на хосте лежат только открытые ключи самого хоста, так что если только кто-то может митмить хост. Иногда на одном хосте, к которому коннектятся по ssh/sftp лежат закрытые ключи от других хостов, которыми должны в этот же момент воспользоваться. И это надо как-то переползти из кучи какого-нибудт апача в память процесса ssh.

Пока официального подтверждения от OpenSSH нет, то нет смысла и поднимать панику. Если есть возможности смены ключей — пусть кто-то поменяет, хуже не будет. Но будем пока считать, что из Heartbleed не следует, что все веб и тор-серверы уязвимы ещё и по SSH.
— Гость (11/04/2014 19:25)   <#>
Сердечко заслужило отдельной статьи википедии.
— unknown (12/04/2014 12:09, исправлен 12/04/2014 12:10)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

NSA Said to Exploit Heartbleed Bug for Intelligence for Years:


The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said.

Очередные спекуляции на тему: «спецслужбы всё знали с самого начала». Источник сведений не приведён.

— unknown (12/04/2014 12:46)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А вот Роджер теперь пишет, что IP-адреса скрытых сервисов вскрываются, провайдер (любой локальный атакующий) может вскрывать соединения пользователя с сетью Tor, даже не компрометируя гвард.
— sentaus (12/04/2014 12:57)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Вы про это?
but I think OpenSSL
lets you ask for a heartbeat during the SSL handshake. If so, that means
any local network mitm attacker, not just your entry guard, can intercept
your outgoing TCP connection and ask you for some heartbeats.



А разве включения в handshake сообщения не обнаружатся после установления соединения?
RFC 4246:

7.4.9. Finished
The Finished message is the first one protected with the just
negotiated algorithms, keys, and secrets. Recipients of Finished
messages MUST verify that the contents are correct. Once a side
has sent its Finished message and received and validated the
Finished message from its peer, it may begin to send and receive
application data over the connection.

struct {
opaque verify_data[verify_data_length];
} Finished;

verify_data
PRF(master_secret, finished_label, Hash(handshake_messages))
[0..verify_data_length-1];

Hash denotes a Hash of the handshake messages.

Вроде ж проверка Hash(handshake_messages) тогда не пройдёт, или я что-то упускаю?
— Гость (12/04/2014 13:02)   <#>

Это проверено на практике, опубликованные эксплоиты так и поступают, посылают heartbeat запрос сразу после получения server hello и до окончания согласования шифров. Судя по коду это верно и для запроса у клиента.
RFC прямо говорит НЕ ДОЛЖЕН посылать, но отвечать же не запрещает? В общем чудесная ошибка получилась.
— Гость (12/04/2014 13:05)   <#>

Но память то уже прочитают. А соединение можно оборвать до завершения handshake. И тогда Tor клиент ничего не заметит, и предупреждений не выдаст.
— unknown (12/04/2014 13:09)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Возможно, что сеть Tor мониторилась и существенная часть информации, проходящей между узлами, была раскрыта комбинацией Heartbleed-атаки с другими способами (MiTM, сравнение корреляций, сопоставление раскрытых ключей и пр.).
— Гость (12/04/2014 13:33)   <#>
Да, кстати, heartbeat это вообще отдельный тип записи (record), это не данные и не хэндшейк. Похоже этот обмен пульсами проходит вообще не замеченным?
— Гость (12/04/2014 13:51)   <#>
Судя по коду и следуя логике RFC, MitM с использованием heartbleed должен проходить и проходит незамеченным. Можно затормозить обмен handshake сообщениями между пирами и не спеша, насколько хватит у пиров тайм-аута, почитывать память с обеих сторон.
— sentaus (12/04/2014 14:07, исправлен 12/04/2014 14:12)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Да, кстати, heartbeat это вообще отдельный тип записи (record), это не данные и не хэндшейк.

В rfc6520 ещё Hello Extenstion описан, мне сейчас интересно, как он обрабатывается.


Но память то уже прочитают. А соединение можно оборвать до завершения handshake.

RFC прямо говорит НЕ ДОЛЖЕН посылать, но отвечать же не запрещает?

Тогда это получается ошибка даже не в реализации, а в протоколе. Хэндшейки ещё не подтверждены, на их подлинность нельзя полагаться.

— Гость (12/04/2014 14:18)   <#>

Троянский конь. Там ещё ведь и рандомные байты в нагрузку к ответу добавляют, стойкий PRNG этим не удивишь, но всё ж не спроста это.
— Гость (12/04/2014 15:07)   <#>

В коде OpenSSL, умеющем heartbeat, нет проверки возможностей пира и содержимого расширения к hello сообщению, если будет запрос то будет и ответ, даже если пир использовал SSL3 протокол. Все проверки и учёт содержимого расширений находятся только в коде для запросов heartbeat, а не ответов. Всё строго по rfc6520, ага.
— sentaus (12/04/2014 15:25, исправлен 12/04/2014 15:26)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Это проверено на практике, опубликованные эксплоиты так и поступают, посылают heartbeat запрос сразу после получения server hello и до окончания согласования шифров.

RFC прямо говорит НЕ ДОЛЖЕН посылать, но отвечать же не запрещает? В общем чудесная ошибка получилась.

Таки нет, rfc говорит, что во время хэндшейка отвечать на heartbeet запросы не следует, этот случай явно оговорен:


However, a HeartbeatRequest message SHOULD NOT be sent during
handshakes. If a handshake is initiated while a HeartbeatRequest is
still in flight, the sending peer MUST stop the DTLS retransmission
timer for it. The receiving peer SHOULD discard the message
silently, if it arrives during the handshake.

Я так понимаю, в OpenSSL исправили только утечку данных из памяти, а на запросы во время хэндшейка она всё ещё
отвечает?


— Гость (12/04/2014 15:33)   <#>
В конечной редакции:
The receiving peer SHOULD discard the message silently, if it arrives during the handshake.
На страницу: 1, ... , 4, 5, 6, 7, 8, ... , 15 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3