WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 3 | 4 || 6 |

«О.В. КАЗАРИН Москва 2004 УДК 681.322 Казарин О.В. ...»

-- [ Страница 5 ] --

Алгоритм построения структурного дерева программы (алгоритм А) сводится к реализации следующей конструкции. Построение структурного дерева программы осуществляется параллельно со сверткой управляющего графа, когда выделенная конструкция заменяется одной вершиной. Для краткости управляющий граф на очередном этапе свертки будем называть графом программы. Таким образом, граф программы будет последовательно преобразовываться в G0,G1,..., где G0 - исходный управляющий граф последовательности - граф, состоящий из одной вершины.

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

А2. В графе программы ищется структурированная конструкция. Если такой нет, то выполняется переход к шагу А4.

А3. В дереве образуется вершина структурированной конструкции. Эта конструкция сворачивается в вершину, тип которой указывается. Выполняется переход к шагу А2.

А4. Если в графе осталась только одна вершина, то работа алгоритма заканчивается.

А5. В графе выделяется неструктурируемая конструкция и в структурном дереве образуется вершина соответствующего типа.

Конструкция в графе сворачивается, после чего выполняется переход к шагу А2.

Построение структурного дерева выполняется от элементов, представляющих вершины управляющего графа, к элементу, представляющему всю программу целиком. Используя понятие структурного дерева программы, можно рассчитать существенную EV = 1 + сложность программы EV: S(V(i)-1), где NS (V (i) - 1) iNS множество вершин неструктурируемого типа в структурном дереве;

V(i) - топологическая сложность конструкции, соответствующей i-й вершине дерева.

Вычисление V(i) производится на шаге А5 алгоритма по формуле V(i)=e(i)-n(i)+2, где e(i) - количество дуг, а n(i) - количество вершин рассматриваемой конструкции.

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

7.7.3. Определение характеристик взаимосвязи модулей и структурной сложности программ с учетом полного числа связей Характеристики иерархической структуры и взаимосвязей модулей между собой в процессе решения задач КУП определяются на основе:

• анализа блок-схемы комплекса с выделением глобальных переменных, используемых в программах;

• формирования групп программ, обращающихся к анализируемой программе, к заданной зоне глобальных переменных или к конкретной переменной;

• вычисления числа переменных в программных модулях, количества условных переходов и циклов в программах.

В процессе анализа блок-схемы комплекса программ определяется количество уровней иерархии структуры комплекса (r), распределение числа программ по уровням P1(r) и распределение среднего количества команд в программах различных уровней P2(r).

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

Взаимосвязь модулей комплекса программ между собой характеризуются распределением числа вызываемых программ P3(r) и распределением числа программ, обращающихся к анализируемой программе - P4(r). Подсчет сложности взаимодействия модулей выполняется с учетом всех управляющих и информационных связей путем интегрирования характеристик модулей. Для каждого i-го модуля число путей входа в него или число модулей, откуда он вызывается, характеризуется величиной aij входных управляющих связей. Аналогично число выходных управляющих связей можно представить как число модулей bij, вызываемых из данного. Наименьшая связность реализуется, когда i-й модуль сопрягается только с одним j-м программным модулем и имеет одну входную (aij=1) и одну выходную (bij=1) связи. В этом случае модуль не вызывает другие модули, а только возвращает управление после завершения своей функции. В результате i-тый модуль находится на нижнем уровне в данной ветви комплекса программ, так как он не вызывает других модулей.

