WildGoblin
Ru-Board Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата: 26.07 // Явные пароли в оперативной памяти повсеместны
Недавнее исследование принстонской группы дало всем понять, что оперативная память компьютера не может считаться совершенно надёжным хранилищем секретных данных: состояние ОЗУ не настолько чувствительно к поддержанию напряжения, как считалось ранее, и противник с физическим доступом к машине способен извлечь содержимое памяти в исходном виде даже после "холодной" перезагрузки. Независимый специалист по инфобезопасности Шерри Давыдофф рассмотрел, насколько надёжны распространённые средства шифрования, контроля доступа и обычные программы перед подобным вектором атаки.
Главный предмет поиска в данном случае представляли пароли (а не криптоключи), используемые повсеместно: для получения доступа к почтовому ящику с помощью 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/ |
Источник
P.S. Интересно актуально это в шестой версии или нет? |
