id: Гость   вход   регистрация
текущее время 10:38 29/03/2024
Владелец: SATtva (создано 09/11/2012 15:04), редакция от 14/11/2012 12:42 (автор: SATtva) Печать
Категории: софт, анонимность, анализ трафика, tor, ошибки и баги, уязвимости, атаки
http://www.pgpru.com/Новости/2012/КлиентСлужбыTorМожетРаскрытьКонфиденциальныеДанныеПользователя
создать
просмотр
редакции
ссылки

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/


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 След.
Комментарии [скрыть комментарии/форму]
— Гость (11/11/2012 02:05)   <#>
memset — знакомая тема. В криптолибах затирать буфера при выходе из функции надо другим способом.

В самой новости ничего особо страшного, конечно, нет — это большей частью надуманная «уязвимость» хотя бы потому, что если какой-то другой процесс имеет доступ, чтобы читать память Tor, он и так всё прочитает. Смысл же в том, что в криптолибах принято затирать область памяти, где хранились ключи, после того, как они больше не нужны. Делается это для устранения неочевидных утечек. К тому же, многозадачные ОС могут сбрасывать стек в пейджфайл, и тогда необходимо, чтобы снизить вероятность этого.

Во многих либах ставят memset, который выбрасывается, как незначимый код, т.е. оптимизатор видит, что этот код не влияет на логику работы приложения, и выбрасывает его. Частичным решением могла бы быть своя функция, использующая volatile, но модификатор volatile некоторые компиляторы могут и игнорировать. Бывают решения и с inline asm (это работает, но некрасиво). Есть еще ОС-зависимые решения, типа функции SecureZeroMemory в винде. «Самые умные» же пишут свою функцию, зануляющую байтики в цикле.

В общем, авторы просто не смотрят в дизасм. Вот пример функции:
void function()
{
 
    unsigned char key[1234];
 
    // do something
 
    // prevent leaks
    memset(key, 0, sizeof(key));
}

Здесь memset распознается оптимизатором, как незначимый код, потому что массив key ей изменяется, но дальше нигде не используется. А можно было бы написать __stosb(key, 0, sizeof(key)); — это intrinsic, компилирующийся непосредственно в ассемблерную инструкцию rep stosb, причём он поддерживается компиляторами MSVC, ICC и GCC на архитектурах x86 и amd64. Вообще, привычка смотреть в дизасм на то, что сгенерировал компилятор, очень полезная, т.к. позволяет выудить косяки, невидимые в исходнике.

Буфера можно затирать через интринсик __movsb, что некроссплатформенно, но точно транслируется в соответствующую ассемблерную инструкцию.
— Гость (11/11/2012 03:16)   <#>
В общем, авторы просто не смотрят в дизасм.
У них есть план в отошении TorBrowser, а вот до просто дизасма Tor руки не дошли. Это косяк.

Кроссплатформенное приложение это как семьдесят детей у одной няньки. Все кругом кричат "нам надо", а реализовать некому.
— Гость (11/11/2012 03:37)   <#>
Раз тема про уязвимости, добавлю своих 5 копеек.

Я уже давно наблюдаю за TorBrowserBundle (TBB), практически с момента его введения в использование проектом Tor.

  1. При мирном использовании TBB (мирные сайты + настройки TBB по умолчанию) он иногда падает, но относительно редко, чтобы заметить какую-то закономерность. Такие падения можно списать на фазу Луны.
  2. При интенсивном боевом использовании TBB (боевые сайты, множество вкладок, отключенный JS, настройки могут быть любыми) он стабильно падает. Я бьюсь об заклад, что невозможно в таком режиме проработать часов 6, чтобы TBB не упал, но обычно TBB падает через 2-3 часа интенсивной работы. Это поведение стабильно, не зависит от версии TBB, наблюдалось всегда и продолжает наблюдаться сейчас. Видалия остаётся запущенной, а окно firefox просто исчезает со всеми вкладками и всей информацией, падают все скачки и закачки, приходится всё открывать и запускать заново. У меня нет обоснованных гипотез, из-за чего это происходит на некоторых сайтах, я могу только повозмущаться тем, что в сборку добавляют слишком свежий firefox. Если говорить о спекуляциях, я не буду сильно удивлён тому, что на ряде подставных сайтов используется 0day-троян, эксплуатирующий уязвимость в широкой линейнке версий firefox.

Теперь, что касается падения 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?
— Гость (11/11/2012 06:05)   <#>
он стабильно падает.
Ни разу не падал. * стучит по головедереву

/tmp надо хранить в tmpfs

Но вопрос очень важный, если не сказать больше. Если это происходит, то только потому, что так делает firefox, и никто не заметил этого. Нужно искать причины, сообщать разработчикам. И не перекладывать это на других, если есть возможность.
Не спрашивай что проект сделал для тебя! Скажи, что ты сделал для проекта!
Как-то так.
— Гость (11/11/2012 06:07)   <#>
Сообщать сюда
— Гость (11/11/2012 06:32)   <#>
Кто-то из параноиков мог замечать интересную его особенность: при скачивании файла в /tmp создаётся временный нулевой файл.
Проверил, ничего не создается. Firefox 10.
— Гость (11/11/2012 07:48)   <#>
Сообщать сюда
И что я им сообщу? :) Что при невыясненных обстоятельствах такое происходит? Я не уверен, что файл в /tmp создаётся каждый раз или при каждой скачке, я только заметил, что такое бывает, т.е. вижу не первый раз. Если попросят запустить специальную версию TBB с полным дебагом всех событий, то о целевой системе, на которой запущен firefox, будет узнано так много, что баргепортинг не имеет смысла. Даже для обычного осмысленного багрепорта надо сообщать слишком много сведений о своей системе. И, вообще, там анонимно репортить можно, или поди надо логиниться, ящик специально создавать?