В общем случае сложность управляющих связей для i-того модуля Ci = + ij ) можно представить суммой:. Тогда сложность связей (ij j C = = + ij ) группы программ имеет вид:, где Ci (ij i i j суммирование идет по всем модулям, входящим в группу.

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

Информационные связи между модулями анализировать сложнее, чем управляющие. Это обусловлено тем, что возможны, с одной стороны, информационные связи между модулями, непосредственно не связанными по управлению, а с другой стороны - тем, что каждая информационная связь может характеризоваться различным числом и типом переменных, участвующих в обмене. В первом приближении информационная связь i того и j-того модулей может быть оценена количеством глобальных и обменных переменных с одинаковыми именами, используемых в планируемой паре модулей. Степень зависимости каждого модуля от остальных можно характеризовать количеством типов (индекс k) переменных aij на входе, необходимых для нормального Ai = ik.

функционирования данного модуля: a k Количество результирующих переменных, подготавливаемых i-м модулем, характеризует степень информационной зависимости от него Bi = ik, где k - количество типов всех остальных модулей в комплексе: b k переменных на входе. При этом, если некоторая k-тая результирующая переменная используется несколькими модулями, то количество информационных связей равно соответственно сумме числа модулей, использующих каждую k-тую переменную.

Переменные, которые используются i-тым модулем не модифицируясь, является только входными и не учитываются как выходные связи.

Таким образом, количественно охарактеризовать информационные Bi = (a + bik ) связи i-того модуля можно следующим образом: ik =Ai+BB.

i k Полное количество информационных связей в группе программ равно B = сумме связей модулей B = (a + bik ) =Ai+BB.

i ik i ii k Каждая информационная связь учитывается в модулях, имеющих переменную на входе. В результате некоторая k-тая глобальная переменная может участвовать в нескольких информационных связях программ, способных использовать эту переменную на входе, и в выходных связях только тех программ, которые модифицируют значение данной переменной. Таким образом, сложность информационных связей через k тую глобальную переменную можно представить выражением:

Bk = (a + bik ).

ik i Обычно каждая глобальная переменная используется двумя или более программами, а модифицируется чаще всего одной, т.е. Вk=3-4. С точки зрения обеспечения технологической безопасности программ необходима тщательная проверка условий модификации переменных, так как именно в эти моменты может изменяться режим работы программы за счет использования значений глобальной переменной в качестве управляющих элементов.

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

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

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

Алгоритм построения маршрутов тестирования критических путей основан на использовании управляющего графа и структурного дерева комплекса. При этом необходимо построить маршруты тестирования от входа до выхода (если существуют несколько входов и выходов, что характерно для большинства управляющих программ, то такие маршруты строятся для каждого входа и каждого выхода), покрывающие в совокупности каждую ветвь модулей с наибольшей сложностью связей хотя бы один раз. Алгоритм является модификацией известного алгоритма структурного построения тестов [Ма], причем введенные дополнения ориентированы на специфические особенности выявления РПС в сложных программах.

Алгоритм Б Б1. В управляющем графе компоненты (вершины – линейные участки и дуги - управляющие связи между линейными участками), относящиеся к одному модулю, условно объединяются в макровершину, которой присваивается весовой коэффициент, соответствующий численному значению сложности информационных связей данного модуля.

Б2. Отмечаются все входы и выходы управляющего графа и фиксируется первый вход.

Б3. Если все входы рассмотрены, то выполняется переход к шагу Б9, иначе выполняется переход к шагу Б4.

Б4. Строится очередной путь, причем первой вершиной пути назначается зафиксированный вход.

Б5. Если текущая вершина пути не выходная, то необходимо перейти к шагу Б6, в противном случае - к шагу Б4 (путь построен).

Б6. Если у последней вершины пути выходят необработанные дуги, то выполняется переход к шагу Б7, в противном случае - к шагу Б8.

Б7. В текущий путь включается необработанная дуга с началом в последней (текущей) вершине пути. Если таких дуг несколько, то выполняется переход к шагу Б5.

Б8. Строится кратчайший путь из последней (текущей) вершины до ближайшей вершины допустимого множества, в которое включаются выходные вершины графа, если в текущем пути уже есть хотя бы одна дуга, а также все вершины, из которых выходят некоторые дуги, если ни одна из вершин не пройдена дважды. Если такой кратчайший путь существует, то он присоединяется к текущему пути, после чего делается переход к шагу Б5. В противном случае фиксируется следующий вход, если это возможно, и делается переход к шагу Б3.

Б9. Участкам пути, входящим в макровершины, присваиваются весовые коэффициенты в соответствии с весами макровершин. Для каждого полного пути определяется весовой коэффициент пути, равный сумме весов входящих в него участков.

Б10. Вычисляется среднее значение весовых коэффициентов путей тестирования, после чего составляется множество критических путей, весовые коэффициенты которых выше среднего. Алгоритм заканчивается.

Необходимо сделать некоторые пояснения к алгоритму Б:

• при построении кратчайшего пути до ближайшей вершины из допустимого множества используется модификация известного алгоритма Дейкстры (достаточно сравнивать вершину с минимальной временной пометкой на принадлежность допустимому множеству) [Кн];

• при выполнении шага Б8 ограничения на допустимое множество накладываются в соответствии с двумя соображениями: во первых, желательно получить не слишком длинные пути, так как весьма вероятно, что они окажутся нереализуемыми, а во-вторых, желательно получить как можно больше путей, однако при этом необходимо контролировать выполнение условия, чтобы число путей не превысило топологическую сложность рассматриваемого участка программы (топологическая сложность определяется при построении структурного дерева программы по алгоритму Б);

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

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

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

ГЛАВА 8. МЕТОДЫ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ ПРОГРАММ ДЛЯ КОНТРОЛЯ ИХ ТЕХНОЛОГИЧЕСКОЙ БЕЗОПАСНОСТИ 8.1. ИСХОДНЫЕ ДАННЫЕ, ОПРЕДЕЛЕНИЯ И УСЛОВИЯ При исследовании методов и средств оценки уровня технологической безопасности программных комплексов учитываются факторы, имеющие, в том числе, чисто случайный характер. Следовательно, показатели, связанные с оцениванием безопасности ПО лучше всего выражать вероятностной мерой, а для их вычисления можно использовать вероятностные модели надежности ПО [Гл,Го,ИКБ,Лип0,ТЛН], которые при осуществлении замены условия надежности функционирования программ на условие их безопасности можно использовать для этих целей.

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

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

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

и наоборот, дефект рассматривается как проявление допущенной ранее ошибки [ТЛН].

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

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

Во-вторых, под определенными условиями внешней среды следует понимать описание входных данных и состояние вычислительной системы в процессе выполнения программы. Состояние вычислительной системы описывается в основном объемом оперативной памяти и зависит от требований к программному обеспечению в части его способности нормально функционировать при наличии отказов. Под способностью подразумеваются свойства программного обеспечения, которые закладываются при его проектировании (например, возможность смены программ в памяти;

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

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

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

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

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

E=(Ei:i=1,2,...,N);

Интуитивное определение безопасности ПО может быть уточнено в статистическом смысле на основе следующих простых соображений:

• выполнение программы П приводит к получению для каждого Ei определенного значения функции F(Ei);

• множество E определяет все возможные вычисления в программе П, то есть каждому набору входных данных Ei соответствует прогон программы П, и наоборот, каждому прогону соответствует некоторый набор входных данных Ei;

• наличие дефектов в программе П приводит к тому, что ей на самом деле соответствует функция F', отличная от заданной функции F;

• для некоторого Ei отклонение выхода F'(Ei), полученного в результате выполнения программы не должно превышать некоторый установленный уровень безопасности программного обеспечения S(Ei), то есть безопасность обеспечивается при соблюдении ограничения: F'(Ei)S(Ei).

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

8.2. КРАТКИЙ АНАЛИЗ СУЩЕСТВУЮЩИХ МОДЕЛЕЙ НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 8.2.1. Определение модели надежности программного обеспечения Модель надежности программного обеспечения - это, как правило, математическая модель, построенная для оценки зависимости надежности программного обеспечения от некоторых определенных параметров.

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

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

Рассмотрим некоторые модели надежности программного обеспечения, которые в той или иной степени могут представлять интерес в контексте исследуемой работы.

8.2.2. Модель Шумана Целесообразность применения модели Шумана [ТЛН] для оценки надежности программного обеспечения зависят от принятых допущений и условий, наиболее существенным из которых является условие существования программы-исследователя системы. Остальные допущения и условия носят статический характер и не связаны с какими-либо специфическими свойствами программного обеспечения. По существу они сводятся к следующему:

• предполагается, что в начальный момент компоновки программных средств в системе имеется Еt, ошибок. С этого момента начинается отсчет времени отладки t, которое включает затраты времени на выявление ошибок с помощью тестов, на контрольные проверки и т.п. при этом время исправного функционирования системы не учитывается;

• предполагается, что значение функции частоты отказов т(t) пропорционально числу ошибок, оставшихся в программном обеспечении после израсходования времени t на отладку исследуемой программы.

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

8.2.3. Модель Джелинского-Моранды Данная модель [ТЛН], предназначенная в основном для прогнозирования надежности программного обеспечения, представляет собой частный случай модели Шумана. При разработке этой модели предполагалось, что значения интервалов времени отладки (в смысле модели Шумана) между обнаружением двух ошибок имеют экспоненциальное распределение с частотой ошибок (или интенсивностью отказов), пропорциональной числу невыявленных дефектов. Каждая обнаруженная в программе ошибка немедленно устраняется и, следовательно, число оставшихся ошибок уменьшается на единицу.

Модификация модели Джелинского-Моранды была предложена Шиком и Волвертоном. В основе модели Шика-Волвертона лежит предположение, согласно которому частота ошибок пропорциональна не только количеству ошибок в программах, но также и времени отладки, т.е.

вероятность обнаружения ошибок с течением времени возрастает.

8.2.4. Другие модели надежности программного обеспечения Модели Джелинского-Моранды и Шика-Волвертона могут быть обобщены, если допустить возможность возникновения на рассматриваемом интервале более одной ошибки и считать, что исправление ошибок производится лишь после истечения интервала времени, на котором они возникли.

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

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

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

Модели, предложенные Коркореном и др. [ТЛН] заслуживают внимания по следующим причинам. Во-первых, они содержат изменяющиеся вероятности отказов для различных источников ошибок и соответственно разные вероятности их исправления. Во-вторых, они относительно просты с математической точки зрения и допускают простую интерпретацию данных об ошибках в ПО. В этих моделях не используется такой параметр, как время тестирования, а учитывается только результат N испытаний, в которых наблюдается Ni ошибок i-ro типа (относящихся к i-тому источнику отказов).

8.2.5. Анализ моделей надежности программ В моделях Шумана и Джелинского-Моранды в качестве независимой переменной фигурируют время и надежность, вычисляемая по формуле R(t)=e-ht.

Значение интенсивности отказов h предполагается постоянным в течение всего периода функционирования системы и изменяется только при обнаружении и устранении ошибок, после чего время t снова отсчитывается от нуля. Поскольку эта формула может быть получена как частный случай рассматриваемой ниже модели Нельсона при некоторых допущениях целесообразно определить условия, при которых верны модели Шумана и Джелинского-Моранды. Эти условия таковы:

• время t должно интерпретироваться как суммарное время работы программы относительно некоторого определенного начального момента времени;

• время t должно быть больше средней длительности выполнения одного прогона программы t;

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

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

В моделях Вейса и Коркорэна [ТЛН] были предложены формулы для определения степени повышения надежности программы в процессе тестирования, причем в этих моделях была предпринята попытка учесть эффект существования в программе нескольких источников ошибок.

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

8.3. ОПИСАНИЕ МОДЕЛИ НЕЛЬСОНА 8.3.1. Обоснование выбора модели Нельсона Модель Нельсона была разработана с учетом основных свойств машинных программ и использует методы теории вероятностей лишь в тех случаях, когда невозможно получение полной информации о том или ином факторе, например при ответе на вопрос, какой набор входных данных следует взять при следующем прогоне программы. Все приближения, принятые модели, четко определены, и известны границы их применимости. Поскольку в основу модели Нельсона положены свойства программного обеспечения, она допускает развитие за счет более детального описания других аспектов надежности. Некоторые из полученных обобщений модели [ТЛН] могут рассматриваться в контексте исследования проблемы безопасности программ и рассматриваются ниже.

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

8.3.2. Общее описание модели Описание метода Нельсона приведем в соответствии с работой [ТЛН].

Для описания введем сначала следующие обозначения.

Совокупность действий, включающая ввод Ei, выполнение программы П, которое заканчивается получением результата F'(Ei) называется прогоном программы П. Необходимо также отметить, что значения входных переменных, образующие Ei, не должны все одновременно подаваться на вход программ П. Таким образом, вероятность P того, что прогон программы приведет к обнаружению дефекта, равна вероятности того, что набор данных Ei, используемый в данном прогоне, принадлежит множеству Ee. Если обозначить через ne число различных наборов значений входных данных, содержащихся в Ee, то P=ne/N - есть вероятность того, что прогон программы на наборе входных данных Ei, случайно выбранном из E среди равновероятных, закончится обнаружением дефекта. При этом R=1-P - есть вероятность того, что прогон программы П на наборе входных данных Ei, случайно выбранном из E среди априорно равновероятных, приведет к получению приемлемого результата.

Однако в процесс функционирования программы выбор входных данных из E обычно осуществляется не с одинаковыми априорными вероятностями, а диктуется определенными условиями работы. Эти условия характеризуются некоторым распределением вероятностей pi, того, что будет выбран набор входных данных Ei. Распределение P может быть определено через pi с помощью величины yi, которая принимает значение 0, если прогон программы на наборе Ei заканчивается вычислением приемлемого значения функции, и значением 1, если этот N P = pi yi - есть прогон заканчивается обнаружением дефекта. Поэтому i= вероятность того, что прогон программы на наборе входных данных Ei, выбранных случайно с распределением вероятностей pi, закончится обнаружением дефекта. При этом R=1-P есть вероятность того, что прогон программы П на наборе входных данных Ei, выбранных случайно с распределением вероятностей pi, приведет к получению приемлемого результата.

Так как R - вероятность того, что единичный прогон программы не закончится отказом на наборе входных данных, выбранных в соответствии с распределением рi, то вероятность успешного выполнения п прогонов этой программы при независимом для каждого прогона выборе входных данных в соответствии с распределением Р будет равна R(п)=R=(1-Р)n.

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

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

С учетом введенного определения функциональный разрез должен быть переопределен в терминах вероятностей pji выбора Ei в качестве входных данных при j-том прогоне из некоторой последовательности прогонов. Тогда вероятность того, что j-тый прогон закончится отказом, N p yi.

может быть записана в виде Pi= ji i= Надежность R(п) программы П равна вероятности того, что в последовательности из п прогонов ни один из них не закончится отказом:

n R(n)=(1-Pi)(1-P2)...(1-Pn)=(1 - Pj ) j= n j ln(1-P ) j = R(n) = e Эта формула может быть представлена в виде.

Некоторые из свойств функции R(n) могут стать более зримыми при следующих допущениях:

для Pj<< n j P j = R(n) = e, если Pj=P для всех j, то n e-P R(n)=.

С помощью соответствующих замен переменных и подстановок можно выразить функцию R(n) через время функционирования t.

j Обозначим через tj время выполнения j-того прогона, через t - i i= суммарное время выполнения первых j прогонов программы n примем, что n - h(t ) t j j ln(1 - Pj ) j = h(t ) = R(n) = e. Тогда.

j t j Если величина tj стремится к нулю с ростом n, то сумма в показателе экспоненты становится интегралом и формула для надежности программного обеспечения принимает вид Эта формула хорошо известна в теории надежности технических устройств. В случае Pj<<1 функция h(tj) может быть интерпретирована как функция интенсивности отказов, которая, будучи умноженной на tj, дает условную вероятность появления отказов и интервале (tj,tj+tj) при отсутствии отказов до момента tj.

8.3.3. Оценка надежности программного обеспечения Надежность машинной программы может быть оценена путем прогона программы на п наборах входных данных и расчета значения оценки R по формуле R=1-ne/n, где пе - число наборов входных данных, при которых произошли рабочие отказы.

Если выборка включает п наборов входных данных из Е и осуществляется в соответствии с распределением вероятностей рi, то расчетное значение R будет представлять собой несмещенную оценку надежности R в том смысле, что для рi<<1 ожидаемое значение на всем множестве наборов входных данных в пределах выборки равно R. Это может быть показано, если ввести характеристику выборки zij, которая определяется так, что zij=1, если Еi входит в выборку j и zij=0, в противном случае.

Число различных наборов входных данных nj, входящих в некоторую выборку j, может быть меньше, чем n, так как некоторые наборы Еi могут N быть включены в нее более одного раза. Поэтому z ji =nj.

i= Однако в большинстве случаев число возможных наборов входных данных N настолько больше размера выборки, что повторный выбор каких-либо наборов маловероятен. Если s - вероятность того, что взята M si = 1- (1- pi )n.

выборка j и M – количество возможных выборок, то zij i= N Так как R можно представить в виде R= (1- yi )zij, то n i= математическое ожидание R равно M M N N M 1 Ri = M(R)=s j s (1- yi )zij = (1- yi )s zij = j j n n i=1 j=1 i=1 i=1 j= N N n = )[1- (1- p ) ]=(1- yi ) pi.

(1- y i i n i= i = При р<<1 значение M(R)=1-Р=R.

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

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

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

на основании полученных данных может быть вычислена оценка надежности R.

Для дальнейшего рассмотрения нам будут необходимы следующие определения и обозначения, связывающие структурные характеристики программ с их безопасностью. Структурными характеристиками программы П являются множество ветвей Lj (j=1,...,n), подмножества входных наборов данных Gj, соответствующие ветвям Lj, множества сегментов Segj, из которых состоят отдельные ветви, совокупность операторов ветвления, которые обеспечивают переход от одного сегмента к другому при движении по отдельной ветви программы.

8.4. ОЦЕНКА ТЕХНОЛОГИЧЕСКОЙ БЕЗОПАСНОСТИ ПРОГРАММ НА БАЗЕ МЕТОДА НЕЛЬСОНА В данном разделе будем считать, что безопасность программного обеспечения - это вероятность того, что преднамеренные программные дефекты, вызывающие критическое поведение управляемой КС, будут обнаружены при определенных условиями внешней среды и в течение заданного периода наблюдения при испытаниях.

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

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

1. Определение множества E входных массивов.

2. Выделение в E подмножеств Gj, связанных с отдельными ветвями программы.

3. Определение для каждого Gj в предполагаемых условиях функционирования значений вероятности Pj.

4. Определение подмножества Gj для каждого входного набора данных, используемого в контрольных примерах.

5. Выявление проверенных пар и непроверенных в ходе испытаний сегментов и пар сегментов.

6. Определение для каждого j величины P'=ajPj, где aj определяется в соответствии со следующими правилами [ТЛН].

• aj=0,99, если подмножество Gj включает более одного контрольного примера;

• aj=0,95, если подмножество Gj включает ровно один контрольный пример;

• aj=0,90, если подмножество Gj не включает ни одного контрольного примера, но в процессе проверки программы были найдены все сегменты и все сегментные пары ветви Lj;

• aj=0,80, если в ходе испытаний были опробованы все сегменты, но не все сегментные пары;

• aj=0,80-0,20m, если m сегментов (1m4) ветви Lj не были опробованы в ходе испытаний;

• aj=0, если более чем 4 сегмента не были опробованы в процессе испытаний.

7. Вычисление грубой оценки R" осуществляется по формуле k R = Pi, где k представляет собой общее число ветвей j= программы.

Приведенные выше параметры aj были определены интуитивно [ТЛН] на основе анализа теоретических результатов исследования и экспериментальных результатов тестирования различных программ. Для того, чтобы получить более точные оценки величины R" необходимо провести измерения с использованием подходящего метода формирования выборки.

Оценка технологической безопасности ПО осуществляется посредством проверки условия R"S", где S" установленная нормативными документами граница безопасности ПО. Отметим также, что для систем критических приложений такая граница должна быть достаточно высокой, то есть стремится к 1.

ГЛАВА 9. ПОДХОДЫ К ЗАЩИТЕ РАЗРАБАТЫВАЕМЫХ ПРОГРАММ ОТ АВТОМАТИЧЕСКОЙ ГЕНЕРАЦИИ ИНСТРУМЕНТАЛЬНЫМИ СРЕДСТВАМИ ПРОГРАММНЫХ ЗАКЛАДОК 9.1. СПОСОБЫ ВНЕДРЕНИЯ РПС ПОСРЕДСТВОМ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ Современный этап развития технологии создания программных комплексов характеризуется ориентацией практически всех специализированных организаций на применение методов проблемно ориентированного программирования. При этом повышение качества программ основывается на использовании мощных инструментальных средств разработки и отладки программ. Использование для автоматизации процессов производства в области программотехники инструментальных средств автоматизации программирования значительно осложняет проблему выявления и устранения РПС. Это обусловлено тем, что программист практически не имеет возможности контролировать непосредственно создаваемые программы, так как работает на уровне логических конструкций языковых средств.

Если целью атаки является нанесение как можно большего вреда, то заманчивой целью для нарушителя, пытающегося внедрить РПС, являются программы, которые используют много различных пользователей, например, компиляторы [РПС]. Для того чтобы понять, как это можно сделать рассмотрим следующую упрощенную структуру компилятора, которая дает представление об общих принципах его работы:

compile:

get (line);

translate(line);

Согласно этой структуры компилятор сначала «получает строку», а затем транслирует ее. Конечно, настоящий компилятор устроен намного сложнее, чем эта схема, но этой иллюстрации отдано предпочтение потому, что она в виде некой модели разъясняет фазы лексического анализа трансляции компилятора. Целью РПС будет поиск новых текстовых участков во входных программах, которые будут транслироваться, и вставление в эти участки различного кода. В примере, представленном ниже, компилятор ищет текстовый участок «read_pwd(p)», наличие которого в функции входа в данную компьютерную систему известно, как мы предполагаем, нападающей программе. Когда этот участок будет найден, компилятор не будет транслировать «read_pwd(p)», а вместо этого буде транслировать вставку из РПС, которая может устанавливать «лазейку», которая потом позволит злоумышленнику легко получить доступ к системе. Измененный код компилятора следующий:

compile;

get (line) if line=«readpwd(p)» then translate (destructive means insertion);

else translate(line);

fi;

В этом измененном коде, компилятор получает строку, ищет нужный код текст, и если находит, то транслирует код РПС. Код РПС может включать в себя простую проверку пароля «черного входа» (например, может признаваться правильный пароль «12345» для любого пользователя). Это особенно опасно, поскольку код источника больше не отражает того, что находится в объектном коде и просмотр кода источника (не смотря на то, что проверяется и компилятор) никогда не позволит уловить эту атаку (см рис.9.1).

Заметим, что на рис.9.1 исходный текст или исполняемый код, включающий только те выражения, которые предлагались его разработчиком назван чистым, а код, содержащий РПС, - грязным. Далее заметим, что если компилируется атакованный компилятор и грязный исполняемый код устанавливается код в какой-либо рабочий каталог (так обычно и бывает), то компилятор с внедренным РПС может быть обнаружен, только если кто-нибудь вернется к источнику компилятора и проверит его (что редко случается). Но настоящий источник может быть восстановлен злоумышленником после компилирования грязного источника и создания грязного исполняемого компилятора. Это, вообще говоря, потом поможет восстановить настоящий исполняемый компилятор при рекомпиляции источника, но это редкий случай.

Более изощренный метод внедрения РПС заключается в реализации следующего алгоритма [То].

compile;

get (line) if line=«pattern_1» then translate (destructive means insertion_N1);

if line=«pattern_2» then translate (destructive means insertion_N2);

else translate(line);

fi;

Текст программы проверки пароля (чистый) Компилятор Компилятор (чистый) (с внесенном РПС, грязный) Исполняемая программа Исполняемая программа проверки пароля проверки пароля (чистая) (грязная) Рис.9.1. Работа компилятора с привнесенным РПС Сущность метода заключается в простом добавлении еще одного РПС к уже существующему. Второй образец настроен на сам компилятор.

Заменяющим текстом может служить самовоспроизводящаяся программа [То], которая вставляет оба РПС в компилятор. В этом случае необходима также фаза обучения. Сначала компилируется модифицированный исходный текст нормальным компилятором, когда получается готовая программа с РПС. Затем устанавливается эта готовая программа как официальный компилятор. Теперь можно удалить РПС из исходного текста компилятора, а новый компилятор будет воспроизводить РПС при каждой перекомпиляции. Команда login (например для ОС Unix), естественно, будет оставаться с РПС без всякого следа в каких-либо исходных текстах.

Таким образом, по мнению лауреата премии Тьюринга К. Томпсона [То]: «Нельзя доверять программе, которую вы не написали полностью сами. Сколько бы вы не исследовали и не верифицировали исходный текст - это не защитит вас от троянской программы. Для демонстрации атаки такого рода я выбрал компилятор Си. Я мог бы выбрать любую программу, обрабатывающую другие программы - ассемблер, загрузчик или даже микропрограмму, зашитую в аппаратуру.

Чем ниже уровень программы, тем труднее и труднее обнаруживать подобные «жучки». Мастерски встроенный «жучок» в микропрограмме будет почти невозможно обнаружить».

9.2. ВОЗМОЖНЫЕ МЕТОДЫ ЗАЩИТЫ ПРОГРАММ ОТ ПОТЕНЦИАЛЬНО ОПАСНЫХ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ Кроме трансляторов, компиляторов и интерпретаторов и целый ряд других инструментальных средств автоматизации программирования могут иметь встроенные средства автоматического генерирования программных закладок, которые включаются в текст производимой программы в ключевых местах, например, перед анализом условий прерывания, в блоках-переключателях, в блоках управления памятью и т.п.

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

Решение данной задачи может основываться на применении функциональных диаграмм [Гл,Ма], позволяющих строить тестовые последовательности по спецификации программной продукции. При этом спецификация исследуемых инструментальных средств разбивается на сегменты приемлемой сложности, в каждом из которых выделяются входные данные (команды инициализации операций) и события, представляющие собой реакцию программных средств на поступившую команду. Каждая команда может рассматриваться как отдельное входное условие или класс эквивалентности входных условий. Реакция программных средств наступает в виде следствия одного или нескольких входных условий. Для удобства анализа программных средств все команды и события получают уникальные номера, а связь команд с событиями определяется матрицей из нулей и единиц. На основании анализа семантики спецификаций инструментальных средств устанавливаются функциональные связи между командами и событиями, которые описываются булевыми функциями в базисе «И,ИЛИ,НЕ». В более сложных случаях могут использоваться расширения этого базиса за счет функций «И-НЕ», «ИЛИ-НЕ». Ограничения на возможные комбинации входных команд также задаются на основе анализа спецификаций.

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

Сущность метода заключается в предоставлении функциональной диаграммы в виде логической сети без обратных связей, а также использовании специально введенных операций «прямого продвижения» и «обратного продвижения», часто применяемых в технической диагностике [Н]. В данном случае в логической сети, задающей функциональную диаграмму, входные переменные соответствуют командам, а выходные - следствиям. Все логические элементы сети соответствуют функциональным связям. В дальнейшем для упрощения вместо термина «логическая сеть», задающая функциональную диаграмму, будет использоваться просто «функциональная диаграмма».

Для упорядочения операций с функциональными диаграммами вводится понятие ранга функциональных связей. Выходная функциональная связь (ФС) относится к рангу r=1. К рангу (i+1) относится ФС, выходы которых являются входами ФС ранга i. Ранжирование ФС завершается после определения рангов для всех связей. Необходимо отметить, что если в функциональной диаграмме выход некоторой ФС разветвляется, то может оказаться, что ФС, уже отнесенная к некоторому рангу, в соответствии с описанным правилом должна быть отнесена к другому, большему рангу. В этом случае ФС относится к большему рангу.

Максимальное значение ранга ФС называется рангом функциональной диаграммы.

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

Вырожденное покрытие (ВП) булевой функции представляет собой сжатую таблицу истинности данной функции. При этом вырожденное покрытие булевой функции f от n аргументов есть совокупность (n+1) разрядных строк, называемых кубами, в которых первые слева n разрядов представляют набор значений аргументов, а (n+1)-й разряд - значение булевой функции на этом наборе. В отличие от обычной таблицы истинности булевой функции, в которой аргументы принимают значения или 1, аргументы в ВП могут принимать значение x (неопределенное).

Если значение аргумента y равно х в некотором кубе ВП, то это значит, что значение булевой функции на наборах аргументов, задаваемых кубом, не зависит от значения y, т.е. y может принимать как значение 0 так и значение 1 и задавать поэтому две строки таблицы истинности булевой функции.

Функциональная диаграмма характеризуется вектором состояния P, размерность которого равна сумме числа ФС и числа входных условий.

Каждый разряд вектора P представляет значение либо команды, либо ФС и может принимать одно из 3-х значений: 0, 1 или х. Считается, что значение разряда вектора P определено, если в нем записан 0 или 1.

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

• алгоритм построения вырожденного покрытия функциональной диаграммы (алгоритм А);

• алгоритм определения множества комбинаций входных команд для заданной совокупности событий (алгоритм Б);

• алгоритм вычисления эталонных значений событий для заданных тестовых наборов команд (алгоритм В).

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

1. Любым известным методом [Н] находится минимальная дизъюнктивная нормальная форма (МДНФ) функции f и ее отрицания.

2. Находятся кубы ВП, соответствующие значениям f=1. Для этого каждый простой импликанте ставится в соответствие куб, значения разрядов которого формируются по следующим правилам:

2.1. Если переменная входит в импликанту без отрицания, то в кубе, в котором f=1, ей соответствует 1, если же переменная входит с отрицанием, то значение 0;

2.2. Если переменная не входит в импликанту, то в кубе ей соответствует х.

3. Находятся кубы ВП, соответствующие значениям f=0. Для этого к МДНФ отрицания функции f применяют правила, определенные пунктом 2 алгоритма А.

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

Таблица 9. Функции И ИЛИ НЕ y1 y2 f y1 y2 f y f 0 x 0 1 x 1 0 x 0 0 x 1 1 1 1 1 1 0 0 0 - Вырожденное покрытие функциональной диаграммы строится по следующей процедуре.

1. Функциональные связи, входящие в функциональную диаграмму, нумеруются по следующим правилам:

а) номера 1,...,а присваиваются входным командам в произвольном порядке;

б) номера а+t,...,b, t1 присваиваются функциональным связям так, что номер выходного условия ФС (события) всегда больше номера ее любого входного условия (команды).

