CC BY
102
© С.С. Кубрин, H.H. Самарин, 2013
УДК 004.056.5:519.718.2
С.С. Кубрин, Н.Н. Самарин
СОВРЕМЕННОЕ СОСТОЯНИЕ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ АНАЛИЗА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА УЯЗВИМОСТЬ *
Проведен анализ программных средств поиска уязвимостей программных продуктов. Приведены определения. Рассмотрены возможности и ограничения анализа программных средств поиска уязвимостей программных продуктов. Приведена их классификация. Определены виды потенциальных опасных возможностей, срьпых в коде программных средств. Ключевые слова: программные средства, уязвимость, опасный код.
В настоящее время развитие информационных технологий привело к пересмотру требований по надежности, отказоустойчивости, а также безопасности программного обеспечения. Одним из важнейших условий успешного функционирования практически значимых объектов информатизации, является защита используемого в их составе программного обеспечения от возможных сбоев, а также корректная работа его на всех наборах входных данных. Сбои в функционировании автоматизированных систем зачастую связаны с наличием уязвимостей (ошибок, дефектов) в программных средствах, при этом они могут приводить к аварийному завершению работы важных программно-аппаратных компонентов, создавая угрозу отказа для системы в целом. Следует отметить, что в настоящее время эффективных и широко распространенных автоматизированных средств, позволяющих проверять корректность программ и выявлять в них возможные уязвимости, не существует.
Задачи анализа программного обеспечения с исходным кодом можно разделить на два способа: ручной (экспертный) анализ и автоматизированный (шаблонный) анализ. Ручной анализ выполняют специалисты высокой квалификации, кото-
Статья подготовлена при финансовой поддержке Минобрнауки РФ в рамках ГК 16.525.12.5008 от 13.10.11
рые полагаются исключительно на свои знания и опыт, одновременно с этим указанный способ имеет большие затраты по времени и крайне дорогостоящий. При этом массовости в использование ручного способа анализа не наблюдается в силу следующих причин: усложнения аппаратных архитектур вычислительных машин, увеличения исходных текстов программ до сотен мегабайт, появлением программных прослоек между операционной системой и программным обеспечением. При шаблонном способе, деятельность экспертов облегчается в силу применения средств, которые осуществляют статичный анализ структуры исследуемой программы на наличие потенциально опасных конструкций языка программирования (уязви-мостях), используемого в программного обеспечении. Часто при данном способе используется совмещение автоматизированного и ручного поиска уязвимостей.
Вопросами выявления уязвимостей и сертификационных испытаний программного обеспечения занимаются испытательные лаборатории аккредитованные органом исполнительной власти (ФСБ и ФСТЭК России), которые в своей работе опираются на нормативно-методические документы, одним из которых является Руководящий документ Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия незадекларированных возможностей (далее РД) Гостехкомиссии России [1]. Объективные причины появления уязвимостей в программных продуктах заключаются в чрезвычайно высокой структурной сложности программного кода, динамичности развития версий выпускаемых разработчиком и легкости самомодификации программ при удаленном обновлении. К этому можно добавить проблему достоверной идентификации преднамеренно созданных программных закладок, несовершенство нормативно-методической базы и отставание инструментальной базы сертификационных испытаний. Методы, определяемые в РД, берут начало в теории надежности функционирования программ, поэтому вопросы защиты кода в них не отражены. В литературе информацию о исследовании программного обеспечения с учетом требований безопасности крайне мало и в основном рассматриваются вопросы поиска потенциальных уязвимостей в исходном коде,
программное обеспечение исходный код которого отсутствует практически не рассматривается. Стоит отметить, что наибольшую опасность представляют уязвимости, заложенные в программное обеспечение из-за невнимательности разработчиков на ранних этапах его жизненного цикла.
Уязвимые сигнатуры в исходных текстах ищутся разработчиками лишь на этапах внутреннего тестирования, основной целью которого является выявление собственных ошибок в разработанном продукте, при этом о тестировании безопасности программного обеспечения чаще всего не задумываются. В соответствии с РД основными видами проверок, которые должны проводиться испытательными лабораториями, являются структурный статический и динамический анализ исходных текстов. Указанные проверки позволяют выявить большинство уязвимостей несложных программ, но применительно к сложным программам это задача становится не выполнимой.
РД были выпущены в 1998 году и для того времени являлись актуальными, они предъявляли требования соответствующие этапу развития программирования. С ростом сложности программного продукта динамический анализ становится неразрешимой задачей и превращается в формальную процедуру. Многие программные продукты используемые экспертами в повседневной работе имеют списки потенциально опасных конструкций, а требования к ним РД не выдвигают, что делает неэффективными методы сигнатурного анализа. Не упоминается сигнатурный анализ в требованиях к испытаниям программ ниже второго уровня контроля (т.е. программ, обрабатывающих секретную и конфиденциальную информацию) [2]. Нет механизмов выявления ошибок кодирования, связанных с переполнением буфера, вызовом функций из чужого адресного пространства, проверки операций освобождения и «очистки» памяти и т.д. Отсутствуют требования по построению перечня маршрутов при выполнении функциональных ветвей программы, нет механизмов определения полноты покрытия кода и его достаточности при динамическом анализе. Для упрощения работы экспертов на рынке информационных технологий представлены коммерческие продукты, которые обладают своими достоинствами и недостатками.
Широко распространенное программное средство статического анализа исходных текстов на языке Си/Си++ ITS4 анализирует лишь наборы лексем, сопоставляя их с образцами потенциально опасных конструкций, хранящихся в специальной базе данных. Подобный алгоритм проверки может выдавать до 100 % ложных заключений, не обнаружив при этом в потенциально опасной исследуемой программе ни одной существующей уязвимости. Программный продукт BOON, основанный на принципе глубокого семантического анализа, выявляет возможные дефекты, предполагая, что некоторые конструкции являются частью неявного типа с конкретным размером буфера [3]. Программный инструмент MOPS (Mоdel checking Programs for Security) используется для динамической корректировки, обеспечивающей соответствие программы на Си статической модели [4]. Программная утилита RATS (Rough Auditing Tool for Security) анализирует исходный текст программы, находя потенциально опасные обращения к функциям, использует сочетание проверок надежности защиты от семантических проверок в ITS4 до глубокого семантического анализа в поисках дефектов, способных привести к переполнению буфера, полученных из MOPS . Статический сканер исходных текстов программ Flawfinder выполняет поиск функций, которые чаще всего используются некорректно, присваивает им коэффициенты риска (опираясь на такую информацию, как передаваемые параметры) и составляет список потенциально уязвимых мест, упорядочивая их по степени риска [6]. Программный комплекс Splint позволяет находить лишь простейшие уязвимости такие, как например, выход за границу статистического массива при обращении к нему.
Стоит обратить внимание, что на отечественном рынке существуют российские разработки, а некоторые из них имеют сертификат ФСТЭК России. Анализатор исходных текстов «АИСТ-С», позволяет получать в автоматическом режиме информацию о структуре и ряде характеристик исследуемого программного обеспечения, а также обеспечивает проведение экспертом в интерактивном режиме операций по анализу получаемой информации с привязкой к анализируемым исходным текстам. Однако, несмотря на его очевидные достоинства, установлено, что анализатор исходных ек-
стов некорректно обрабатывает структуры объектно-ориентированных программ, не анализируются и исходные тексты, подключаемые директивами #include — лишь проверяется исходный текст программы. Мало того, нормальная работа анализатора возможна, только если объем исходных текстов не превышает нескольких мегабайт: блок-схемы программ строятся некорректно уже для программ объемом более нескольких килобайт. Программный комплекс «IRIDA Sources» предназначен для проведения статического и динамического анализа потоков управления в исходных кодах программ на языке Си++ для проектов Microsoft Visual Studio .NET. Анализатор «AK-ВС 1.0» предназначен для проведения сертификационных испытаний на отсутствие незадекларированных возможностей (программных закладок) и анализа безопасности программного кода является единственным сертифицированным средством проведения сертификационных испытаний по 2 и 1 уровням контроля отсутствия незадекларированных возможностей по требованиям РД. Результаты проведенного анализа и сравнительные характеристики программных продуктов приведены в табл. 1.
Самыми распространенными и потенциально опасными уязвимостями являются ошибки переполнения буфера и использования неконтролируемой форматной строки. Переполнение буфера (buffer overflow) возникает как следствие отсутствия контроля или недостаточного контроля выхода за пределы массива в памяти. Языки Си/Си+ + , чаше всего используемые для разработки программного обеспечения системного уровня, не реализуют автоматического контроля выхода за пределы массива во время выполнения программы. По месту расположения буфера в памяти процесса различают переполнения буфера в стеке (stack buffer overflow), памяти (куче) (heap buffer overflow) и области статических данных (BSS buffer overflow) [5].
Ошибки неконтролируемой форматной строки (format string) возникают из-за недостаточного контроля параметров при использовании функций форматного ввода-вывода семейства printf/scanf стандартной библиотеки языка Си. Эти функции принимают в качестве одного из параметров символьную строку, задаюшую формат ввода или вывода после-дуюших аргументов функции.
В процессе тестирования и отладки программы обнаружить уязвимости защиты чрезвычайно трудно, так как в большинстве случаев для того, чтобы уязвимость себя проявила, программе необходимо передать нетривиальные входные данные. Поэтому на стадии тестирования и отладки находятся лишь самые-простые уязвимости. Другой подход к предотвращению использования уязвимостей защиты представляют собой утилиты, предназначенные для обнаружения попыток взлома защиты в реальном времени. Однако часто такие программы влекут неприемлемые временные затраты, при этом они фиксируют лишь попытку взлома, не указывая собственно на место ошибки в программном обеспечении. Поэтому наиболее полным с точки зрения безопасности решением является аудит исходного кода программы с привлечением автоматических или полуавтоматических инструментальных средств (так как исследование кода, проводимое вручную, является дорогостоящим, длительным и неэффективным).
Указанные выше способы выявления уязвимостей (ошибок, дефектов) применимы только для программного обеспечения, которое имеет исходный код. Как показывает статистка на территории России используется более 70 % импортного программного обеспечения, которое не имеет исходного кода и не может быть подвергнуто исследованию предлагаемому по РД, поэтому автоматизированный процесс исследования существующими продуктами для этого программного обеспечения не применим. Выполненный анализ показывает, что большинство программ используемых для поиска уязвимости хорошо справляются со статическим анализом, динамический анализ присутствует не у всех, однако самым важным выявленным аспектом является не применимость проанализированного программного обеспечения (табл. 1) для анализа продуктов, у которых отсутствует исходный код.
При наличии исходного кода эксперт выявляет потенциально опасные конструкции (уязвимости), итогом его работы должно быть утверждение, что исследованный продукт надежен, корректен и безопасен. С другой стороны программный продукт не имеющий исходного кода потенциально несет угрозу автоматизированной системе в которой он должен функционировать. Для реализации потенциально заложенной угрозы программа должна взаимодействовать с общим и прикладным
Таблица 1
Сравнительные характеристики программных продуктов по определению безопасности программного кода
№ п/ п Наименование продукта Поддерживаемые языки Тип анализируемой программы Тип анализа Список потенциально опасных сигнатур Определение типа уязвим остей Наличие сертификата ФСТЭК
С исходным кодом Без исходного кода Статиче- Динамиче- Неконтролируемая Переполнение Запрос исполняемых Нулевой указатель
1 BOON Си + - + - - - + - + нет
2 CQual Си + - + - - + - - - нет
3 MOPS Си + - + + + + + + + нет
4 ITS4 Си + - + - + + + + + нет
5 RATS Си/Си++, PHP, Perl, Python + + + + + + нет
6 Flawfinder Си/Си++ + - + - + + + + + нет
7 UNO Си + - + - - + - - + нет
8 FlexeLint (PC-Lint) Си/Си++ + - + - - + + + + нет
9 Coverity Си/Си++, Java + - + - - + + - + нет
10 Frama-C Си + - + - - + + + + нет
11 JavaChecker Java + - + - - + - + + нет
12 Qaudit Си/Си++ + - + - - + + + + нет
Отечественные программные продукты
13 АИСТ-С Си/Си++ + + + + + + № 451 до 05.06.
1—' 1—' 1—' СП 1—'
Программный комплекс «IRIDA Sources» «AK-ВС 1.0» von КСАИТ Наименование продукта
Си++ Си/Си++, Java, Pascal, Си#, PHP, Assembler Си/Си++, Pascal, Perl, PLM Си/Си++ Поддерживаемые языки
+ + + + С исходным кодом Тип анализируемой программы
Без исходного кода
+ + + + Статиче- Тип анализа
+ + 1 1 Динамиче-
+ + + Список потенциально опасных сигнатур
+ + + + Неконтролируемая Определение типа уязвим остей
+ + + + Переполнение
+ + + + Запрос исполняемых
+ + + + Нулевой указатель
№ 3185 до 17.08.1 3 № 1710 от 13.01.0 9 нет нет 1—' 00 Наличие сертификата ФСТЭК
программным обеспечением тем самым воздействовать на систему в целом.
Введем определение: колом с потенциально опасными возможностями - назовем код, реализующий одно или несколько действий определенного вида, последствия выполнения которых могут либо непосредственно представлять угрозу целостности, достоверности и конфиденциальности данных, либо приводить к выполнению кода, представляющего данную угрозу. Выделим виды опасных возможностей:
а) передача управления в область модифицированных данных;
б) самомодификация или изменение кода других программ в оперативной памяти или на внешних носителях;
в) самодублирование, подмена собою других программ или перенос своих фрагментов в области оперативной или внешней памяти, не принадлежащие программе;
г) сохранение информации из областей оперативной памяти, не принадлежащих программе;
д) искажение, блокирование или подмена информации, являющейся результатом работы других программ;
е) скрытие своего присутствия в программной среде.
Передача управления в область модифицированных данных
используется для активизации выполнения динамически сформированного кода. Программа, реализующая такую возможность, формирует алгоритм своего функционирования (по крайней мере, его часть) динамически, во время своего выполнения. Такая возможность позволяет создавать или изменять участки кода, не обнаруживаемые статическим анализатором, что приводит к неполному восстановлению алгоритма функционирования исследуемой программы на этапе статического анализа. Самомодификация программы в оперативной или внешней памяти приводит к изменению алгоритма функционирования программы относительно ее исследуемого образца. Отсюда следует невозможность полного восстановления алгоритма (всех его вариантов) путем статического анализа.
Модификация кода других программ в оперативной или внешней памяти приводит к изменению их функциональности и может использоваться для внедрения закладок. Целью такой модификации может являться получение кодом, содержащим
опасные возможности, более высокие привилегии на выполнение. Сохранение информации из областей оперативной памяти, не принадлежащих программе, представляет собой обращение к областям оперативной памяти, не принадлежащим процессу, с целью их копирования в собственные области памяти, либо во внешнюю память. Может приводить к утечке конфиденциальных данных, а также данных, критичных для безопасности системы в целом, либо отдельных приложений. Искажение, блокирование или подмена информации, являющейся результатом работы других программ являются данные, размещаемые в оперативной памяти или на внешних носителях. Их искажение, блокирование или подмена имеют целью навязывание входной или выходной информации, например, навязывание результата проверки пароля, навязывание длины файла, подлежащего шифрованию, изменение файла перед установкой ЭЦП, и т. п. Скрытие присутствия некоторого кода в теле программы имеет своей целью затруднение обнаружения и исследования этого кода. Для затруднения обнаружения и анализа кода могут использоваться следующие способы: самомодификация кода, передача управления внутрь инструкций, эмуляция команд переходов и вызовов, шифрование и компрессия кода.
На основании вышеизложенного можно сделать следующие выводы.
1. Действующие нормативно-методические документы морально устарели и не соответствуют реальным требованиям по надежности, отказоустойчивости, а также безопасности программного обеспечения имеющего исходный код.
2. Разработчики программного обеспечения в своей деятельности используют импортные средства для поиска уязвимо-стей в исходном коде программ, которые позволяют определять большую часть стандартных ошибок совершенных при написании программ.
3. На рынке присутствуют отечественные средства поиска уязвимостей в исходном коде программ, которые сертифицированы ФСТЭК по требованиям безопасности, однако широкого распространения они не получили в связи с высокой стоимостью и специфичностью применения.
4. Выполненный анализ показал, что методы и средства, используемые в настоящее время для исследование программно-
го обеспечения с закрытым исходным кодом, которого на рынке подавляющее большинство, не применимы.
5. Существуют частные способы выявления потенциально опасных действий программного обеспечения с закрытым исходным кодом, которые могут представлять угрозу целостности, достоверности и конфиденциальности данных в автоматизированных системах.
6. Требуется разработать алгоритм, методы и способы анализа программного обеспечения с закрытым исходным кодом с целью проверки его надежности и безопасности.
- СПИСОК ЛИТЕРАТУРЫ
1. Руководящий документ. Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей. М.: Гостехкомиссия России, 1998.
2. Выявление уязвимостей программного обеспечениия в процессе сертификации / А.С. Марков, С.В. Миронов, В.Л. Цирлов // Известия Южного федерального университета. Технические науки. 2006. Т. 62. № 7. С. 82-87.
3. D. Wagner et al., «A First Step Towards Automated Detection of Buffer Overrun Vulnerabilities», Network and Distributed System Security, 2000; www.isoc.org.
4. H. Chen, D. Wagner, «MOPS: An Infrastructure for Examining Security Properties of Software», Proc. ACM Conf. Computer and Communications Security, ACM Press, 2002.
5. Маликов О.Р. Автоматическое обнаружение уязвимостей в исходном коде программ, Известия ТРТУ, №4, с. 48-53, 2005.
6. Криспин Кован, «Безопасность систем с открытым кодом», «Открытые системы», № 07-08, 2003. !ЕШ
КОРОТКО ОБ АВТОРАХ -
Кубрин Сергей Сергеевич - профессор, доктор технических наук, зав. лабораторией, s_kubrin@mail.ru
Институт проблем комплексного освоения недр Российской академии наук Самарин Николай Николаевич - аспирант, mnogoru2004@mail.ru Московский государственный горный университет.
