CC BY
16А.В.Дьякова
кандидат технических наук, доцент
A.A. Бойко
кандидат технических наук, доцент
Р. С. Яковлев
кандидат технических наук, доцент
НИИЦ РЭБ ВУНЦ ВВС «ВВАим. проф. Н.ЕЖуковского и Ю.А. Гагарина» (г. Воронеж)
АЛГОРИТМ ВСКРЫТИЯ УЯЗВИМОСТЕЙ ДЛЯ КОМПЬЮТЕРНЫХ АТАК В ИНФОРМАЦИОННО-ТЕХНИЧЕСКИХ СРЕДСТВАХ
Предложен алгоритм вскрытия уязвимостей для компьютерных атак (КА) в информационно-технических средствах (ИТС), основанный на использовании автоматизированного метода формальной верификации программного обеспечения (ПО) MODEL CHECKING.
Введение
Сегодня не вызывает сомнения тот факт, что в современных ИТС математическое и реализующее его программное обеспечение обретает все большие объем и сложность, что приводит к лавинообразному увеличению количества ошибок. Ошибки приводят к возникновению уязвимостей, которые могут быть вскрыты и использованы злоумышленником для реализации КА. В таких обстоятельствах очевидна закономерность: чем больше достоверной информации об уязвимостях будет в арсенале разработчика и заказчика на этапе проведения предварительных, приемо-сдаточных (государственных), сравнительных и аттестационных испытаний ИТС, тем более эффективным будет их применение по назначению. Однако, как показывает практика, существующий подход к вскрытию в ИТС уязвимостей и последующей разработке тестовых алгоритмов КА состоит в проверке на наличие наиболее часто встречающихся «шаблонных» уязвимостей (уязвимости при использовании временных файлов, переполнение буфера, переменных, форматной строки, уязвимости, предоставляющие остаточную информацию в оперативной памяти, использующие нарушение синхронизации про-
граммных процессов, использующие библиотечные функции, ХББ-уязвимости, БОЬ-уязвимости), а также в поиске экспертом единичных применимых только в специфических условиях КА, способных каким-либо образом нарушить штатный режим функционирования целевого ИТС.
Такой подход не универсален, т.к. не позволяет на основании теоретического обоснования синтезировать наиболее полное для имеющегося объема информации множество тестовых алгоритмов КАна ИТС, из которых для различных условий эксплуатации данных средств возможно выбрать оптимальные и тем самым существенно повысить достоверность оценки их функциональной стабильности. Исходя из этого, задача разработки подхода, позволяющего учитывать недостатки традиционного, является актуальной. В настоящей статье рассматривается алгоритм, который может быть использован в качестве базиса для нового подхода вскрытия уязвимостей для КА в ИТС.
Основная часть
В алгоритме вскрытия уязвимостей для КА в ИТС предлагается использовать автоматизированный метод формальной верификации ПО
MODEL CHECKING [1,2]. Верификацию предлагается осуществлять с помощью программного средства SPIN (Simple Promela Interpreter) [3], входным языком описания которого является Promela.
Пусть дан фрагмент ПО исследуемого ИТС, представленный на рис. 1 [4]. В этом фрагменте описывается функция, реализующая бесконечный цикл взаимодействия с ядром (посылает сообщения и принимает их от него).
Рассмотрим применение предлагаемого алгоритма вскрытия уязвимостей для КА в ИТС на примере данного фрагмента.
На шаге 1 задаем требования (спецификацию) к функции. В частности, проверяем выполнимость следующих требований:
1) всегда при вызове sys_irqenable() верно DspVersion[0] < 4;
2) тупики отсутствуют;
3) недостижимый код отсутствует;
4) циклы бездействия, за исключением цикла, связанного с бесконечным выполнением моделируемой функции, отсутствиуют.
На шаге 2 строим модель функции. На языке Promela модель будет выглядеть следующим образом (рис. 2).
На шаге 3 формулируем (при необходимости) и проверяем каждое требование спецификации. Требования 2-4 проверяются в SPIN внутренними командами (включением/отключением специальных флагов). Для проверки требования 1 его необходимо выразить на языке LTL (Linear Time Logic).
В ходе шага 4 анализируем результаты верификации. При проверке требования 1 получили контрпример, который сохранился в файле model assert.prm (рис. 3).
PRIVATE int DspVersion[2]; PRIVATE int dspinit() t
int i, s;
if(dsp reset (} != OK) {
dprint ("sbl(5: No SoundBlaster card detected\n"); return -1;
f
DspVersion[0] = DspVersion[1] = 0;
dap command(DSP_GET_VERSION); /* Get DSP version bytes */ for(i = 1000; i; i —} {
if <sbl6__inb(DSP_DATAJWL> & 0x80) \ if<Dspversion[0] = 0) i
DspVersion[0] = sbl6_inb(DSP_READ);
} else {
DspVersion[1] = sbl6_inb(DSP_READ); break;
f
]
Y
if(DspVersion[0] < 4) i
dprint("sbl6: No SoundBlaster 16 compatible card detected\n"); return -if
}
dprint ("sbl6: SoundBlaster DSP version %d.%d detected\n", DspVersion[0] DspVersion[1]);
/* set SB to use our IRQ and DMA channels */ mixer_set(MIXER_SET_IRQ, (1 « (SE_IRQ / 2 - I))>; mixer_set(MIXER_SET_DMA, (1 « SB_DMA_8 I 1 « S3_DMA_16)); /* register interrupt vector and enable irq */
if ( (s=sys_irqsetpolicy(SB_IRQ, IRQ_RE ENABLE, Sirq_hook_id )) != OK)
panic ("SB16DSP", "Couldn't set IRQ policy",' s);" if ((s=sys_irqenable(&irq_hook_id)) != OK)
panic("SB16DSP", "Couldn't enable IRQ", s); DspAvail - 1; return OK;
}
Рис. 1. Фрагмент ПО исследуемого ИТС
tdefine OK О ♦define NOT_OK 1 #define SYS_IRQPOLICY 1 tdefine SYS_IRQENABLE 2 int DspVersion[2];
chan to_kernel_channel = [0] of {byte}; chan from_kernel_channel = [0] of {byte};
active proctype kernel () {
int msg;
do
:: to_kernel_channel?msg ->
{
if
(msg == SYS_IRQPOLICY) -> if
from_kernel_channel!OK; from kernel channel!NOT OK;
}
fi;
fi;
(msg == SYS_IRQENABLE) -> if
:: from_kernel_channelI OK; :: from_kernel_channel!NOT_OK; fi;
else -> skip;
od;
}
active proctype dsp_init() |
do
byte result; DspVersion[0] = 0; DspVersion[1] - 0; if
DspVersion[0] = 0; DspVersion[0] = 1; DspVersion[0] = 5;
fi; if
fi;
if
{
}
DspVersion[1} = 0; DspVersion[1] = 1;
(DspVersion[0] < 4) ->
goto return;
Рис. 2. Модель фрагмента исследуемого ПО ИТС (неполная)
% spin -p -tmodel_assert.prm.trail model_assert.prm
Starting kernel with pid 0
Starting dsp_init with pid 1
spin: couldn't find claim (ignored!
2 : proc 1 (dsp_init) line 54 [DspVersion[0] = 0]
4; proc 1 (dsp init) line 55 [DspVersion[1] = 0]
6: proc 1 (dsp_init) line 60 [DspVersion[0] = 5]
8 : proc 1 (dsp_init) line 64 [DspVersion[1] = 0]
model_assert.prm" (state 1)
model_assert.prm" (state 2)
model_assert.prm" (state 5)
model_assert.prm" (state 8)
10 12 14
proc 1 (dsp_init) line 72 proc 1 (dsp_init) line 72 proc 1 (dsp_init) line 76
"model_assert.prm" "model_assert.prm" "model_assert.prm"
(state 15) (state 16) (state 19)
[else] [(1) ]
[to_kernel_channel!1]
15: proc 0 (kernel) line 23 "model_assert.prm" (state 1) [to kernel_channel?msg] 17: proc 0 (kernel) line 19: proc 0 (kernel) line [from kernel channel!0] 20: proc 1 (dsp_init) 1ine [from kernel channel?result]
26 "model^assert.prm" ( 29 "model_assert.prm" (
state 2) [((msg==l)) state 3)
77 "model_assert.prm" (state 20)
22 24 26
proc 1 (dsp_init) line 84 proc 1 (dsp init) line 84 proc 1 (dsp_init) line 88
"model_assert.prm" "model assert.prm" "model_assert.prm"
(state 24) (state 25) (state 28)
[else] [ (1) ]
89 "model_assert.prm" (state 2 9)
state 1)
[call_irqenable = 1] 28 : proc 1 (dsp_init) line [to_kernel_channel! 2]
29: proc 0 (kernel) line 23 "model_assert.prm" ( [to_kernel_channel?msg] spin : trail ends after 30 steps fprocesses: 2
DspVersion[0] = 5 DspVersion[1] =0 call irqenable = 1 30: proc 1 (dsp init) line 90 "model assert.prm" 30: proc 0 (kernel) line 43 "model_assert.prm" ( 2 processes created
(state 30) state 19)
Рис. 3. Контрпример
Далее необходимо проверить, является контрпример следствием ошибки моделирования или программирования. Анализируя поученный контрпример, можно установить, что в процессе инициализации параметр БзрУегаоп^] получил значение 5, и при вызове системной
функции 8у8_1щепаЬ1е() требование 1 нарушилось (рис. 4).
На 41 строке происходит вызов зувщепаЫеО, и, как следствие, спецификация нарушается, что и было выявлено в процессе верификации модели.
Строка DspVersion[0]
1 -
12 0
13 0
14 0
15 0
35 5
36 5
40 5
41 5
, На 41 строке происходит вызов 5уз_1гдепаЬ1е(), и, как следствие, спецификация I | нарушается, что и было выявлено в процессе верификации модели. I
1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ J
Рис. 4. Нарушение требования 1
Следовательно, с использованием предлагаемого подхода выявлена уязвимость, заключающаяся в потенциальной возможности невыполнения требования 1. Наличие данной уязвимости означает, что при обращении к ядру процессора посредством вызова функции 8у8_1щепаЫе() происходит прерывание при значениях параметра БзрУегаоп^] > 4. Такая уязвимость может быть использована злоумышленником в интересах нарушения функциональной стабильности ИТС при реализации КА.
Заключение
Таким образом, предложен алгоритм вскрытия уязвимостей для компьютерных атак в информационно-технических средствах, основанный на использовании автоматизированного метода формальной верификации про-
граммного обеспечения MODEL CHECKING, и рассмотрено его применение для фрагмента кода программного обеспечения. Предложенный алгоритм позволит дополнительно к существующей технологии вскрывать уязвимости в многопоточных, распределенных и параллельных алгоритмах функционирования, характерных для программного обеспечения иерархически организованных и распределенных информационно-технических средств. Алгоритм может быть использован в процессе автоматизированного синтеза тестовых алгоритмов компьютерных атак на информационно-технические средства в интересах оценки их функциональной стабильности на этапе предварительных, приемо-сдаточных (государственных), сравнительных и аттестационных испытаний.
СПИСОК ЛИТЕРАТУРЫ
1. Кларк Э.М., Грамберг О., Пелед Д. Верификация моделей программ: Model Checking — М.: МЦНМО, 2002. - 416 с.
2. Карпов Ю.Г. Model Checking. Верификация параллельных и распределенных программных систем - СПб.: БХВ-Петербург, 2010. - 551 с.
3. Документация, дистрибутивы SPIN // http:// spinroot.com [Интернет-ресурс]. Дата обращения: 01.09.2013 г.
4. Портал, посвященный программированию // http://esyr.org/wiki/BnHM,_npHMepbi_3afla4/3afla4a_3 [Интернет-ресурс]. Датаобращения: 01.09.2013 г.