2. Строится таблица, имеющая d столбцов (d - количество ФС).

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

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

На комбинацию событий может быть наложено ограничение M(y1,y2), запрещающее одновременное равенство единице y1 и y2.

Продвижение от событий к командам в соответствии с вектором Р заключается в выполнении алгоритма Б. Исходными данными при этом являются: вектор состояния функциональной диаграммы (совокупность значений реакций исследуемых инструментальных средств на входные команды) и вырожденное покрытие функциональной диаграммы.

Алгоритм Б 1. Начальная установка номера шага j:=0.

2. Из вектора Рj состояния ФД выбирается ФС Sh с наибольшем номером, ранее не рассматривавшаяся, значение которой в Рj определено (0 или 1).

3. Если Sh есть входное условие ФД, то алгоритм завершается, т.е. значения входных условий, определенных в Рj, являются искомыми.

В противном случае выполняется п.4.

4. Из таблицы вырожденных покрытий ФС выбираются кубы Kh(1),...,Kh(k), в которых значения ФС совпадают со значениями, определенными в Рj, а значения входных условий ФС не противоречат их значениям в Рj. Противоречие имеет место тогда и только тогда, когда значение входного условия в кубе Kn(i) равно 0(1), а в Рj противоположное - 1(0). Если h больше наименьшего номера ФС, значение которого определено в Рj, но из вырожденного покрытия ФС Sh нельзя выбрать ни одного куба, удовлетворяющего указанным условиям, то Рj не реализуем, т.е.

