Регистрация29.10 // Уязвимость в opera: элементарная деанонимизация при работе в Tor
Уязвимость, присутствующая в браузере opera, позволяет деанонимизировать любого пользователя, работающего по http/https, посредством специально сформированной web-страницы, если в настройках не включена опция "использовать прокси для локальных серверов". В opera 9.61 (под Windows) Функция, проверяющая адрес на предмет локальности/удалённости, считает все адреса удалёнными, кроме следующих:
- 10.x.x.x
- 127.x.x.x
- 172.{1,2,3}.x.x
- 192.168.x.x
- произвольная строка, не содержащая точек, например http://qwerty, http://1 или http://1123637608.
Однако, согласно распространённой практике, не являющейся стандартом, адреса вида http://число также могут быть истолкованы как десятичное представление IP-адреса, например: 66.249.89.104 (IP гугла) --> 1123637608 = 66*256^3+249*256^2+89*256+104. Opera, соответственно, расценивает такой адрес как локальный. Итак, если ссылка имеет вид http://1123637608, а опция "использовать прокси для локальных серверов" не включена, то соединение с гуглом произойдёт минуя настройки прокси. Для эксплуатации уязвимости достаточно вставить в HTML-страницу (например, CSS) следующий код:
В этом случае соединение с самим сайтом произойдёт через прокси, а картинка pic.jpg и стилевой файл будет запрошена с гугла напрямую, минуя настройки прокси.
Предположительно, уязвимости подвержены все версии opera. Для нивелирования ошибки в старых версиях opera'ы (информация не проверена!), следует, предварительно выйдя из программы, прописать в файле конфигурации (Opera6.ini или OperaDef6.ini):
Стоит отметить, что включение опции "использовать прокси для локальных адресов" было бы необходимо вне зависимости от наличия указанной выше уязвимости, ибо отсутствие опции открывает путь для атак со стороны злонамеренных серверов локальной сети, среди которых вполне может оказаться и сам узел ISP. Поскольку, как ожидается, у многих эта опция уже была включена из вышеназванных соображений, массовой деанонимизации из-за уязвимости не ожидается.
В качестве противодействия подобному виду угроз, рекомендуется настроить файерволл таким образом, чтобы принудительно отправлять весь трафик с браузера, а также opera mail, только на IP:порт прокси. Естественно, что вышесказанное верно для настроек любой прокси, в том числе и privoxy. Firefox, как утверждается, не подвержен этим уязвимостям, однако аналогичные превентивные меры в отношении как него, так и других программ, работающих с сетью через прокси/Tor, нивелируют последствия от подобных ошибок в будущем. Настройка файерволла для фильтрации по приложениям (например, xauth+authpf+PF+tor в BSD), уже обсудавшаяся на pgpru.com, оказалась как никогда кстати.
Предоставленный материал частично основан на источнике http://eqt5g4fuenphqinx.onion/talk/1783, однако, не подтверждает всех предоставленных им фактов.
Доступ к источнику через гейт с обычного интернета: https://www.awxcnx.de/cgi-bin/proxy1/nph-proxy.cgi/000000A/http/eqt5g4fuenphqinx.onion/talk/1783
комментариев: 155 документов: 20 редакций: 5
Файрфокс тоже не блещет. По крайней мере, в Опере работают задокументированные функции, например не принимать куки не с основного домена, и другие.
И зачем Норвежской Опере устанавливать бэкдур. Также как и зачем гуглу вся эта шумиха вокруг него. Это просто смешно.
В некоторых странах его доля порядка 40%, в то время как доля опера повсюду не больше 5%, емнип.
Могут "попросить" так, что нельзя будет отказаться. Бэкдор в браузере – самый прямой доступ к частной информации. А зачем вводить тотальную прослушку? Зачем в соседней Швеции принимать закон Оруелла? Зачем принуждать к раскрытию шифровальных ключей в Великобритании? Зачем требовать установку оборудования СОРМ для всех телематических служб в РФ?
комментариев: 155 документов: 20 редакций: 5
Не, то что "контора пишет" – это всем известно. Но бэкдур то зачем? В таком случае нужно на сайтах делать ПО, вмешивающееся в работу браузера.
Мне просто легче понять, что какой-то заработавшийся программист забыл скопи-пейстить, а тестер поленился тщательно проверить на регрессионные баги. Чем в то, что в каждой нормальной конторе злобный тим-лид по совместительству является сексотом.
Могу конечно и ошибаться.
Опцию "использовать прокси для локальных серверов" выключите, если тестируете. Это опция по умолчанию отключена так-то, что и приводит к игнорированию прокси.
Лично у меня 9.61 не отличается по поведению от 9.60, и обе игнорируют прокси по умолчанию для этих как-бы "локальных" адресов. Осталось 9.62 проверить, или лучше подождать сразу 9.63 :)
Конечно в данной ситуации уместно было бы вспомнить что и для лисы к примеру советуют включать все доступные и понимаемые опции в настройках под прокси, например протоколы.
Интересно как с этой опцией обстоят дела у неофициальной сборки Opera+Tor?
Скорей всего так же. Как мне показалось, это всего лишь "пакет для ленивых" собравший tor, privoxy и opera в один install.
Для параноиков необходимо, но не достаточно, в любом случае. В общем как и вещают нам цитаты, новость, и здравый смысл.
Но от этого баг не перестает быть ошибкой, хотя возможно это уже за пределами последствий описанных в новости. К примеру сценарий как из рассылки 2001 года: есть доверенная локалка с серверами и фильтрующий антивирусный прокси, и пользователь который совмещает все это в одном профиле уязвимой оперы.
В 9.52 (Linux) при включении той галки соединение идёт через прокси, даже если указано http://1123637608 – что это значит? Что существует только 2ая уязвимость, оговоренная в новости, но не существует первой?
Если так, то почти alarma false, и новость надо исправлять. Подтвердите хоть кто-нибудь, о современных версиях оперы, которые игнорируют настройки прокси при коннекте к http://1123637608, даже если указана галочка "использовать прокси для локальных серверов".
Кажется, я понял. Баг один единственный: опера рассматривает http://число как локальные адреса, хотя они могут быть и удалёнными. В связи с этим, все уязвимости, оговоренные в новости, полностью закрываются установкой той самой галочки (и у многих она итак по умолчанию установлена, кстати. Т.о., массовой деанонимизации нет). Если бы этого бага не было, то анонимность не должна была бы разрушаться даже при выключенной опции, в предположении что в локальной сети нет злонамеренных узлов (сильное предположение, ибо часто ISP является частью локальной сети и имеет внутренний адрес).
Что же касается настройки fw, то это превентивные меры направленные на защиту от подобных атак. При должной настройке fw анонимность не будет нарушаться вне зависимости от того, есть ли уязвимости вышеперечисленного типа в браузере или нет.
зы: если возражений нет, то новость я исправлю.
комментариев: 9796 документов: 488 редакций: 5664
Предлагаю обсудить не просто принудительное блокирование DNS-запросов (уходящих мимо Tor'a), а прозрачную анонимизацию – принудительное их заворачивание в Tor вместе со всем трафиком. Хотя это не панацея от уязвимостей в браузере, дающей доступ к соседним запущенным в иксах программах или выполнению произвольного кода с повышением привилегий.
Можете дополнить FAQ правилами для BSD и настройками ipfw.
Completely fixed.
Программы можно запускать от разных пользователей. Сажать пользователей в чрут. А один юзер под иксами может работать с информацией, даваемой программами. работающими под другими юзерами, под одними и теми же иксами. Народ говорил что это делается срадствами xauth. Чтобы настройки доступа в инет были per user, можно заюзать authpf. Самое сложное – это запретить смотреть локальные настройки типа ipconfig – оно решается либо посредством виртуализации, либо с помощью навороченных механизмов, присутствующих только в Linux (типа мандатных политик), а вот простого решения не вижу, ну кроме как если поставить два компьютера физически, где один даёт доступ другому.
У меня пока кроме голых идей нет опыта настройки/работающей_конкретной_схемы/времени_разобраться. Если у кого есть, то prego.
комментариев: 11558 документов: 1036 редакций: 4118
Только без иксов.
У меня браузер, мэйл-клиент и разное другое по мелочи так работает.
Почему?