Регистрация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/
Нет, он просто не должен хранить этот пароль дольше, чем это нужно для проверки почты. Если он хранит пароль постоянно, то связанные с этим опасности должны быть отражены в документации, чтобы не вводить пользователя в заблуждение. По хорошему ОС должна обеспечивать надежные механизмы выделения безопасной памяти для таких применений.
Нет, это provable security. Запись дампа при падении системы блокируется, а значит никакого пароля на диске не будет. Взломщику просто нечего будет взламывать. Очень просто и очень надежно. Естественно, это не защита от вредоносного ПО, а лишь защита от утечки пароля через стандартные механизмы системы. И надежность этой защиты доказуема.
Если надежность защиты хоть в малейшей степени зависит от знания взломщиком принципов ее работы, то это есть безопасность через неясность. Этот подход работает только в том случае, если механизм обфускации каждый пользователь программы пишет сам, и хранит в секрете.
Потому что небезопасность такого способа очевидна. Криптография – это не та область, где допустимо подобное.
Потому что в сфера ИБ – это не военное дело. И криптография – это не каска. Если используемые криптоалгоритмы защищают от прямого попадания снаряда, то всё остальное должно им соответствовать. Таковы мои требования к качеству кода, и таково мое представление о безопасности, в соответствии с которым я буду развивать свой софт. На этом позвольте откланяться, я все сказал.
комментариев: 11558 документов: 1036 редакций: 4118
Это нужно для автоматической проверки раз в надцать минут (не спрашивать же пароль у пользователя каждый раз?). В заблуждение никто никого не вводит — пользователь сам ставит галочку на "Кэшировать" или "Проверять новые сообщения раз в ___ минут".
Должна. Вот только когда такие ОС появятся?
Мне кажется, здесь возникло недопонимание. Дампы, о которых идёт речь в статье, — это не crash-дампы, выполняемые операционной системой, а образы ОЗУ, снимаемые пользователем "изнутри" системы штатными средствами, или снимаемые нештатными средствами "извне" после "холодной" перезагрузки. Можно и иные способы придумать (интерфейсы PCI, PCMCIA и т.д.). Термин provable security я бы тут не употреблял. Образ/дамп ОЗУ получить можно всегда, если есть физический доступ к работающей машине.
Не могу сказать, чтобы я был с этим несогласен. Но ИБ — это не одна только криптография. Был в статье пример с открытым текстом GnuPG, оставшимся в памяти терминала: криптография — не самоцель, всегда следует учитывать окружение, вплоть до пользователя системы (если можно сделать программу так, чтобы она не позволила пользователю выстрелить в свою ногу, то нужно сделать именно так; в этом смысле запрет на спящий режим в DiskCryptor, если не может быть гарантирована безопасность hibernate-файла, — это есть правильно).
Ну и ещё Шнайер в последнее время регулярно приводит пример: если благодаря сигнализации в вашем доме грабители пошли грабить дом соседа, то вы в выигрыше (хоть и не всё общество), и это — хорошая безопасность.
От подобной атаки нет, и не может быть никакой программной защиты, и позиционирование обфускации как меры противодействия – есть преднамеренный обман пользователя. Возможность подобной атаки должна быть четко описана в документации, и пользователь должен принять меры исключающие использование подобной атаки. Наличие видимости защиты гораздо хуже ее отсутствия, так как заставляет пользователя надеяться на программные полумеры, вместо того, чтобы создавать реальную физическую защиту. В документации DiskCryptor описаны варианты подобных атак, и в любом подходящем случае обращаю на это внимание. Нельзя, чтобы пользователь думал, что поставив мою программу он автоматически становиться защищен от всего на свете. Впрочем, введение пользователей в заблуждение является необходимым условием успешных продаж любой коммерческой программы связанной с ИБ, поэтому там можно найти немало подобных обманных полумер.
Нельзя, чтобы надев каску, солдат думал, что он защищён от всего на свете? Конечно. Повод ли это отменить каски – конечно нет!
зы
Хрущёв решил, что если есть ядерные ракеты, не нужно нам обычное вооружение. История показала, что он ошибался.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
информационно-теоретическая стойкость – любой противник обладающий любыми знаниями и любыми ресурсами никогда не сможет взломать алгоритм, причём это строго доказано. Реально это только для одноразовых блокнотов (при наличии трудностей в реализации). Ещё на эту роль претендуют квантовая и шумовая криптография ( у них еще больше трудностей с реализацией, и с доказательствами – особенно для шумовой). В идеале – это абсолютная ИБ, упирающаяся только в практическую реализацию.
вычислительная стойкость – противник обладающий максимумом доступных вычислительных и энергитических ресурсов в больших, но всё-таки ограниченных рамках (Земного Шара/Солнечной системы/Галактики) и т.д. не может взломать алгоритм.
доказуемая безопасность – доказательство, что задача взлома системы относится к решению задачи вычислительной стойкости. В практической реализации доказуемой безопасности не существует. Абсолютных методов получения самих доказательств получено не было, как и доказательств возможности вычислительной стойкости.
Для чего это нужно? Потому что как только мы переходит от теории к практике и конкретной реализации стойкость системы намного снижается. Поэтому и считалось, по словам раннего Шнайера, что или мы ставим целью защищаться от правительств ведущих мировых держав или от младшей сестры. У криптографии первого рода есть какой-то шанс (хотя эти цели могут быть всё-равно недостигнуты), у второй – никакого, а промежуточная скатывается к уровню "младшей сестры".
Затем Шнайер почти забросил теорию криптографии, занялся бизнесом и консультированием. Там этот максималистский подход продавался плохо. Кроме того безопасность зависит от многих факторов, не только от криптографии, которая тоже реализуется неидеально и работает в неидеальном окружении.
Он и придумал схему страхования рисков. Если что-то можно реализовать на уровне теоретически вычислительно стойкой системы, так и надо делать. Но если это реализуется плохо (не из-за ошибок разработчиков, а из-за ограничений, потому что иначе в реальности не сделать) или там где такой подход обходится слишком дорого, там Шнайер предлагает использовать ограниченные и несовершенные методы обеспечения ИБ, а риски застраховать.
Как ведёт свой бизнес мистер Шнайер и его фирма Counterpane я помню не очень детально, страхует ли он риски сам? Маловероятно. Скорее всего, он только выступает посредником. По крайней мере он сообщал, что он их оценивает. И берёт деньги за оценку и обслуживание рисков, аутсорсинг, аудит и даже непрерывный мониторинг чужих систем и сетей.
Если к вашей системе в вашей фирме прилагается контракт на сотрудничество с командой экспертов под руководством хитрого Шнайера, то тогда смело можете использовать методы "ограниченной защиты". Это торговля, бизнес. Всё покроется страховкой, сменой бизнес-стратегии если что. Если у вас такой возможности нет, и ваша модель угрозы не позволяет страховать информационные риски и обходиться с ними как с товаром, подумайте лишний раз, что рекламирует хоть и специалист в ИБ, но не в последнюю очередь удачливый бизнесмен (редкое сочетание научного и коммерческого таланта) мистер Шнайер.
Это взаимный процесс. Вспомним изобретение ARPAнета/MILнета/Интернета .
В последнее время заметна т.н. тенденция к псевдомаркетингу в FOSS. Некоммерческие программы стараются подражать коммерческим, чтобы привлечь корпоративных пользователей, получить деньги спонсоров, "завоевать десктоп", показать, что они не хуже коммерческих по числу фич. Иногда даже в ущерб своему качеству, но это уже оффтопик.
Касаемо GnuPG, как последняя надежда, полумеры против слабого противника могут быть использованы (как неполные методы защиты), если исходить из того, что для "рядового пользователя", такой противник наиболее вероятен, но надо отдавать себе отчёт, чего они стоят на самом деле. Возможно появится противник, который не сможет установить "сильный" руткит, против этого антикейлоггера, но зато сможет как-то в обход имитировать такое окошко для неопытного пользователя. Забота о неопытных пользователях – это палка о двух концах.
комментариев: 9796 документов: 488 редакций: 5664
Вопрос уже чисто психологического выбора.
комментариев: 11558 документов: 1036 редакций: 4118
На сложность самой программы pinentry и gpg-agent не влияют, их связь с программой происходит через абстрактный интерфейс статус-сообщений.
комментариев: 9796 документов: 488 редакций: 5664