не существует комбинации входных условий, при которой значение следствий соответствует Рj.

5. Находится множество векторов Pj(1),...,Pj+1(k) за счет поразрядного пересечения расширенных кубов Kh(1),...,Kh(k) вырожденного покрытия Sh с вектором Рj: Pj+1(i) =PjP{Kh(i)}, i=1,...,k, причем операция П выполняется по следующим правилам: выбранные кубы расширяются за счет присвоения всем неопределенным ФС значения х, 1П1=1, 0П0=0, 1Пх=1, 0Пх=хП0=0, 1П0=0П1=d.

6. j:=j+1;

пункты 2-5 выполняются для каждого из найденных векторов Pg(i), i=1,...,k.

В результате работы этого алгоритма заполняются соответствующие строки таблицы решений [Го]. Для получения полной таблицы решений необходимо выполнить алгоритм для всех комбинаций событий, включаемых в таблицу 9.1.

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

• Е(x1,...,xn) - запрещены комбинации входных условий, в которых более одной переменной равны 1;

• I(x1,...,xn) - запрещена комбинация входных условий, в которых все xi=0;

• О(х1,х2) - одно и только одно из значений х1 и х2 должно иметь место, т.е. запрещены комбинации (х1=1, х2=1) или (х1=0, х2=0);

