id: Гость   вход   регистрация
текущее время 17:43 29/03/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 След.
Комментарии [скрыть комментарии/форму]
— Гость (28/10/2011 14:56)   <#>
Исправления в области приватности/анонимности
В течение какого времени эти уязвимости существовали? Касается ли это только (относительно новой) ветки 0.2.2.x?
— Гость (28/10/2011 15:46)   <#>
В теории с момента появления сертификатов у пиров и использования гвардов (0.0.9pre5 ?! гварды позже, однако). На практике (когда ваши сертификаты могли обозревать 'зеркала'), с момента массового использования туннелирования скачиваемой статистики через одно-хоповые цепочки (0.1.2.x, 0.2.0.x).

Позволять деанонимизировать и устроить деанон здесь и сейчас — не одно и тоже. Читайте новости внимательней и не паникуйте (но обновляйтесь). От того что злоумышленник (владеющий, обязательно, узлом) вычислил ваши гварды — ваша анонимость не испарится. Но используя пункты 3 и 4, со временем и контролируя посещаемый вами ресурс, сможет устроить более гарантированный деанон (чем без этой уязвимости).
— Гость (28/10/2011 17:30)   <#>
с момента массового использования туннелирования скачиваемой статистики через одно-хоповые цепочки
Разве номинально Tor-клиент обновляет статистику через однохоповые цепочки?! Не знал, не знал...

не паникуйте
Это стандартный дежурный вопрос. Когда находят уязвимость, всегда спрашивается: допустим, есть некто, кто знал о ней всегда, тогда как много дел зла он мог совершить?
— Гость (28/10/2011 17:52)   <#>
Вообще, хорошо, что Tor начали ломать — этому можно только порадоваться. Значит, он действительно становится более анонимным. Больше внимания прессы и злоумышленников => больше внимания исследователей, причём прекрасны работы как по взлому, так и по методам превентивной защиты. Только тот протокол, который остаётся (приемлемо) анонимным несмотря на то, что его все ломают/исследуют, дейтствительно анонимен. Надеюсь, эта мысль достаточно ясна читателям этого форума, а то есть тенденция всё воспринимать на кульхацкерском уровне — "Tor взломан, надо пользоваться чем-то другим — оно безопасней".
— Гость (28/10/2011 18:01)   <#>
Разве номинально Tor-клиент обновляет статистику через однохоповые цепочки?! Не знал, не знал...
Как иначе? Раньше все документы выкачивалиь в плайн-тексте стандартным http. Теперь (года 2) качает через цепочку. Что удивляет, однохоповость или ...?
Это стандартный дежурный вопрос.
Ну также дежурно пишут в чэнджлогах:
Bugfix on 0.0.9pre5

Когда находят уязвимость, всегда спрашивается: допустим, есть некто, кто знал о ней всегда, тогда как много дел зла он мог совершить?
Ошибки в коде они такие ошибки.
— Гость (28/10/2011 18:54)   <#>
Что удивляет, однохоповость или ...?
Мне казалось, что если статистики нет, то качается напрямую с корневых директорий. Если есть относительно свежая — строятся цепочки сразу и статистика обновляется с Tor. Если номинально клиент всегда запущен — тоже. Обновляется с Tor — значит качает с тех нод, которые зеркалируют статистику, через Tor. Т.е., как я понимал, через стандартную торовскую цепочку статистика и качалась.
— Гость (28/10/2011 19:22)   <#>
Скачивание статистики не требует анонимности, нет необходимости скрываться от зеркал (в теории, практика несколько сложней как показывает новость). Значит нет необходимости загружать стандартную анонимизирующую цепочку. Один хоп это использование имеющегося механизма цепочек при нулевой анонимности но защита от локального обозревателя (провайдер и т.д) на предмет тривиального определения использования тора.
— Гость (28/10/2011 20:29)   <#>
защита от локального обозревателя (провайдер и т.д) на предмет тривиального определения использования тора.
Ну, это важно только для тех, кто использует бриджи. А остальные от ISP не скрывают факт пользования Tor'ом.
— unknown (28/10/2011 21:18, исправлен 28/10/2011 22:00)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

ВНЕЗАПНО: после обновления пакета под Debian, tor пытается запуститься под юзером "debian-tor". И даже запускается, почти как и обычно. Только раньше он это делал правильно, а теперь как-то странно. ps aux | grep tor должно было выводить в первом поле принадлежность процесса debian-tor, а теперь выводит только номерной uid 106, хотя в /etc/passwd всё вроде как правильно.


Пока не поменял в файрволе с прозрачной торификацией переменную с имени на явно заданный по номеру uid, получал массу неработающих программ. Зато Tor из TBB бодро отработал с Видалией без двойного заворачивания (вот наглядный пример почему прозрачная торификация плохо вместо жёсткого блокирования всего неторовского трафика — а могла бы быть утечка деанонимизирующих данных).


У кого ещё так?

— sentaus (28/10/2011 21:25)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
ВНЕЗАПНО: после обновления пакета под Debian, tor пытается запуститься под юзером "debian-tor". ... У кого ещё так?


Подтверждаю. Наблюдаю это же на дебиане и на убунте.
— unknown (28/10/2011 21:57, исправлен 28/10/2011 21:58)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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

— sentaus (28/10/2011 22:10)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
А оно точно так и раньше было в ps aux? Гугль говорит, что если длина имени пользователя >8 символов, то будет uid использоваться. Я вот не помню точно, с длинными именами пользователей не так уж часто сталкиваешься.
— Гость (28/10/2011 22:21)   <#>
Ну, это важно только для тех, кто использует бриджи. А остальные от ISP не скрывают факт пользования Tor'ом.
Ну так бриджи те же узлы только различной степени не публичности.
— Гость (28/10/2011 22:22)   <#>
наглядный пример почему прозрачная торификация плохо вместо жёсткого блокирования всего неторовского трафика
Вероятно, я что-то недопонимаю, но
  1. При правильно настроенной прозрачной торификации весь трафик от торифицируемых пользователей заворачивается на соответствующие порты Tor'а (для udp и tcp). Всё остальное от таких юзеров режется.
  2. Если пользователь пошёл в сеть, а Tor не запущен, соответствующие порты ни кем не заняты, потому трафик просто никуда не пойдёт, а у нужных юзеров попросту не будет сети.
В связи с этим не понимаю вашего беспокойства.

[толсто]
  • Если злонамеренное приложение от какого-то 3его пользователя запустило свою прокси на нужном порту (а Tor по какой-то причине оказался не запущен, и соответствующий ему порт — свободен), то траф в сеть в BSD не пойдёт, а в Linux'е пойдёт. Потому что в OpenBSD pf есть понятие owner для пакетов in (это владелец сервиса, запущенного на соответствующем порту — что-то типа pass in from $lh to $lh port 9050 user bsd-tor), а в Linux — нет (owner там только для out). Соответственно, последний плохо годится для рутеров. Вон, на них уже черви завелись.
Но всё равно неприятно.
Когда с BSD на Linux пересаживаешься, прям чувствуется как мало становится контроля над машиной — сидишь, как на пороховой бочке. Так бы и пользовался BSD, но, по независящим от меня причинам
я его убил
[/толсто]
— Гость (28/10/2011 22:30)   <#>
Ну так бриджи -- те же узлы, только различной степени непубличности.
Да ну? У всех бриджей максимально возможная "непубличность" по определению. Я что-то пропустил? Любой бридж стараются держать непубличным, раздавая его в зависимости от IP (если смотреть с сайта) или ящика (если запрашивать на гмыло). Или вы хотели сказать "бриджи — такие же узлы, только с другой степенью непубличности"?
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3