id: Гость   вход   регистрация
текущее время 15:24 29/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, ... , 7, 8, 9, 10, 11, ... , 15 След.
Комментарии [скрыть комментарии/форму]
— SATtva (14/04/2014 07:16)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Тем хуже для Вас.
— Гость (14/04/2014 09:06)   <#>

Что-то странное тут написано. В софте прописаны как раз отпечатки долговременных ключей DA, как я понимаю, а для кратковременных ключей лишь требуется, чтоб они были не более, чем недельной давности. Так? Ничто им не мешает в любой момент полностью сменить кратковременные (недельные) ключи подписи статистики. Tor-клиент, пока его не запустили, вообще не знает, какие там кратковременные ключи.
— Гость (14/04/2014 09:48)   <#>
Собрались однажды Ассандж, Сноуден и Мэннинг. Нет, не так. Собрались однажды Thomas Drake, William Binney и J. Kirk Wiebe. Надо по аналогии собрать в одном месте Robin Seggelmann'а, Kurt Roeckx'а и ещё каких-нибудь подобных ярких личностей. Озаглавить встречу можно как «Ведущие мудаки последнего десятилетия, которые обрушили безопасность всего Интернета», устроить интервью с ними, пресс-конференцию; послушать, что они говорят про безопасность...

Что характерно, ни один из этих людей не чувствует раскаяния и не хочет нести ответственность. Ну, ошибся и ошибся. Подумаешь там, миллиардные убытки в индустрии, инфраструктурный коллапс, нарушение работы миллионов серверов, кража колоссального числа данных — с кем не бывает?

Всегда можно говорить, что в менее распространённом софте дыр не меньше, просто их там не ищут, но если их там действительно меньше, то где грань? Сколько нужно спотыкаться об OpenSSL, прежде чем все признают, что он настолько дырявый не потому, что распространённый, а потому, что он просто дырявый? Мне эта история напоминает sendmail — безусловный лидер, мощный, исторически развитый, везде присутствующий, нечеловечески сложный мейлер. Сколько там было дыр, но мыши кололись и продолжали есть кактус. После сканада с очередной дырой народ в NetBSD-team сказал «с нас хватит» и вышвырнул его из базы нахрен несмотря на то, что он у них был там с самого начала, и они его тоже поддерживали, вкладывались в него, раз он в базе. С тех пор у них postfix. В OpenBSD же упёрлись рогами, типа «всё остальное ещё хуже», оставив всё, как есть.

Существует GnuTLS, есть PolarSSL, есть другие библиотеки. Почему весь мир держится за OpenSSL? Дело исключительно в распространённости, т.е. в исторически сложившихся обстоятельствах? Про перевод проектов на GnuTLS активно говорили ещё в 2008-ом, когда в Debian случилась лажа.


В них тоже бэкдоры?

Старый комментарий звучит неплохо и актуально:

А главный разработчик OpenSSL отвечает, что девелоперскую рассылку он не читает и вовсе она не девелоперская несмотря на название, а сидят в ней апстримеры, которые до конца во все тонкости не посвящены, даунстриму в код не фиг было лезть, и о такой хитрой фиче позволено знать только его высочеству, с которым надо связываться лично по мэйлу и если он соизволит, то даст ответ.
— Гость (14/04/2014 11:06)   <#>

Как интересно! И давно это поменяли? Раньше было вроде так: оффлайновыми ключами подписывались временные еженедельно. А как теперь?


Интересно, он не боится, что представители индустрии его могут попросту заказать?


Мнение Тео.


Да много, что можно сделать. Для начала — вытащить сеансовые ключи и расшифровать транзитный трафик. Если там нет DH, то вытаскиваем договременные симметричные ключи шифрования, что позволит расшифровывать трафик и в будущем.* Если DH есть, то имея приватный ключ, делаем MITM и расшифровываем трафик в будущем.


Fxd.

*Не знаю, как это работает; один клиент же не должен знать, какой симметричный ключ используется у другого, но как сделать симметричные ключи для всех разными, но не меняющимися со временем, если нет DH?
— sentaus (14/04/2014 11:08)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Интересно, он не боится, что представители индустрии его могут попросту заказать?

Поздно уже.
— Гость (14/04/2014 11:34)   <#>

В спецификации:
Every authority has a very-secret, long-term "Authority Identity Key". This is stored encrypted and/or offline, and is used to sign "key certificate" documents. Every key certificate contains a medium-term (3-12 months) "authority signing key", that is used by the authority to sign other directory information. (Note that the authority identity key is distinct from the router identity key that the authority uses in its role as an ordinary router.)

Но это не строгие границы. Вообще сначала все подписывали на год. Есть особые параноики, которые делали и чаще. Это же ручная работа, автоматизировать можно только напоминалку и запускалку, но пароль от ключа нужно вводить самому.
— unknown (14/04/2014 11:37)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Те, кто чего-то разрабатывал в security-индустрии, сами делали или видели от коллег до фига таких ошибок. В этом то и проблема, что ошибиться легче лёгкого, а выявить баг, связанный с секурностью, а не функциональностью — сложно.
— Гость (14/04/2014 11:53)   <#>

Такого клиента, который ничего не знает, можно отмитмить если скормить ему старые сертификаты и документы подписанные с использованием старых ключей. Сделать это, используя машинку unknown'а, ибо считается, что с помощью hertbleed из памяти процесса утекли все ключи. И всё будет в порядке и согласно протоколу. Потому как старые они только с точки зрения клиента который обновил их на новые.
— Гость (14/04/2014 12:46)   <#>