• R(x1,x2) - запрещена комбинация (х1=0, х2=0).

Возможны комбинации ограничений, например, Е(x1,...,xn) и R(xi,xj), (i,j)=1,...,n. В общем случае ограничение может быть задано указанием произвольного множества запрещенных комбинаций команд (входных условий). Учет ограничений может быть осуществлен следующими способами.

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

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

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

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

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

Задача, решаемая данным алгоритмом, формируется следующим образом.

Дано:

• вырожденное покрытие функциональной диаграммы инструментальных средств (или их относительно автономного участка), исследуемых на отсутствие блоков формирования программных закладок диверсионного типа;

• вектор Р(0) состояния функциональной диаграммы, соответствующий тестовому набору ХТ.

Требуется: найти для исследуемых средств значения реакций, соответствующие вектору Р(0).

Решение данной задачи осуществляется следующим образом.

Алгоритм В 1. Начальная установка номера шага алгоритма j:=1.

2. В векторе Рj-1 определяется функциональная связь Sg с минимальным номером, значение которой не определено, а хотя бы одно входное условие этой ФС имеет значение 0 или 1. Так как в соответствии с принятым правилом нумерации номер ФС всегда больше номера любого ее входного условия, то gV+j, где V - число входных условий ФС. Поэтому при выполнении этой операции следует анализировать значения ФС с номерами V+j,V+j+1,...,V+N-1, где N - число ФС.

3. Из вырожденного покрытия ФС Sg выбирается куб Khg, значения компонентов которого не противоречат значениям соответствующих компонентов вектора состояния Рj-1.

Противоречие отсутствует, если для всех компонентов куба Khg выполняются следующие условия:

3.1. Если в кубе компонент а имеет значение х, то в векторе Р(j-1) значение компонента а может быть 0, или х;

3.2. Если в кубе Khg компонент а имеет значение d, d=0,1, то и в векторе Рj-1 этот компонент должен иметь значение d.

4. Если не выбрано ни одного куба, то Рj=Рj-1 и осуществляется переход к п.6, в противном случае – к п.5.

5. Формируется вектор Рj состояния ФД, разряды которого образуются с помощью операций П поразрядного пересечения (см. п.5 алгоритма Б) компонентов выбранного куба Kgh с соответствующими компонентами вектора Рj-1 и заменой значений и этих компонентов результатами операции перечисления.

6. Если g

7. j:=j+1, переход к п.2.

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

ГЛАВА 10. МЕТОДЫ ИДЕНТИФИКАЦИИ ПРОГРАММ И ИХ ХАРАКТЕРИСТИК 10.1. ИДЕНТИФИКАЦИЯ ПРОГРАММ ПО ВНУТРЕННИМ ХАРАКТЕРИСТИКАМ Обеспечение безопасности программ, когда их исходные тексты попадают в руки злоумышленников, которые стремятся привнести в код программы РПС до того как программы подвергнутся компиляции может заключаться в использовании методов идентификации программ и их характеристик.

При установления степени подобия исходной и исследуемой программы целесообразнее всего выбрать критерий, который насколько это возможно, не зависит от маскировок, вносимых в исходный текст программ нарушителем. Для этого необходимо выбрать параметры, характеризующие собственно программу и связанные с такими ее свойствами, которые трудно изменить и которые сохраняются в машинном коде программы. К таким параметрам может относиться, например, распределение операторов по тексту программы [ЗПО], которое сложно изменить нарушителю, не искажая назначения программы. Такие изменения требуют глубокого понимания текста программы и логики вносимых изменений, что сопряжено с огромной работой по преобразованию программы.

Сначала рассмотрим вопросы анализа подобия последовательностей операторов в программе, поскольку этот подход не чувствителен к поверхностной маскировке, которую мог бы попытаться внести нарушитель, изменяя некоторые атрибуты программы, например, имена переменных, нумерацию строк и т.п. Для этого необходимо написать программу - анализатор, которая будет тестировать исследуемую программу и выделять операторы, накапливая их в файле как данные, отражающие порядок их использования. Введем для последовательности операторов программы с номером n обозначение seq n. Тогда последовательность операторов для программ 1 и 2 будет обозначаться seq1 и seq2 соответственно. Одна из характеристик последовательности операторов - частота появления отдельного оператора. Анализ последовательности операторов оказывается эффективным в тех случаях, когда нарушитель изменяет или перемещает отдельные части программы, добавляет дополнительные операторы или погружает скопированную программу в некоторый модуль. При таких манипуляциях значительные участки последовательности операторов сохраняются неизменными, так как попытка изменить их равносильна переписыванию программы с сопутствующей трудоемкой операцией отладки. Рассмотрим распределение частот появления операторов в программе. Если программа скопирована целиком, но при этом замаскирована, число появлений каждого оператора в копии будет аналогично числу появлений в оригинале. Нарушитель может изменить некоторые операторы и добавить новые, но в целом процент изменений в программе, вероятно, будет мал, и распределение частот появления операторов ожидается одинаковым как для копии, так и для оригинала.

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

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

10.2. СПОСОБЫ ОЦЕНКИ ПОДОБИЯ ЦЕЛЕВОЙ И ИССЛЕДУЕМОЙ ПРОГРАММ С ТОЧКИ ЗРЕНИЯ НАЛИЧИЯ ПРОГРАММНЫХ ДЕФЕКТОВ Частоту появления операторов в программе можно изобразить в виде гистограммы. Для этого достаточно написать подпрограмму, которая будет подсчитывать каждое появление операторов в последовательности зафиксированных операторов программы. На рис.10.1 приведена гистограмма операторов для информационно - поисковой системы (ИПС) [ЗПО];

на абсциссе графика отмечено количество возможных операторов интерпретатора языка, используемого в этих текстах. Было выявлено [ЗПО], что некоторые операторы очень часто встречаются в программах различного назначения, некоторые редко, а некоторые вообще не встречаются. Для сравнения на рис.10.2 приведена гистограмма для программы редактирования текстов (РТ), которая отличается от гистограммы на рис.10.1.

Частота появления операторов Рис. 10.1. Гистограмма частоты появления операторов в программе для поисково-информационной системы Повторяемость некоторых операторов делает степень подобия программ визуально видимой, особенно для программ с одинаковым функциональным назначением, поскольку целевая направленность часто определяет и выбор операторов. Глаз плохо различает относительные значения амплитуд на различных гистограммах, поэтому удобнее изображать частоту появления операторов в одной программе в зависимости от частоты появления в другой. В этом случае для программ одного вида подобия точки будут размещаться на биссектрисе первого квадранта под углом 45°. Если программы существенно различаются по частоте вхождения операторов в последовательности операторов, тогда точки будут иметь существенный разброс.

Частота 40 появления операторов Рис. 10.2. Гистограмма частоты появления операторов в программе для редакторов текстов Визуальное восприятие можно выразить математически, используя понятие корреляции. Простую меру оценки подобия можно получить, подсчитывая для каждого оператора с номером n среднее значение частоты его появления Dn в каждой программе. Математически эта мера подобия An для одного оператора записывается в виде Sn fn(1) + fn(2) An = - Dn = - fn(1) - fn(2), (10.1) где, - частоты появления оператора с номером n в программах 1 и fn(1) fn(2) соответственно;

Sn средняя сумма частот появления операторов с номером n в обеих программах;

Dn - разность между частотами появления оператора с номером n в программах 1 и 2.

Мера для всей последовательности операторов получается путем суммирования по всем операторам и нормировки (чтобы снять зависимость от длины программы, сумму делят на полное число операторов в обеих программах). Такая мера подобия A(1,2) для программ 1 и 2 имеет вид:

N Sn - 2Dn n=, (10.2) A(1,2) = N Sn n= где N - число операторов в языке.

Если частота появления операторов в обеих программах одинакова, мера подобия A(1,2)=1, если операторы, присутствующие в программах, образуют пересекающие множества A(1,2)=-1. Для рассмотренных последовательностей операторов мера подобия равна A(ИПС,РТ)=-0,8.

Статистическая формула для корреляции имеет вид:

N (1) (2) ( fn(1) - f )( fn(2) - f ), n= C(1,2)= 1/ N N (1) (2) ( fn(1) - f )2 ( fn(2) - f ) n=1 n= (1) (2) f f где, - средние значения частот появления всех операторов в программах 1 и 2 соответственно.

Значения коэффициентов корреляции, вычисленных по формуле (10.2) всегда находятся в пределах от 0 до 1. Если программы имеют почти один и тот же вид подобия, то коэффициент корреляции близок к 1, в случае вычисления коэффициента корреляции для программ ИПС и РТ, коэффициент корреляции равен C(ИПС,РТ)=0,56.

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

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

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

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

Улучшенную корреляцию можно получить, если рассматривать группу элементов. Поэтому при поиске в некоторой последовательности операторов совпадающих элементов следует проверять, является следующий элемент совпадающим, и если это так, то совпадение фиксируется и этот процесс продолжается до окончания сравниваемой последовательности. Если последовательность имеет длину n, объем выборки, отнесенный к первому элементу, увеличивается с 1 до n.

