id: Гость   вход   регистрация
текущее время 19:02 29/03/2024
Владелец: SATtva (создано 26/07/2008 21:27), редакция от 26/07/2008 21:27 (автор: SATtva) Печать
Категории: софт, инфобезопасность, защита дисков, безопасная разработка, truecrypt, защита email, уничтожение информации, атаки, защита im, разграничение доступа
http://www.pgpru.com/Новости/2008/ЯвныеПаролиВОперативнойПамятиПовсеместны
создать
просмотр
редакции
ссылки

26.07 // Явные пароли в оперативной памяти повсеместны


Недавнее исследование принстонской группы дало всем понять, что оперативная память компьютера не может считаться совершенно надёжным хранилищем секретных данных: состояние ОЗУ не настолько чувствительно к поддержанию напряжения, как считалось ранее, и противник с физическим доступом к машине способен извлечь содержимое памяти в исходном виде даже после "холодной" перезагрузки. Независимый специалист по инфобезопасности Шерри Давыдофф fileрассмотрел, насколько надёжны распространённые средства шифрования, контроля доступа и обычные программы перед подобным вектором атаки.


Главный предмет поиска в данном случае представляли пароли (а не криптоключи), используемые повсеместно: для получения доступа к почтовому ящику с помощью Thunderbird, подключения к IM-аккаунту через Pidgin, шифрования файлов или дисковых разделов с помощью GnuPG и TrueCrypt, удалённого входа в систему по SSH. Исследование проводилось в среде GNU/Linux (дистрибутив Ubuntu) с отключенным свопом. Давыдофф снимал дамп памяти после использования перечисленных программ, изучал его в поисках паролей, определял оффсет, по которому размещается тот или иной пароль, или последовательности байтов (сигнатуры), так же указывающие на расположенный рядом пароль. Полученные сведения затем использовались для извлечения паролей из второй тестовой системы.


Как оказалось, большинство обычных приложений держат используемые пароли в виде открытого простого текста в памяти своего процесса. Это закономерно, например, для Thunderbird для автоматической проверки почтового ящика. В других случаях это менее понятно: так, пароль от учётной записи пользователя остаётся в памяти оконного менеджера (в данном случае, gdm) даже после успешной аутентификации.


Средства безопасности, разработанные с учётом специфических атак, предпринимают более активные меры, дабы не сохранять пароли в памяти, но, к сожалению, в некоторых случаях не спасает и это. Пароль SSH не был найден в памяти процесса, однако, оказался в общем дампе памяти системы. То же самое касается пароля администратора (root), вводимого в su.


Парольная фраза от ключа GnuPG не была обнаружена ни в памяти процесса, ни в дампе памяти системы. К сожалению [для целей исследования], система безопасности ядра Linux не даёт доступ через устройство /dev/mem к зоне ОЗУ ZONE_HIGHMEM (верхняя половина памяти), поэтому образ мог быть снят только ZONE_NORMAL. Возможно, какие-то пароли могли бы быть найдены в ZONE_HIGHMEM; в то же время, не исключено, что превентивные меры GnuPG по блокированию и нулификации критических данных в памяти не дают им остаться там дольше, чем следует. Как бы то ни было, использование даже сверхзащищённого приложения в небезопасной среде чревато утечками: открытый текст сообщения, расшифрованного с помощью GnuPG, так и остался в памяти терминала Gnome.


Наиболее интересна ситуация в паролями от криптоконтейнеров TrueCrypt 5.1. Когда пользователь вводит пароль, программа позволяет сохранить его в кэше, чтобы избежать последующих запросов. Автор исследования подчёркивает, что кэширование не использовалось. Тем не менее, в памяти процесса TC удалось без труда обнаружить как пароль, так и полный путь и имя файла криптоконтейнера. Более того, область, содержащую пароль, предваряет фиксированная сигнатура (и даже счётчик длины пароля), позволяющая безошибочно опознать его в любой ситуации. Почему пароль сохраняется в памяти, даже когда пользователь явно просит этого не делать, — непонятно.


Атаки на явные пароли (с применением методов "холодной" перезагрузки или снятия дампа привилегированным пользователем) позволяют взломщику не только получить доступ к данным непосредственно на атакованной системе, но и составить словарь паролей для взлома иных систем, используемых тем же лицом. Использование в системе своп-раздела ещё более усугубляет ситуацию: в нём могут обитать пароли, проходившие через ОЗУ месяцы назад.


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