Статус проблемы не понятен. Всё ли успели исправить в OpenSSL? Есть ли ошибка/уязвимость в требованиях самого протокола/RFC? Или дело только в том, что OpenSSL из-за ошибки не удовлетворял требованию протокола?


Насколько я знаю, torbutton отдельно более не релизится, его надо выкорчёвывать из актуальных версий TBB самостоятельно, если он вдруг понадобится. Видалия более не входит в состав TBB, но её вроде можно установить отдельно и заставить работать с TBB [1], [2].


Доверия к любому браузеру нет, но TBB (текущая релизная версия, которую должны установить себе все) хотя бы не профилирует так сильно, как остальные.


А эту багу? Правили исходники firefox?


Наружу светят только параметры firefox. На них может влиять torbutton. Видалия тут вообще ни при чём, это вспомогательный софт.


Мстить никогда не поздно. :)


Понятно. Я думаю, это обходится. Надо выпустить новую версию Tor, в которой заблэклистить старые сертификаты (вроде на сайте Tor'а такой вариант тоже обсуждался). Все, кто обновятся, уже не будут подвержены машинке unknown'а.


Как где-то написали, «люди в салоне уверены в нечеловеческой серьёзности тех, кто сидит за штурвалом, а те, в свою очередь, вытворяют штуки вида "секс в кабине пилота" и вообще не напрягаются». С DA было так же: все думали, что там всё защищено, а потом оказалось, что скомпрометированные DA находятся на сервере, где ещё что-то запущено (версионник, какие-то сервисы), к серверу имеют доступ много людей и т.д. А теперь, оказывается, что и недельного срока нет, все ключи лежат на DA, и если его взломать, его можно год имперсонировать.

Держать запущенным свой DA — это катастрофическая ответственность, это требование личного знакомства с разработчиками Tor, это вопрос безупречной репутации, это работа под возможным давлением и атаками со стороны АНБ, и после всего сказанного этим людям лениво чаще, чем раз в несколько месяцев, парой команд свои ключи вручную обновлять? Я хренею с этого мира. Да у них при такой популярности уже давно должна быть круглосуточная служба безопасности, цель которой — вовремя реагировать на угрозы и мониторить состояние сети, а тут получается, что «чисто исследовательский проект», «всем пофигу», «лучшего всё равно не найдёте».
— Гость (14/04/2014 12:54)   <#>

Есть проект со сравнимой популярностью, сложностью и распространённостью — это OpenSSH. Я не спорю, в нём находят время от времени небольшие дыры, постоянно развивают (в отличие от OpenSSL, который почти не развивают), что-то фиксят. В нём хотя бы раз была дыра, которая позволяла полностью расшифровывать весь трафик или получить удалённый доступ в сколь-нибудь распространённой/дефолтной конфигурации? И если была, то когда последний раз? Больше 10 лет назад? Почему Тео умеет писать безопасный код, а остальные нет?
— unknown (14/04/2014 12:57, исправлен 14/04/2014 12:59)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


При массовой атаке манипуляции со статистикой будут замечены.


Меня больше интересует вопрос — закрытые gpg-ключи к подписям пакетов дистрибутивов операционных систем у кого хранятся, как защищаются? Можно ли вручить их владельцу требование выдачи под кляп-ордер? Они и долговременные, и используются регулярно, и нужны срочно в любое время (выпуск обновлений подписывать). Они часом не на серваках прямо лежат? Про нелегальные способы получения и так всё понятно.

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

В памяти всё равно какие-то ключи придётся держать. Если заставить их обновлять раз в неделю, то владельцы DA быстро устанут и сделают себе хаков в утилите по выпуску новых сертификатов. Автоматизируют настолько, что оставят всё без паролей, поближе к процессу или встроят сразу туда.
Уж лучше новую версию с блеклистом подождать, чем неделю вот такого ничего не защищающего сертификата.
— Гость (14/04/2014 13:09)   <#>
Есть способы написания кода таким образом, чтобы его могли проверить на предмет ошибок автоматические анализаторы. Ответственные программисты этим заморачиваются, а кодеры OpenSSL нет. Код последнего ругают за грязность, сложность и запутанность. Автоматическими тулзами его тоже не проверить, разработчикам пофиг на безопасность.


А как её сверить? Простых способов нет. Если будут делать MITM на стороне хостера DA, то единственный, кто сможет заметить неладное — сам владелец DA, да и то чисто теоретически, т.к. его самого могут отмитмить и функции сервера подменить. Нет ведь простого способа даже для владельца DA понять, какая статистика правильная. Если владелец DA заходит на взломанный DA-сервер по SSH, ему можно отдавать такую же левую статистику, как и всем остальным. Подмена может быть скрыта в недрах самого DA-сервера. Тут единственная надежда только на децентрализованность, но штатно клиенты Tor даже не пишут, совпали ли файлы статистики от разных DA или нет, сколько не совпало, есть ли какие-то подозрительные действия...
— SATtva (14/04/2014 13:13)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Ответственные программисты этим заморачиваются, а кодеры OpenSSL нет. Код последнего ругают за грязность, сложность и запутанность. Автоматическими тулзами его тоже не проверить, разработчикам пофиг на безопасность.

Проверили, вон, однажды...
— Гость (14/04/2014 13:14)   <#>

В том числе, ключ Erinn Clark, которым подписывают TBB. ☺ Где-нибудь в документах утверждается, что ключи для подписи Tor и TBB хранятся в оффлайне?
На страницу: 1, ... , 7, 8, 9, 10, 11, ... , 15 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3