Читать онлайн «19 смертных грехов, угрожающих безопасности программ». Страница 44

Общепринятый способ моделирования безопасности информационного потока–это модель Белла–ЛаПадулы (рис. 13.1). Основная идея в том, чтобы представить иерархию прав в виде вершин графа. Некоторые вершины соединены ребрами. Относительные позиции важны, так как информация должна течь только «вверх» по графу. Интуитивно чем вершина выше, тем она более конфиденциальна, и информация некоторого уровня секретности не должна поступать субъектам, которым разрешен доступ только к менее секретной информации. Вершины, находящиеся на одном и том же уровне, не должны передавать информацию друг другу, если между ними нет ребра. Наличие ребра означает один и тот же уровень доступа.

Примечание. Это несколько упрощенное изложение, но для наших целей его достаточно. Оригинальное описание модели, датируемой 1974 годом, – это документ на 134 страницах!

Модель Белла–ЛаПадулы – это абстракция модели, используемой правительством США для классификации данных (например, «сверхсекретно», «секретно», «для служебного пользования», «открыто»). Не вдаваясь в детали, отметим, что она позволяет моделировать также разбиение на отделы. Это означает, что наличие допуска к сверхсекретным документам еще не означает, что вы можете читать любой такой документ. На каждом уровне имеются еще и подуровни.

Рис. 13.1. Модель Белла–ЛаПадулы

Эта модель включает также понятие о недостоверных данных. Например, данные, помеченные тегом «недостоверно», несут эту печать в течение всего срока своего существования. При попытке использовать такие данные в «высокопривилегированной» операции система будет возражать.

Создавая собственную модель привилегий, изучите сначала модель Белла–ЛаПадулы и реализуйте механизм, навязывающий ее. Но учтите, что на практике нередко приходится ослаблять требования, например потому, что необходимо использовать данные из не заслуживающего доверия источника в привилегированной операции. Бывают также случаи, когда нужно избирательно раскрывать информацию, например позволить компании, обслуживающей кредитные карты, видеть номер карты, но не имя ее владельца. Это соответствует идее селективного «рассекречивания» данных. Вообще говоря, вы должны реализовать специальный API, который явно разрешает «рассекречивание». Семантика вызова будет такова: «Да, я хочу передать эту информацию субъекту с меньшими привилегиями (или разрешить операцию, запрошенную таким субъектом). Это нормально».

Модель Белла–ЛаПадулы применяется в системах безопасности нескольких языков программирования. Так, модель привилегий в Java (наиболее отчетливо проявляющаяся в аплетах) основана на модели Белла–ЛаПадулы. С каждым объектом связан набор разрешений, и система не выполнит вызов, если не все участвующие в запросе объекты (стек вызова) обладают необходимыми разрешениями. Операцией явного «рассекречивания» является вызов метода doPrivileged(), который позволяет обойти проверку стека (в Java это называется «инспекцией стека»). В общеязыковой среде исполнения (CLR) в .NET тоже имеется аналогичная модель «разрешений» для сборок.

Греховность С# (и других языков)

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

...

Родственные грехи

Ближайший родственник этого греха обсуждался в грехе 6. Сюда же можно отнести кросс–сайтовые сценарии с раскрытием данных, хранящихся в куках (грех 7), и внедрение SQL–команд (грех 4), в результате которого противник может изменить SQL–запрос к базе данных.

В грехе 11 мы привели пример побочного хронометрируемого канала при описании ошибки в системе TENEX.

Обращайте внимание на следующие места:

□ процесс посылает пользователям информацию, получаемую от ОС или среды исполнения;

□ операции над секретными данными, время завершения которых не фиксировано и зависит от обрабатываемых данных;

□ случайное использование конфиденциальной информации;

□ незащищенные или слабо защищенные конфиденциальные или привилегированные данные;

□ процесс передает конфиденциальные данные пользователям, которые могут оказаться низкопривилегированными;

□ незащищенные конфиденциальные данные передаются по незащищенным каналам.

Это может оказаться нелегкой задачей, поскольку во многих системах нет четкого понятия о том, какие данные считать привилегированными, а какие – нет. В идеале вы должны понимать, как может использоваться любой существенный элемент данных, иметь возможность проследить все случаи его использования в программе и убедиться, что он никогда не попадает субъектам, не обладающим необходимыми правами. Сделать это, безусловно, можно, но в общем случае довольно трудно. Лучше возложить решение данной задачи на какой–нибудь динамический механизм, контролирующий соблюдение требований модели Белла–ЛаПадулы.

Если такая модель у вас имеется, то нужно лишь аудировать взаимосвязи между привилегиями и точками явного рассекречивания с целью убедиться, что оба элемента корректны.

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

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

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

Чтобы найти места, подверженные атаке с хронометражем, начните с идентификации секретных данных, например ключей. Затем исследуйте все операции над этими данными, чтобы понять, есть ли какая–нибудь зависимость от данных. Далее следует определить, меняется ли время выполнения зависимых операций, когда на вход подаются разные данные. Это может оказаться трудно. Ясно, что если имеются ветвления, то вариации во времени будут почти наверняка. Но есть множество неочевидных способов вызвать зависимость от времени, мы об этом уже говорили выше. Реализации криптографических алгоритмов следует подвергать сомнению, если в них не предприняты явные меры против атак с хронометражем. Удаленное проведение таких атак может и не привести к успеху, на практике их обычно проводят локально. Так что если у приложения есть локальные пользователи, то лучше перестраховаться, чем потом кусать локти.

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

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

Чтобы выяснить, возможна ли на практике атака с хронометражем, в общем случае придется прибегнуть к динамическому тестированию. К тому же надо разбираться в математической статистике. Мы не будем затрагивать здесь эту тему, а отошлем вас к работе Дэна Бернстайна (Dan Bernstein) по атакам с хронометражем на криптографические алгоритмы (см. раздел «Другие ресурсы»).

Имитация кражи ноутбука

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

□ загрузка из другой операционной системы;

□ установка на одну машину двух ОС;

□ установка системы с выбором загрузчика (dual boot);

□ подбор какого–нибудь распространенного пароля для входа в систему.

Начнем с примеров атак с хронометражем, а затем перейдем к более традиционным способам утечки информации, о которых есть сообщения в базе данных CVE (http://cve.mitre.org).

Атака с хронометражем Дэна Бернстайна на шифр АЕS

Дэн Бернстайн сумел провести удаленную атаку с хронометражем на реализацию AES в OpenSSL 0.9.7. Оказалось, что использованные в ней большие таблицы вытесняются из кэша, в результате чего время исполнения кода перестает быть постоянным. Операции и до некоторой степени поведение кэша зависят от ключа. Бернстайну удалось вскрыть защищенное соединение после просмотра примерно 50 Гб зашифрованных данных. Впрочем, нелишним будет одно предупреждение. Во–первых, он мог бы сделать атаку более изощренной и не собирать так много данных. Разумно предположить, что ключ можно было бы получить уже после анализа нескольких гигабайтов данных, а быть может, и того меньше.