09.11 // Клиент службы Tor может раскрыть конфиденциальные данные пользователя
В анонимизационной службе Tor обнаружена уязвимость, которая при определенных условиях, может позволить злоумышленнику получить доступ к конфиденциальным данным приложения.
Проблема заключается в том, что некоторые компиляторы во время оптимизации кода опускают функцию memset(), если заполняемый ею буфер больше нигде не используется. Таким образом, находящиеся в памяти данные не обнуляются, что позволяет считать их другим процессом.
Учитывая, что служба Tor предназначена для предоставления пользователям анонимного доступа к сети Интернет и обеспечения защиты сохранности конфиденциальной информации, наличие подобной бреши может быть использовано для восстановления списка ресурсов, посещаемых пользователем, а также извлечения учетных данных, которые используются для авторизации на этих ресурсах.
Описание уязвимости
Дата публикации: | 09.11.2012 |
Дата изменения: | 09.11.2012 |
Всего просмотров: | 0 |
Опасность: | Низкая |
Наличие исправления: | Нет |
Количество уязвимостей: | 1 |
CVSSv2 рейтинг: | (AV:N/AC:H/Au:N/C:P/I:N/A:N/E:P/RL:U/RC:C) = Base:2.6/Temporal:2.3 |
CVE ID: | Нет данных |
Вектор эксплуатации: | Удаленная |
Воздействие: | Обход ограничений безопасности |
CWE ID: | Нет данных |
Наличие эксплоита: | PoC код |
Уязвимые продукты: | Tor Browser Bundle for Windows 2.x |
Уязвимые версии: | Tor 2.2.39-5, возможно другие версии |
Описание: | Уязвимость позволяет удаленному пользователю раскрыть важные данные на целевой системе. Уязвимость существует из-за ошибки состояния операции при вызове функции memset(), которая может быть удалена компилятором. Удаленный пользователь может раскрыть содержимое буферов клиента Tor |
URL производителя: | https://www.torproject.org/ |
Решение: | Способов устранения уязвимости не существует в настоящее время. |
Добавлено 14.11.12: Проблема устранена в Tor 0.2.4 и выше.
Источник: http://www.securitylab.ru/news/432245.php, http://www.securitylab.ru/vulnerability/432243.php, http://www.viva64.com/ru/b/0178/
В самой новости ничего особо страшного, конечно, нет — это большей частью надуманная «уязвимость» хотя бы потому, что если какой-то другой процесс имеет доступ, чтобы читать память Tor, он и так всё прочитает. Смысл же в том, что в криптолибах принято затирать область памяти, где хранились ключи, после того, как они больше не нужны. Делается это для устранения неочевидных утечек. К тому же, многозадачные ОС могут сбрасывать стек в пейджфайл, и тогда необходимо, чтобы снизить вероятность этого.
Во многих либах ставят memset, который выбрасывается, как незначимый код, т.е. оптимизатор видит, что этот код не влияет на логику работы приложения, и выбрасывает его. Частичным решением могла бы быть своя функция, использующая volatile, но модификатор volatile некоторые компиляторы могут и игнорировать. Бывают решения и с inline asm (это работает, но некрасиво). Есть еще ОС-зависимые решения, типа функции SecureZeroMemory в винде. «Самые умные» же пишут свою функцию, зануляющую байтики в цикле.
В общем, авторы просто не смотрят в дизасм. Вот пример функции:
Здесь memset распознается оптимизатором, как незначимый код, потому что массив key ей изменяется, но дальше нигде не используется. А можно было бы написать __stosb(key, 0, sizeof(key)); — это intrinsic, компилирующийся непосредственно в ассемблерную инструкцию rep stosb, причём он поддерживается компиляторами MSVC, ICC и GCC на архитектурах x86 и amd64. Вообще, привычка смотреть в дизасм на то, что сгенерировал компилятор, очень полезная, т.к. позволяет выудить косяки, невидимые в исходнике.
Буфера можно затирать через интринсик __movsb, что некроссплатформенно, но точно транслируется в соответствующую ассемблерную инструкцию.
Кроссплатформенное приложение это как семьдесят детей у одной няньки. Все кругом кричат "нам надо", а реализовать некому.
Я уже давно наблюдаю за TorBrowserBundle (TBB), практически с момента его введения в использование проектом Tor.
Теперь, что касается падения TBB. Кто-то из параноиков мог замечать интересную его особенность: при скачивании файла в /tmp создаётся временный нулевой файл. Мне это показалось странным, но, поскольку файл был со случайным именем и нулевым размером, я подумал, что ничего страшного в этом нет. Действительно, если вы скачваете файл через TBB, он всегда спрашивает, куда его сохранять. В некоторых версиях при распаковке архива TBB возникала директория для скачки, с именем типа Desktop, но потом она перестала появляться. Из интерфейса TBB, кстати, создать нужную директорию на лету в его [папке] tor-browser_ЯЗЫК нельзя — надо её там создать предварительно вручную, сторонними средствами, и тогда TBB сможет в неё писать (и, кажется, даже на лету в ней создавать поддиректории). Это я к тому, что, если вы скачиваете файл, он вроде как скачивается в место, указанное при скачке. Во всяком случае, вы так об этом думаете и это похоже на правду. Ведь даже сама идеология TBB — портабл-бандл. Его можно запускать с флешки или откуда-то ещё и при этом знать, что он ничего не запишет на основной диск, который, кстати, может вообще быть нешифрованным.
Однако, не всё так просто. Последний раз, когда упал TBB, я обнаружил в /tmp осколок файла со случайным именем — что-то типа СлучайныеСимволы.part.bin или СлучайныеСимволы.bin, точнее уже не помню. Файл был ненулевого размера. Файл... содержал первую часть как раз того файла, который я скачивал до падения firefox. Почему при падении TBB возможен такой эпический казус? Если у firefox есть собственная директория tor-browser_ЯЗЫК/tmp, зачем он лезет в системный /tmp?! Если такая дичь творится даже на линуксах, что остаётся сказать про временные директории в виндах? При погоне за "фичами, флешами и скриптами для среднего юзера" в Tor Project они упоролись там все что ли?
Вывод: в текущих версиях нешифрованный (или не находящийся целиком в памяти при отключенном свопе) /tmp — катастрофа для анонимности. Кто-нибудь может независимо подтвердить, или я не первый, кто это заметил? Есть ли баг-тикет на сайте Tor?
головедереву/tmp надо хранить в tmpfs
Но вопрос очень важный, если не сказать больше. Если это происходит, то только потому, что так делает firefox, и никто не заметил этого. Нужно искать причины, сообщать разработчикам. И не перекладывать это на других, если есть возможность.
Как-то так.
Firefox может создать файл и тут же его удалить, но продолжить в него писать. В Linux есть способы посмотреть дескрипторы всех открытых файлов (lsof), что будет работать, даже если файл удалён. Можно ещё этим методом глянуть.
Первая — core dump. Кто регулирует их создание? ОС, само приложение? Если они в системе не отключены, не будет ли сама ОС создавать их при падении TBB?
Вторая — эксплуатация уязвимости вида "переполнение буфера". Про боевые сайты мне ещё много лет назад говорили следующее: если сайт эксплуатирует переполнение буфера в браузере, то на уязвимых его версиях под ОС, для которой написан эксплоит, это сработает, но эта же уязвимая версия браузера под другой ОС при этом просто упадёт. Короче говоря, эксплоиты под браузеры в винде при попытке открыть их уязвимыми версиями браузеров под линукс будут банально падать. Обсуждалось давно, деталей не помню, но что-то такое осело в памяти.
Это уже какая-то магия. Зачем это браузеру?
1. какая система установлена.
2. немного о железе (память, процессор, носители)
у меня лично TBB не падал ни при полнолунии, ни при солнечном затмении. стабильность работы пакета даже от времени суток не зависит.
Убунта, 32 bit. Какое отношение к делу имеет железо? Вот реально, какое отношение к софтварным багам на прикладном уровне имеет железо?! Обычный ПК, двухядерный проц, несколько гигабайт оперативной памяти, места на диске достаточно.
Не поверите, но если ходить только по мирным сайтам, и у меня почти так же.
Комментарии:
Проверяйте.
комментариев: 9796 документов: 488 редакций: 5664