Расчет корреляции (которая в данном случае называется взвешенной взаимной корреляцией) продолжается путем перехода к следующему (второму) элементу последовательности. В этом случае соответствующая выборка увеличивается с 2 до n-1.

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

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

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

ГЛАВА 11. МЕТОДЫ И СРЕДСТВА ЗАЩИТЫ ПРОГРАММ ОТ КОМПЬЮТЕРНЫХ ВИРУСОВ 11.1. ОБЩАЯ ХАРАКТЕРИСТИКА И КЛАССИФИКАЦИЯ КОМПЬЮТЕРНЫХ ВИРУСОВ Под компьютерным вирусом (или просто вирусом) понимается автономно функционирующая программа, обладающая способностью к самостоятельному внедрению в тела других программ и последующему самовоспроизведению и самораспространению в информационно вычислительных сетях и отдельных ЭВМ [Без,Бел,ЗМС,ФДК,Со].

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

Наиболее распространенной разновидностью троянских программ являются широко известные программы массового применения (редакторы, игры, трансляторы и т.д.), в которые встроены так называемые «логические бомбы», срабатывающие по наступлении некоторого события.

Следует отметить, что троянские программы не являются саморазмножающимися.

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

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

«Первичное» заражение происходит в процессе поступления инфицированных программ из памяти одной машины в память другой, причем в качестве средства перемещения этих программ могут использоваться как носители информации (дискеты, CD-ROM, CD-RW, флэш-память и т.п.), так и каналы вычислительных сетей. Вирусы, использующие для размножения сетевые средства, принято называть сетевыми.

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

Физическая структура компьютерного вируса достаточно проста. Он состоит из головы и, возможно, хвоста. Под головой вируса понимается его компонента, получающая управление первой. Хвост - это часть вируса, расположенная в тексте зараженной программы отдельно от головы.

Вирусы, состоящие из одной головы, называют несегментированными, тогда как вирусы, содержащие голову и хвост - сегментированными.

Наиболее существенные признаки компьютерных вирусов позволяют провести следующую их классификацию.

I. По режиму функционирования:

• резидентные вирусы - вирусы, которые после активизации постоянно находятся в оперативной памяти компьютера и контролируют доступ к его ресурсам;

• транзитные вирусы - вирусы, которые выполняются только в момент запуска зараженной программы.

II. По объекту внедрения:

• файловые вирусы - вирусы, заражающие файлы с программами;

• загрузочные (бутовые) вирусы - вирусы, заражающие программы, хранящиеся в системных областях дисков.

В свою очередь файловые вирусы подразделяются на вирусы, заражающие:

• исполняемые файлы;

• командные файлы и файлы конфигурации;

• составляемые на макроязыках программирования, или файлы, содержащие макросы (макровирусы);

• файлы с драйверами устройств;

• файлы с библиотеками исходных, объектных, загрузочных и оверлейных модулей, библиотеками динамической компоновки и т.п.

Загрузочные вирусы подразделяются на вирусы, заражающие:

• системный загрузчик, расположенный в загрузочном секторе дискет и логических дисков;

• внесистемный загрузчик, расположенный в загрузочном секторе жестких дисков.

III. По степени и способу маскировки:

• вирусы, не использующие средств маскировки;

• stealth-вирусы - вирусы, пытающиеся быть невидимыми на основе контроля доступа к зараженным элементам данных;

• вирусы-мутанты (MtE-вирусы) - вирусы, содержащие в себе алгоритмы шифрования, обеспечивающие различие разных копий вируса.

В свою очередь, MtE-вирусы делятся на • обычные вирусы-мутанты, в разных копиях которых различаются только зашифрованные тела, а дешифрованные тела вирусов совпадают;

• полиморфные вирусы, в разных копиях которых различаются не только зашифрованные тела, но и их дешифрованные тела.

Наиболее распространенные типы вирусов характеризуются следующими основными особенностями.

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

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

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

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

Отличительной особенностью последних является инфицирование загрузочного сектора (бут-сектора) магнитного носителя. Голова бутового вируса всегда находится в бут-секторе (единственном для гибких дисков и одном из двух - для жестких), а хвост - в любой другой области носителя.

Наиболее безопасным для вируса способом считается размещение хвоста в так называемых псевдосбойных кластерах, логически исключенных из числа доступных для использования. Существенно, что хвост бутового вируса всегда содержит копию оригинального (исходного) бут-сектора.

Механизм инфицирования, реализуемый бутовыми вирусами, например, при загрузке MS DOS, таков. При загрузке операционной системы с инфицированного диска вирус, в силу своего положения на нем (независимо от того, с дискеты или с винчестера производится загрузка), получает управление и копирует себя в оперативную память. Затем он модифицирует вектор прерываний таким образом, чтобы прерывание по обращению к диску обрабатывались собственным обработчиком прерываний вируса, и запускает загрузчик операционной системы.

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

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

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

Макровирусы распространяются под управлением прикладных программ, что делает их независимыми от операционной системы.

Подавляющее число макровирусов функционируют под управлением системы Microsoft Word for Windows. В то же время, известны макровирусы, работающие под управлением таких приложений как Microsoft Word for Windows, Microsoft Exel for Windows, Lotus Ami Pro, Lotus 1-2-3, Lotus Notes, в операционных системах фирм Microsoft и Apple [Бел].

Сетевые вирусы, называемые также автономными репликативными программами, или, для краткости, репликаторами, используют для размножения средства сетевых операционных систем. Наиболее просто реализуется размножение в тех случаях, когда сетевыми протоколами предусмотрен обмен программами. Однако, размножение возможно и в тех случаях, когда указанные протоколы ориентированы только на обмен сообщениями. Классическим примером реализации процесса размножения с использованием только стандартных средств электронной почты является уже упоминаемый репликатор Морриса [ФДК]. Текст репликатора передается от одной ЭВМ к другой как обычное сообщение, постепенно заполняющее буфер, выделенный в оперативной памяти ЭВМ адресата. В результате переполнения буфера, инициированного передачей, адрес возврата в программу, вызвавшую программу приема сообщения, замещается на адрес самого буфера, где к моменту возврата уже находится текст вируса.

Тем самым вирус получает управление и начинает функционировать на ЭВМ-адресате.

«Лазейки», подобные описанной выше и обусловленные особенностями реализации тех или иных функций в программном обеспечении, являются объективной предпосылкой для создания и внедрения репликаторов злоумышленниками. Эффекты, вызываемые вирусами в процессе реализации ими целевых функций, принято делить на следующие группы:

• искажение информации в файлах, либо в таблице размещения файлов (FAT-таблице), которое может привести к разрушению файловой системы в целом;

• имитация сбоев аппаратных средств;

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

• инициирование ошибок в программах пользователей или операционной системе.

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

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

11.2. ОБЩАЯ ХАРАКТЕРИСТИКА СРЕДСТВ НЕЙТРАЛИЗАЦИИ КОМПЬЮТЕРНЫХ ВИРУСОВ Наиболее распространенным средством нейтрализации компьютерных вирусов являются антивирусные программы (антивирусы).

Антивирусы, исходя из реализованного в них подхода к выявлению и нейтрализации вирусов, принято делить на следующие группы:

• детекторы;

• фаги;

• вакцины;

• прививки;

• ревизоры;

• мониторы.

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

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

Фаги выполняют функции, свойственные детекторам, но, кроме того, «излечивают» инфицированные программы посредством «выкусывания» вирусов из их тел. По аналогии с полидетекторами, фаги, ориентированные на нейтрализацию различных вирусов, именуют полифагами.

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

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

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

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

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

Антивирусы рассмотренных типов существенно повышают вирусозащищенность отдельных ПЭВМ и вычислительных сетей в целом, однако, в связи со свойственными им ограничениями, естественно, не являются панацеей. В работе [СМ] приведены основные недостатки при использовании антивирусов.

В связи с этим необходима реализация альтернативных подходов к нейтрализации вирусов: создание операционных систем, обладающих высокой вирусозащищенностью по сравнению с наиболее «вирусодружественной» MS DOS, MS Windows, разработка аппаратных средств защиты от вирусов и соблюдение технологии защиты от вирусов.

11.3. КЛАССИФИКАЦИЯ МЕТОДОВ ЗАЩИТЫ ОТ КОМПЬЮТЕРНЫХ ВИРУСОВ Проблему защиты от вирусов необходимо рассматривать в общем контексте проблемы защиты информации от несанкционированного доступа и технологической и эксплуатационной безопасности ПО в целом.

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

• регламентацию проведения работ на ПЭВМ;

• применение программных средств защиты;

• использование специальных аппаратных средств защиты.

При этом количество уровней защиты зависит от ценности информации, которая обрабатывается на ПЭВМ.

Для защиты от компьютерных вирусов в настоящее время используются следующие методы.

Архивирование. Заключается в копировании системных областей магнитных дисков и ежедневном ведении архивов измененных файлов.

Архивирование является одним из основных методов защиты от вирусов.

Остальные методы защиты дополняют его, но не могут заменить полностью.

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