Источник: http://philosecurity.org/resea.....ext-passwords-linux/


 
На страницу: 1, 2, 3, 4 След.
Комментарии [скрыть комментарии/форму]
— ntldr (27/07/2008 05:00)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Почему пароль сохраняется в памяти, даже когда пользователь явно просит этого не делать, — непонятно.

Причина в том, что TrueCrypt всецело полагается на функцию VirtualLock для блокирования критических участков памяти. Но эта функция не гарантирует успешной блокировки, а лишь указывает системе, что заблокированный участок сбрасывать в файл подкачки нежелательно. Я проводил эксперименты с этой функцией, и счел ее слишком ненадежной для блокирования участков памяти содержащих пароли, поэтому DiskCryptor использует собственный механизм блокировки через драйвер, что гарантирует неподкачиваемость заблокированного участка. Также в DiskCryptor реализовано централизованное управление критичными участками памяти (функции secure_alloc/secure_free в файле dcapi\misc.c), что гарантирует корректную блокировку и затирание памяти при освобождении. Механизм блокировки памяти в драйвере также обеспечивает автоматическое затирание данных при нештатном завершении приложения, завершении работы, или падении системы. Подробнее смотрите файл sys\mem_lock.c
— гость01 (27/07/2008 05:56)   <#>
Использование в системе своп-раздела ещё более усугубляет ситуацию: в нём могут обитать пароли, проходившие через ОЗУ месяцы назад.


Если использовать зашифрованный своп, это сделает не возможным обнаружение в нем паролей?
— SATtva (27/07/2008 10:37, исправлен 27/07/2008 10:38)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
гость01, если принимать во внимание возможность атаки с "холодной" перезагрузкой (как в сценарии данного исследования), то шифрование свопа не даёт стопроцентной гарантии. Противник точно так же извлекает сеансовый ключ от свопа из ОЗУ в момент перезапуска машины и расшифровывает им файл подкачки.

Однако одно важное преимущество от шифрования свопа есть. Даже если противнику удастся его расшифровать, он получит лишь данные от последнего сеанса работы, но не от всех предыдущих, какие могли заваляться в свопе. (Последнее справедливо при условии, что для шифрования свопа используются случайные сеансовые ключи, а не один фиксированный.)
— sentaus (27/07/2008 11:28)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Но эта функция не гарантирует успешной блокировки, а лишь указывает системе, что заблокированный участок сбрасывать в файл подкачки нежелательно.

[offtopic]
Кстати, такая же проблема была с GPG под Windows – последние версии перед первым релизом постоянно выводили предупреждения об использовании небезопасной памяти. И, насколько я помню, эту проблему решать не стали – просто перестали выводить предупреждения.
[/offtopic]
— Гость (27/07/2008 16:04)   <#>
Ничё не понял. Если оппонент может снять дамп оперативной памяти то не спасёт уже тождественно ничего (если пароли или ключи в том или ином виде в этот моент там были). Если же своевременно программы удаляют свои пароли после того как они не требуются – то да, уже не получится. Получается, что новость лишь о том, что не все проги корректно очищают свои области данных в оперативке, но не более того.
— SATtva (27/07/2008 17:00)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Тем, кто не понял, — внимательно перечитать предпоследний абзац этой новости, новость об атаке через "холодную" перезагрузку, а также саму процитированную здесь работу.
— Гость (27/07/2008 20:07)   <#>
Там написано что Джон Каллас предложил схему защиты (посл абзац): это собираются реализовывать в каких-либо программных продуктах или явно не в ближайшем будущем? Или это убдет существенно замедлять работу программ?
— ntldr (27/07/2008 20:55)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
обфускация паролей в памяти, дабы затруднить их выявление по простым текстовым подстрокам

Это в корне неправильное решение, security through obscurity. Оно работает только тогда, когда атакующий не знает алгоритма обфускации. Если у атакующего есть дамп памяти, то эта мера не поможет, а если нет – то эта мера не нужна. Зато подобные меры "защиты" затрудняют поиск уязвимостей, аналогичных вышеописанным, из за чего эти уязвимости не будут исправлены. Вывод: предложенная мера не повышает безопасность, а наоборот понижает.
Я категорически против security through obscurity, и ни в коем случае не буду применять ничего подобного.
— Гость (27/07/2008 21:59)   <#>
По такой логике запирать двери бесполезно – всё равно специалист вскроет. :)
— Гость (27/07/2008 22:17)   <#>
А мужики то и не знают! :))
— SATtva (28/07/2008 00:51, исправлен 28/07/2008 00:53)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Там написано что Джон Каллас предложил схему защиты (посл абзац): это собираются реализовывать в каких-либо программных продуктах или явно не в ближайшем будущем?

