id: Гость   вход   регистрация
текущее время 10:25 24/02/2024
Владелец: unknown (создано 08/04/2014 11:32), редакция от 12/04/2014 17:52 (автор: unknown) Печать
Категории: софт, анонимность, криптоанализ, инфобезопасность, tor, ошибки и баги, уязвимости, стандарты, атаки, ssl, разное, события
http://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/06/2014 23:21)   <#>
По ссылкам написано, что бага существует с первых версий, но эксплуатация возможна только если уязвимы обе стороны обмена. Сервер уязвим начиная с 1.0.1 версии.
With any OpenSSL client talking to an OpenSSL 1.0.1 server, an attacker can inject CCS messages to fixate the bad keys at both ends but the Finished hashes will still line up. So it's possible for the attacker to decrypt and/or hijack the connection completely.
— Гость (09/06/2014 08:33)   <#>

Т.е. начиная с 19 Apr 2012 где-то.


Типа бага настолько некритичная, что они вообще не торопятся? Что такое «верхний слой защиты»? Эксит может узнать, какому guard'у предназначен трафик, а guard — какому экситу?
— Гость (09/06/2014 10:19)   <#>

SSL шифрование Tor трафика, которое служит для защиты от внешнего локального наблюдателя. Если нет шифрования, то можно посмотреть какие ячейки посылает клиент, как много цепочек строит и т.д. В некоторых случаях (использование CREATE_FAST cell) позволит определить используемый в цепочке миддл. То есть всё то, что знает гвард. Эксита они не знают, эксит не знает гварда.

При уязвимости сеанса связи между узлами, атакующий видит часть того, что видят релеи. Тип ячеек, номер цепочки у ячейки. Это серьезно, но проследить соответствие ячейки на входе и на выходе это не поможет (логическая связь между входящими и исходяшими номерами для цепочки хранится в памяти узла). Ключи для Tor протокола независят от SSL обёртки.
— Гость (09/06/2014 11:45)   <#>
Гость (09/06/2014 10:19), спасибо за объяснение. Примерно так и думал.
— Гость (09/06/2014 13:35)   <#>
TBB 3.6.2 is ready for testing. Вероятней всего именно эти пакеты и будут релизом. Подписей пока нет, а просто файл с хэшами. Тестируем или ждём.
— Гость (16/06/2014 21:05)   <#>
Ааронсон про heartbleed:

Oh, and anyone who thinks the main reason to care about quantum computing is that, if our civilization ever manages to surmount the profound scientific and technological obstacles to building a scalable quantum computer, then that little padlock icon on your web browser would no longer represent ironclad security? Ha ha. Yeah, it turns out that, besides factoring integers, you can also break OpenSSL by (for example) exploiting a memory bug in C. The main reason to care about quantum computing is, and has always been, science.
— SATtva (22/06/2014 11:40)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Теперь уже не только OpenBSD, но и Гугл задолбало бодаться с бесконечными багами в OpenSSL:

Гугль форкнул OpenSSL
Вслед за OpenBSD, анонсировавшей свой форк OpenSSL под именем LibReSSL, об аналогичных планах отписался Адам Лэнгли (Adam Langley) – человек, отвечающий за сетевой стек в Google Chrome, да и вообще за всю гуглевскую https-инфраструктуру. Результат, который должен скоро появиться в репозитории Chromium, получил предварительное имя BoringSSL.

Основная идея этого форка – перестать страдать многочислеными патчами OpenSSL, которыми приходилось раньше заниматься разработчикам Chrome и Android (которые потом иногда входили, а иногда не входили в состав основного пакета), а держать свою отлаженную версию и подтягивать в нее при необходимости функциональность, появляющуюся в OpenSSL.

Похоже, теперь получим обратную ситуацию: вместо единого пакета, который, по идее, должен быть лучше отлажен и привлекать больше внимания сообщества, получим over9000 SSL-библиотек от каждого более-менее крупного вендора.
— Гость (22/06/2014 12:34)   <#>

+1. Если не смогут договориться о том, что брать за основу (стандартный софт), каждый будет клепать своё. Ресурсы на аудит со стороны сообщества будут делиться на число новых проектов, поэтому если фатальный баг где появится, шансы быть обнаруженным у него будут значительно меньше.
— unknown (22/06/2014 22:04)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Потому что нужно идти от стандарта к реализациям, со всей неизбежной бюрократией, а не из наборов патчей от базарного кодинга создавать стандарт.

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

Проблема в том, что такое нужно на практике «ненужно», потому что слишком трудоёмко, неконкурентоспособно и вообще так никто не делает.
— SATtva (25/09/2014 09:25)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Немного оффтопика на ту же тему:

...the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents.

Уязвимости 20 лет. Всё это время имели в баше, серверах, веб-приложениях, встроенных системах и прочем, и прочем исполнение произвольного кода. Кто ещё будет говорить, что АНБ в наш век зачем-то надо тратить деньги на криптоанализ?
— unknown (25/09/2014 14:21)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

В обработке PGP-запросов к обёртке вокруг GnuPG на pgpru.com?
— SATtva (25/09/2014 14:43)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Первым делом проверил. Как ни странно, нет.
— Гость (25/09/2014 22:24)   <#>
Local root обычный. Не пойму, чего столько шума. Сетевые сервисы? Дык поделом им.
— Гость (26/09/2014 01:05)   <#>
Не в тему, но и темы такой под руку не попало.
Что делать с этим ?
Набрал у себя:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

и вылезло это:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

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