id: Гость   вход   регистрация
текущее время 16:32 26/04/2024
Владелец: unknown (создано 28/10/2011 10:43), редакция от 28/10/2011 12:02 (автор: unknown) Печать
Категории: софт, анонимность, tor, ошибки и баги, уязвимости, атаки, свободный софт
https://www.pgpru.com/Новости/2011/СрочнойИсправлениеКритическойУязвимостиВTorПозволявшейДеанонимизироватьПользователей
создать
просмотр
редакции
ссылки

28.10 // Срочное исправление критической уязвимости в Tor, позволявшей деанонимизировать пользователей


В Tor 0.2.2.34 исправлены критические уязвимости, касающиеся анонимности, позволяющие атакующему деанонимизировать пользователя. Каждому необходимо обновиться.


Данная атака основана на четырёх составляющих:


  1. Клиенты повторно используют свои TLS-сертификаты при обращении к различным переотправляющим узлам, так что переотправляющие узлы могли идентифицировать ключ в сертификатах.
  2. Атакующий, которому известен ключ, идентифицирующий клиента, мог протестировать каждый сторожевой узел для того, чтобы видеть, что данный идентифицирующий ключ связан с данным сторожевым узлом непосредственно в данный момент времени.
  3. Множество активных атак, описанных в литературе (начиная с "Low-Cost Traffic Analysis of Tor" Мёрдока и Денейзиса, 2005), дают возможность злонамеренному вебсайту определять сторожевые узлы, которые выбирает Tor-пользователь для их посещения.
  4. Клиенты обычно выбирают три сторожевых узла случайным образом, так что набор сторожевых узлов для конкретного пользователя явлется достаточного хорошим уникальным отпечатком его профиля.

В данной реализации исправлены 1-ый и 2-ой пункты, достаточные для блокирования атаки, два других остаются предметом открытых исследований в поиске решения проблемы.


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


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


Этот релиз также исправляет множество уязвимостей, которые позволяют атакующему выявлять бридж-узлы. Некоторые атаки вычисления бридж-узлов всё ещё остаются незакрытыми (см. напр. proposal 188).


Скачать обновления

Фрагмент изменений в версии 0.2.2.34 – 2011-10-26

Исправления в области приватности/анонимности (клиенты):


  • Клиенты и бридж-узлы больше не смогут посылать цепочку TLS-сертификатов через исходящие OR-соединения. До этого, каждый клиент или бридж должен был использовать ту же самую цепочку сертификатов для всех исходящих OR-соединений, по крайней мере пока у него не поменяется IP-адрес, что позволяло любому переотправляющему узлу, с которым соединялся клиент или бридж определять, какой входящий узел он использует. Исправлена уязвимость CVE-2011-2768. Bugfix on 0.0.9pre5; найдено "frosty_un".

  • Если релей получает ячейку CREATE_FAST через TLS соединение, то он больше не рассматривает такое соединение как подходящее для запроса EXTEND. Теперь переотправляющие узлы могут защищать клиентов от CVE-2011-2768, даже если они не успели проагрейдиться.

  • Корневые директории больше не назначают флаг сторожевых узлов для переотправляющих узлов, которые не проапгрейдились до фикса вышеупомянутой опции "отклонять EXTEND запросы для соединений клиентов". Теперь корневые директории могут защищать клиентов от проблемы CVE-2011-2768, даже если ни клиенты, ни узлы сети не проапгрейдились. Предусмотрен новый флаг "GiveGuardFlagTo_CVE_2011_2768_VulnerableRelays" в опции конфигурирования для плавного перехода, так чтобы в один день в сети Tor не возникло ситуации полного отсутствия сторожевых узлов.

Исправления приватности/анонимности (вычисление бридж-узлов)


  • Теперь бридж-узлы получают свои запросы от корневых директорий через TLS-соединение, также как и остальные клиенты, вместо того чтобы осуществлять соединение через DirPort, как это делают общедоступные переотправляющие узлы. Удалены другие направления вычисления бриджей (Fixes bug 4115; bugfix on 0.2.0.35).

  • Бридж-узлы теперь строят собственные цепочки более сходным образом по отношению к тому, как это делают обычные клиенты. Удалены другие направления вычисления бриджей: Fixes bug 4124; bugfix on 0.2.0.3-alpha, где впервые были введены бриджи.

  • Бриджи теперь отклоняют ячейки CREATE и CREATE_FAST в OR-соединениях, которые инициированы ими. Переотправляющие узлы могли различать входящие клиентские соединения от соединений бриджей, открывая ещё один способ их вычисления. Fixes CVE-2011-2769. Bugfix on 0.2.0.3-alpha. Найдено "frosty_un".

Источник: The Torproject Blog, Обсуждение в рассылке


 
На страницу: 1, 2 След.
Комментарии [скрыть комментарии/форму]
— unknown (28/10/2011 23:18, исправлен 28/10/2011 23:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Да, погорячился. Действительно у всех длинных имён отображается только номерной UID. Проверил на другой машине и там этот глюк после апдейта не работает. Но всё равно с прозрачной торификацией периодически творится что-то неладное — то работает, то не работает. Хотя ничего не менял (кроме имени на UID) и раньше всё работало как часы.

— unknown (29/10/2011 00:02, исправлен 29/10/2011 00:04)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Разобрался с раздражающей проблемой, надеюсь окончательно. Права на /etc/tor/torrc почему-то поменялись на 640 root:root, а были и должны быть 644 root:root.


На старте Tor читает конфиг из под рута и уже после этого меняет UID на debian-tor. Если же в процессе работы сделать killall -SIGHUP tor, то он уже пытался перечитать конфиг из под юзера debian-tor, чего и не мог сделать. В логах он об этом пишет и предупреждает, что загружает установки по умолчанию. А там, ясное дело, никакой прозрачной торификации нет. Вот она и отказывалась работать до перезапуска демона из-под рута со сбросом прав обратно после чтения конфига.


После того, как поменял права, всё заработало.


Странно только то, что на другой машине после обновления права на конфиг не менялись.

— Гость (29/10/2011 01:44)   <#>
у всех длинных имён отображается только номерной UID
Я не знаю, как в iptables-save, но в pfctl -sr правила всегда выводятся с UID'ом, а не с username'ом. Если какой-то username pfctl не может превратить в UID, он поругается и не даст даже загрузить правила. С точки зрения UNIX, существуют только UID'ы, всё остальное — чисто для удобства пользователя.
— Гость (29/10/2011 06:29)   <#>
Да ну? У всех бриджей максимально возможная "непубличность" по определению. Я что-то пропустил? Любой бридж стараются держать непубличным, раздавая его в зависимости от IP (если смотреть с сайта) или ящика (если запрашивать на гмыло). Или вы хотели сказать "бриджи — такие же узлы, только с другой степенью непубличности"?
Бридж может опубликовать свой дескриптор (в непубличное хранилище), данные из которого будут розданы не всем и не всегда, т.е. к примеру "в зависимости от IP". Или может вообще его (дескриптор) не публиковать, тогда это будет приватный бридж о котором (в теории) знать будут только владелец и его пользователи, без каких либо посредников.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3