Реализовано в PGP.

Я категорически против security through obscurity, и ни в коем случае не буду применять ничего подобного.

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

В большинстве случаев, однако, нет никакого смысла, чтобы таскать пароли по ОЗУ. В тех же случаях, когда это явно необходимо, можно найти способ не держать его открытым текстом. Я бы не смешивал понятия "безопасности через неясность" и "сокращение уязвимой площади" (так, даже если память будет выгружена в своп или в hibernate-файл, противник не сможет пройтись по диску чёсом и использовать найденные строки как материал для дальнейших атак).
— Гость (28/07/2008 03:26)   <#>
Я бы не смешивал понятия "безопасности через неясность" и "сокращение уязвимой площади" (так, даже если память будет выгружена в своп или в hibernate-файл, противник не сможет пройтись по диску чёсом и использовать найденные строки как материал для дальнейших атак).

Любой программист со средними навыками за час напишет алгоритм для поиска строк с учетом обфускации. Например большинство программ сохраняет пароли в своих конфигах тоже не открытым текстом, а используя разнообразную обфускацию. И что, это хоть кому-то помогло? Пароли тащат все кому не лень, для чего написана куча разных программ. Вы думаете что поиск строк на диске с учетом обфускации не будет добавлен в соответствующий софт? Это самая натуральная безопасность через неясность, и ни что иное. PGP – коммерческий продукт, и они будут делать все, за что платят деньги, пусть даже это ни в малейшей степени не обосновано. Нормальная безопасность должна строиться на предотвращении попадания пароля на диск. DiskCryptor работает именно по этому принципу. Например он не разрешает запись дампов и вхождение в hibernate если имеются подключенные разделы и системный раздел не зашифрован.
— SATtva (28/07/2008 08:08)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Простой пример. Цель: минимизировать риск восстановления пароля, выгруженного на диск. Реализация: пароль хранится в памяти в зашифрованном виде; сеансовый ключ располагается в произвольном участке памяти процесса.

Нормальная безопасность должна строиться на предотвращении попадания пароля на диск.

Нормальная безопасность должна опираться на то, чтобы пароли просто не болтались в памяти. Но не всякое ПО может следовать этому принципу. Если мэйл-клиент кэширует в памяти пароль от почтового ящика (что требуется для правильной работы программы), он тоже должен блокировать переход в спящий режим или реализовывать блокировку памяти через собственный драйвер?

Например он не разрешает запись дампов и вхождение в hibernate если имеются подключенные разделы и системный раздел не зашифрован.

А запрет на снятие дампов — это не "безопасность через неясность" по Вашей логике?
— Гость (28/07/2008 08:51)   <#>
Любой программист со средними навыками за час
Любой слесарь со средними навыками, обладая соответствующим инструментом, вскроет за час почти любой замок. Но большинство всё-таки ставит замки. И что, это хоть кому-то помогло? :)

поиск строк на диске с учетом обфускации не будет добавлен в соответствующий софт?
Вот в этом "будет добавлен" всё и дело. Этот софт ещё нужно будет найти. Для него нужно бкде оперативно отслеживать изменения в новых версиях (а также появление клонов и новых программ). то есть прикладывать дополнительные усилия. Желание (взломщиков) экономить усилия и даёт прирост в защите.

Одно дело, когда взламывают целенаправлено вас – тут это не поможет, а другое – когда просто кого-нибудь. В этом и смысл запирания дверей – если замок не открылся стандартными методами, проще угнать другую машину. (Представьте себе, например, возможные массовые рейды по выявлению запрещённой литературы пиратского софта ради бабла или "галочки")

В конце концов, если мы живём в вероятностном мире (и пароль тоже можно быстро подобрать с некоторой вероятностью, которую уменьшает увеличение его длины, кстати, зачем?;), почему бы не уменьшить вероятность взлома и таким способом?

"Сокращение уязвимой площади" хороший принцип, повсеместно использующийся и в военном деле. Вы же не предлагаете отменить каски на том основании, что они не защишают лицо и не спасают от прямого попадания снаряда.
Почему-же в сфере ИБ должно быть по другому?
— Гость (28/07/2008 09:07)   <#>
когда взламывают целенаправлено вас – тут это не поможет
И то при условии достаточной квалификации взломщика.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3