Набор детекторов достаточно широк, и постоянно пополняется по мере появления новых вирусов. Однако при этом могут быть обнаружены не все вирусы, а только распознаваемые детектором. Следующим элементом входного контроля является контекстный поиск в файлах слов и сообщений, которые могут принадлежать вирусу (например, Virus, COMMAND.COM, Kill и т.д.). Подозрительным является отсутствие в последних 2-3 килобайтах файла текстовых строк - это может быть признаком вируса, который шифрует свое тело.

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

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

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

Ревизия. Анализ вновь полученных программ специальными средствами (детекторами), контроль целостности перед считыванием информации, а также периодический контроль состояния системных файлов.

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

Сегментация. Предполагает разбиение магнитного диска на ряд логических томов (разделов), часть из которых имеет статус READ_ONLY (только чтение). В данных разделах хранятся выполняемые программы и системные файлы. Базы данных должны храниться в других секторах, отдельно от выполняемых программ. Важным профилактическим средством в борьбе с файловыми вирусами является исключение значительной части загрузочных модулей из сферы их досягаемости. Этот метод называется сегментацией и основан на разделении магнитного диска (винчестера) с помощью специального драйвера, обеспечивающего присвоение отдельным логическим томам атрибута READ_ONLY (только чтение), а также поддерживающего схемы парольного доступа. При этом в защищенные от записи разделы диска помещаются исполняемые программы и системные утилиты, а также системы управления базами данных и трансляторы, т.е. компоненты ПО, наиболее подверженные опасности заражения. В качестве такого драйвера целесообразно использовать программы типа ADVANCED DISK MANAGER (программа для форматирования и подготовки жесткого диска), которая не только позволяет разбить диск на разделы, но и организовать доступ к ним с помощью паролей. Количество используемых логических томов и их размеры зависят от решаемых задач и объема винчестера. Рекомендуется использовать 3 - 4 логических тома, причем на системном диске, с которого выполняется загрузка, следует оставить минимальное количество файлов (системные файлы, командный процессор, а также программы - ловушки).

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

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

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

Терапия. Предполагает дезактивацию конкретного вируса в зараженных программах специальными программами (фагами).

Программы-фаги «выкусывают» вирус из зараженной программы и пытаются восстановить ее код в исходное состояние (состояние до момента заражения). В общем случае технологическая схема защиты может состоять из следующих этапов:

• входной контроль новых программ;

• сегментация информации на магнитном диске;

• защита операционной системы от заражения;

• систематический контроль целостности информации.

Необходимо отметить, что не следует стремиться обеспечить глобальную защиту всех файлов, имеющихся на диске. Это существенно затрудняет работу, снижает производительность системы и, в конечном счете, ухудшает защиту из-за частой работы в открытом режиме. Анализ показывает, что только 20-30% файлов должно быть защищено от записи.

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

Кроме того, для защиты операционной системы может применяться нестандартный командный процессор (например, командный процессор 4DOS, разработанный фирмой J.P.Software), который более устойчив к заражению. Размещение рабочей копии командного процессора на виртуальном диске позволяет использовать его в качестве программы ловушки. Для этого может использоваться специальная программа, которая периодически контролирует целостность командного процессора, и информирует о ее нарушении. Это позволяет организовать раннее обнаружение факта вирусной атаки.

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

Из них следует отметить DR DOS и Hi DOS. Любая из этих систем более «вирусоустойчива», чем MS DOS. При этом, чем сложнее и опаснее вирус, тем меньше вероятность, что он будет работать на альтернативной операционной системе.

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

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

• Семейство (батарея) детекторов. Детекторы, включенные в семейство, должны запускаться из операционной среды комплекса.

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

• Программа-ловушка вирусов. Данная программа порождается в процессе функционирования комплекса, т.е. не хранится на диске, поэтому оригинал не может быть заражен. В процессе тестирования ПЭВМ программа - ловушка неоднократно выполняется, изменяя при этом текущую дату и время (организует ускоренный календарь). Наряду с этим программа-ловушка при каждом запуске контролирует свою целостность (размер, контрольную сумму, дату и время создания). В случае обнаружения заражения программный комплекс переходит в режим анализа зараженной программы - ловушки и пытается определить тип вируса.

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

Используя это свойство возможно создание программы, которая обрабатывала бы файлы таким образом, чтобы вирус считал, что они уже заражены.

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

• Резидентные средства защиты. Эти средства могут резидентно разместиться в памяти и постоянно контролировать целостность системных файлов и командного процессора. Проверка может выполняться по прерываниям от таймера или при выполнении операций чтения и записи в файл.

ГЛАВА 12. МЕТОДЫ ЗАЩИТЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ОТ ИССЛЕДОВАНИЯ 12.1. КЛАССИФИКАЦИЯ СРЕДСТВ ИССЛЕДОВАНИЯ ПРОГРАММ 12.1.1. Вводная часть В этом подразделе мы будем исходить из предположения, что на этапе разработки программная закладка была обнаружена и устранена, либо ее вообще не было. Для привнесения программных закладок, например в этом случае необходимо взять готовый исполняемый модуль, дизассемблировать его и после внесения закладки подвергнуть повторной компиляции. Другой способ заключается в незаконном получении текстов исходных программ, их анализе, внесении программных дефектов и дальнейшей замене оригинальных программ на программы с приобретенными закладками. И, наконец, может осуществляться полная замена прикладной исполняемой программы на исполняемую программу нарушителя, что впрочем, требует от последнего необходимость иметь точные и полные знания целевого назначения и конечных результатов прикладной программы.

Все средства исследования ПО можно разбить на 2 класса:

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

Два наиболее известных типа программ, предназначенных для исследования ПО, как раз и относятся к разным классам: это отладчик (динамическое средство) и дизассемблер (средство статистического исследования). Если первый широко применяется пользователем для отладки собственных программ и задачи построения алгоритма для него вторичны и реализуются самим пользователем, то второй предназначен исключительно для их решения и формирует на выходе ассемблерный текст алгоритма.

Помимо этих двух основных инструментов исследования, можно использовать:

• «дискомпиляторы», программы, генерирующие из исполняемого кода программу на языке высокого уровня;

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

• «следящие системы», запоминающие и анализирующие трассу уже не инструкции, а других характеристик, например вызванных программой прерываний.

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

В первом случае защита может быть основана на шифровании конфиденциальной части программы, а во втором - на блокировании доступа к исполняемому коду программы в оперативной памяти со стороны отладчиков [ЗШ]. Кроме того, перед завершением работы защищаемой программы должен обнуляться весь ее код в оперативной памяти. Это предотвратит возможность несанкционированного копирования из оперативной памяти дешифрованного исполняемого кода после выполнения защищаемой программы.

Таким образом, защищаемая от исследования программа должна включать следующие компоненты:

• инициализатор;

• зашифрованную конфиденциальную часть;

• деструктор (деициниализатор).

Инициализатор должен обеспечивать выполнение следующих функций:

• сохранение параметров операционной среды функционирования (векторов прерываний, содержимого регистров процессора и т.д.);

• запрет всех внутренних и внешних прерываний, обработка которых не может быть запротоколирована в защищаемой программе;

• загрузка в оперативную память и дешифрование кода конфиденциальной части программы;

• передача управления конфиденциальной части программы.

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

Деструктор после выполнения конфиденциальной части программы должен выполнить следующие действия:

• обнуление конфиденциального кода программы в оперативной памяти;

• восстановление параметров операционной системы (векторов прерываний, содержимого регистров процессора и т.д.), которые были установлены до запрета неконтролируемых прерываний;

• выполнение операций, которые невозможно было выполнить при запрете неконтролируемых прерываний;

• освобождение всех незадействованных ресурсов компьютера и завершение работы программы.

Для большей надежности инициализатор может быть частично зашифрован и по мере выполнения может дешифровать сам себя.

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

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

• периодический подсчет контрольной суммы области оперативной памяти, занимаемой защищаемым исходным кодом;

сравнение текущей контрольной суммы с предварительно сформированной эталонной и принятие необходимых мер в случае несовпадения;

• проверку количества занимаемой защищаемой программой оперативной памяти;

• сравнение с объемом, к которому программа адаптирована, и принятие необходимых мер в случае несоответствия;

• контроль времени выполнения отдельных частей программы;

• блокировку клавиатуры на время отработки особо критичных алгоритмов.

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

12.1.3. Анализ программ на этапе их эксплуатации В данном разделе будут рассмотрены методы исследования программ нарушителем с помощью дизассемблеров и отладчиков на этапе эксплуатации программ с целью внесения в них РПС. То есть задача защиты в отличие от задач защиты, рассмотренных в предыдущем подразделе, здесь решается «с точностью до наоборот». Этот подраздел необходим для понимания процесса исследования программ, но не специалистами в области защиты ПО (см. главу 7), которые пытаются обнаружить и устранить программные дефекты, а потенциальными нарушителями, которые пытаются внести в исследуемую программу РПС.

Т.е. цель, объекты и субъекты обеспечения безопасности ПО здесь разные.

Основная схема анализа нарушителем исполняемого кода, в данном случае, может состоять из следующих этапов [ПБП]:

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

• лексический анализ;

• дизассемблирование;

• семантический анализ;

• перевод в форму, удобную для следующего этапа (в том числе и перевод на язык высокого уровня);