Проверил, ничего не создается.
Firefox может создать файл и тут же его удалить, но продолжить в него писать. В Linux есть способы посмотреть дескрипторы всех открытых файлов (lsof), что будет работать, даже если файл удалён. Можно ещё этим методом глянуть.
— Гость (11/11/2012 08:04)   <#>
Про запись файлов в несанкционированные места есть пара идей.

Первая — core dump. Кто регулирует их создание? ОС, само приложение? Если они в системе не отключены, не будет ли сама ОС создавать их при падении TBB?

Вторая — эксплуатация уязвимости вида "переполнение буфера". Про боевые сайты мне ещё много лет назад говорили следующее: если сайт эксплуатирует переполнение буфера в браузере, то на уязвимых его версиях под ОС, для которой написан эксплоит, это сработает, но эта же уязвимая версия браузера под другой ОС при этом просто упадёт. Короче говоря, эксплоиты под браузеры в винде при попытке открыть их уязвимыми версиями браузеров под линукс будут банально падать. Обсуждалось давно, деталей не помню, но что-то такое осело в памяти.
— Гость (11/11/2012 08:25)   <#>
И, вообще, там анонимно репортить можно, или поди надо логиниться, ящик специально создавать?

If you find a topic you want to fix, expand, or create, please either create an account or use the multi-user account cypherpunks

Firefox может создать файл и тут же его удалить, но продолжить в него писать.
Это уже какая-то магия. Зачем это браузеру?
— Гость (11/11/2012 08:50)   <#>
Firefox может создать файл и тут же его удалить, но продолжить в него писать. В Linux есть способы посмотреть дескрипторы всех открытых файлов (lsof), что будет работать, даже если файл удалён. Можно ещё этим методом глянуть.
Проверил, куда указано писать туда и пишет. Никаких лишних дескрипторов по этому поводу не создается.
— Гость (11/11/2012 13:03)   <#>
Раз тема про уязвимости, добавлю своих 5 копеек.
когда речь идет о багах, принято информировать как минимум:
1. какая система установлена.
2. немного о железе (память, процессор, носители)

у меня лично TBB не падал ни при полнолунии, ни при солнечном затмении. стабильность работы пакета даже от времени суток не зависит.
— Гость (11/11/2012 20:18)   <#>
Это уже какая-то магия. Зачем это браузеру?
Не знаю. Например, старые версии флеш-плагина создавали файл /tmp/мусор со скачиваемым с youtube видео. В более новых версиях флеш стал их создавать, но через какое-то время тереть. В ещё более новых ничего не создаётся — всё в директории мозиллы, но суть та же: зачем-то видео бьётся на n кусков, где просмотреть можно только первый, причём даже первый быстро потом удаляется по непонятному алгоритму. Из-за всех этих пертурбаций видео, как раньше, руками не скачать — ничего из кэша толкового не заберёшь, остаётся только плагинами для скачки пользоваться.

когда речь идет о багах, принято информировать как минимум
Убунта, 32 bit. Какое отношение к делу имеет железо? Вот реально, какое отношение к софтварным багам на прикладном уровне имеет железо?! Обычный ПК, двухядерный проц, несколько гигабайт оперативной памяти, места на диске достаточно.

у меня лично TBB не падал ни при полнолунии, ни при солнечном затмении. стабильность работы пакета даже от времени суток не зависит.
Не поверите, но если ходить только по мирным сайтам, и у меня почти так же.
— Гость (11/11/2012 20:27)   <#>
Убунта, 32 bit.
Забыл добавить: i386.
— Гость (11/11/2012 22:01)   <#>
Всё, эксплоит с proof of concept готов:

  1. Идём на станицу http://arxiv.org/abs/1207.5216
  2. Щёлкаем на ссылку на pdf справа сверху: http://arxiv.org/pdf/1207.5216v2
  3. Всплывает окошко "External application is needed to handle". Есть две кнопки: lunch и cancel.
  4. Жмём на lunch, т.к. других вариантов скачать файл нету.
  5. Открывается второе окно, спрашивающее, что мы хотим сделать с файлом. Предлагаются 2 варианта: открыть его с помощью /usr/bin/xpdf (default) или сделать Save.
  6. Мы не жмём на save, но идём в терминал и смотрим ls -la /tmp. Вот он, гадёныш, сидит:
    $ file /tmp/oeXvw4D+.pdf.part 
    /tmp/oeXvw4D+.pdf.part: PDF document, version 1.5
  7. Жмём в предыдущем окне Save. Замечаем, что после нажатия Save файл из /tmp пропадает.

Комментарии:

  1. Когда выбрали lunch, файл пошёл скачиваться, но юзер ещё на тот момент не выбрал, куда же его скачивать. Естественно, скачка идёт во временный файл. Поидее, им должен быть файл в директории tor-browser_en-US/tmp, но это директория почему-то всегда пуста. Вместо этого системный /tmp из-за чего-то получает больший приоритет, и файлы сохраняются в него.
  2. Когда юзер выбрал Save, файл из временной директории можно стереть, предварительно скопировав его в выбранную юзером директорию для закачки. Именно из-за этого потом файлы в /tmp пропадают.
  3. Если что-то пошло не так, и TBB невовремя грохнулся, удалять файл с /tmp некому, он там и останется.

Проверяйте.
— unknown (12/11/2012 00:18)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Подтверждаю.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3