• синтаксический анализ.

После снятия нарушителем защиты осуществляется поиск сигнатур (лексем) РПС. Примеры сигнатур РПС приведены в работе [ПБП].

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

www.kiev-security.org.ua BEST rus DOC FOR FULL SECURITY При синтаксическом анализе могут встретиться следующие трудности (хотя - это проблема нарушителя):

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

• порядок следования лексем может быть известен с некоторой вероятностью или вообще не известен;

• грамматика языка может пополняться, так как могут возникать новые типы РПС или механизмы их работы.

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

Так как семантический анализ удобнее вести на языке высокого уровня далее проводится этап перевода ассемблерного текста в текст на языке более высокого уровня, например, на специализированном языке макроассемблера, который нацелен на выделение макроконструкций, используемых в РПС.

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

12.2. СПОСОБЫ ЗАЩИТЫ ПРОГРАММ ОТ ИССЛЕДОВАНИЯ Способы защиты от исследования можно разделить на четыре класса [ПАС].

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

• использование аппаратных особенностей микропроцессора (особенности очередности выборки команд, особенности выполнения команд и т.д.);

• использование общего программного ресурса (например, общего стека) и разрушение данных или кода отладчика, принадлежащих общему ресурсу, либо проверка использования общего ресурса только защищаемой программой (например, определение стека в области, критичной для выполнения защищаемой программы);

• переадресация обработчиков отладочных событий (прерываний) от отладочного средства к защищаемой программе.

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

2. Влияние на работу отладочного средства путем использован~ особенностей его аппаратной или программной среды. Например:

• перемещения фрагментов кода или данных с помощью контроллер прямого доступа к памяти;

• влияния на процесс регенерации оперативной памяти (на некотором участке кода регенерация памяти отключается, а затем опять включается, - при нормальной работе никаких изменений нет, при медленном выполнении программы отладчиком она «зависает»);

• перехода микропроцессора в защищенный режим.

3. Влияние на работу отладчика через органы управления или/и устройства отображения информации.

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

4. Использование принципиальных особенностей работы управляемого человеком отладчика. В данном случае защита от исследования состоит в навязывании для анализа избыточно большого объема кода (как правило, за счет циклического исполнения некоторого его участка).

Рассмотрим данный метод подробнее. Пусть имеется некоторое полноцикловое преобразование из N состояний t: Т=t1,t2,...,tN (Например, обычный двоичный счетчик либо, рекуррента). Значение N выбирается не слишком большим. Например, для k-битового счетчика N=2k. Участок кода, защищаемый от изучения, динамически преобразуется (шифруется) с использованием криптографически стойкого алгоритма на ключе t, который выбирается случайно и равновероятно из множества состояний Т.

Работа механизма защиты от исследования выглядит следующим образом. Программа полноциклового преобразования начинает работу с детерминированного или случайного значения. На установленном значении производится дешифрование зашифрованного участка кода.

Правильность дешифрования проверяется подсчетом значения хэш-кода расшифрованного участка программного кода с использованием элементов, связанных с отладкой (стек, отладочные прерывания и др.).

Хэш-функция должна с вероятностью 1 определять правильность дешифрования (для этого значение хэш-кода должно быть не менее k).

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

Для численной оценки данного метода введем следующие значения.

Предположим, что i в среднем равно N/2. Пусть w0 - время выполнения цикла алгоритма (установка текущего значения, дешифрование, проверка правильности дешифрования) в штатном режиме функционирования (без отладки);

w1 - время выполнения того же цикла в режиме отладки;

z — предельное время задержки при штатной работе защищенной программы.

Тогда N=z/w0. Затраты времени злоумышленника исчисляются средней величиной Тзл=Nw1/2. Для приблизительных расчетов w1/w010000.

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

Способ динамического преобразования заключается в следующем:

первоначально в оперативную память загружается фрагмент кода, содержание части команд которого не соответствует тем командам, которые данный фрагмент в действительности выполняет;

затем этот фрагмент по некоторому закону преобразуется, превращаясь в исполняемые команды, которые затем и выполняются.

Преобразование кода программы во время ее выполнения может преследовать три основные цели:

• противодействие файловому дизассемблированию программы;

• противодействие работе отладчику;

• противодействие считыванию кода программы в файл из оперативной памяти.

Перечислим основные способы организации преобразования кода программы [ПАС]:

1. Замещение фрагмента кода функцией от находящейся на данном месте команды и некоторых данных.

2. Определение стека в области кода и перемещение фрагментов кода с использованием стековых команд.

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

4. Преобразование кода в зависимости от (внешней к программе) информации.

5. Преобразование кода, совмещенное с действиями, характерными для работы отладочных средств.

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

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

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

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

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

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

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

1. Пассивная защита - запрещение работы при переопределении обработчиков событий относительно заранее известного адреса.

2. Активная защита первого типа - замыкание цепочек обработки событий минуя программы трассировки.

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

Например, для защиты от трассировки по дисковым прерываниям для ОС MS DOS при чтении некопируемой метки с дискеты или винчестера можно использовать следующие приемы:

• работа с ключевой меткой путем прямого программирования контроллера гибкого диска (активная защита второго типа);

• определение одного из неиспользуемых прерываний для работы с диском (активная защита первого типа);

• прямой вызов соответствующих функций в ПЗУ (BIOS) после восстановления различными способами их физического адреса (активная защита первого типа);

• определение факта переопределения адреса прерывания на другую программу и невыполнение в этом случае дисковых операций (пассивная защита).

При операциях с жестким диском, как правило, используется преры вание int 13h. Для предотвращения трассировки программы по заданному прерыванию (в данном случае прерыванию int 13h) можно также исполь зовать указанные выше способы, а именно:

• переопределение исходного прерывания в BIOS на неиспользуемый вектор прерывания;

• прямой вызов функций BIOS.

При опасности трассировки по событиям операционной среды могут быть выделены следующие действия программ:

• определение факта замены обработчиков событий на собственные функции (в частности, для защиты от отладчиков);

• файловые операции, связанные со считываниями различных счетчиков или паролей, вычисление контрольных сумм и значений хэш-кодов;

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

12.3. СПОСОБЫ ВСТРАИВАНИЯ ЗАЩИТНЫХ МЕХАНИЗМОВ В ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ Встраивание защитных механизмов можно выполнить следующими основными способами:

• вставкой фрагмента проверочного кода в исполняемый файл;

• преобразованием исполняемого файла к неисполняемому виду (шифрование, архивация с неизвестным параметром и т.д.) и применением для загрузки не средств операционной среды, а некоторой программы, в теле которой и осуществляются необходимые проверки;

• вставкой проверочного механизма в исходный код на этапе разработки и отладки программного продукта;

• комбинированием указанных методов.

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

• высокая трудоемкость обнаружения защитного фрагмента при статическом исследовании (особенно актуальна при встраивании в исходный код программного продукта);

• высокая трудоемкость обнаружения защитного фрагмента при динамическом исследовании (при отладке и трассировке по внешним событиям);

• высокая трудоемкость обхода или редуцирования защитного файла.

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

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

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

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

12.4. ОБФУСКАЦИЯ ПРОГРАММ 12.4.1. Вводные замечания В данном подразделе кратко затрагиваются вопросы, связанные с активно развивающимися теорией и практикой обфускации программ.

Неформально говоря, под обфускацией программ здесь понимается преобразование программ с целью максимального затруднения их анализа и модификации, при сохранении, в то же время, их функциональных возможностей. Известные на сегодня методы обфускации, как правило, носят эмпирический характер и слабо обоснованы теоретически. В работе [CTL] приведена классификация методов обфускации, а в работе [BGI] предпринята, скорее всего, первая попытка формализации и теоретического обоснования задачи обфускации программ.

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

Существование обфускаторов для этих приложений должно быть основано на формализации определения понятия «неясности» [BGI].

12.4.2. Теоретические основания Пусть обфускатор – это (эффективный, вероятностный) «компилятор», который по входу программы (схеме) P выдает новую программу О(P), удовлетворяющую следующим условиям:

1. Условие функциональности. Обфусктор O(P) должен вычислять ту же самую функцию, что и программа P.

2. Условие (свойство) «виртуального черного ящика». «Все, что может быть вычислено эффективным образом из обфускатора O(P), может быть эффективно вычислено при оракульном доступе к программе P».

Одна из интерпретаций определения, приведенного выше, неформально можно объяснить так, что: во-первых, должна сохраняться функциональная эквивалентность P и O(P) и, во-вторых, все что противник мог бы получить при доступе к обфусцирующей программе, он мог бы с таким же успехом получить при доступе к некоторому «черному ящику».

Основной результат работы [BGI] заключается в том, что даже при очень слабой формализации, полная обфускация программ является теоретически невозможной. Это доказывается посредством построения (посредством односторонних функций) семейства функций F, которые являются необфусцирующими в том смысле, что существует свойство :F{0,1} такое, что:

• по данной программе (схеме), которая вычисляет функцию fF, значение (f) может быть также эффективно вычислено;

• по данному оракульному доступу к (случайно выбранной) функции fF, никакой эффективный алгоритм не может вычислять (f) лучше, чем случайным угадыванием.

Pages:     | 1 |   ...   | 3 | 4 || 6 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.