CC BY
46
5. Hammonds K. H. How Google Grows...and Grows...and Grows // Журнал FastCompany. - 2003. - Режим доступа: http://www.fastcompany.com/magazine/69/google.html, своб.
6. Инструкция пользователя Lustre 1.6, 2007. - Режим доступа: http://manual.lustre.org/manual/LustreManual16_HTML/TOC.html, своб.
7. Егоров А. RAID 0, RAID 1, RAID 5, RAID 10, или что такое уровни RAID? Материалы компании «ТИМ», 2005. - Режим доступа: http://www.timcompany.ru/article4.html, своб.
8. Фильчаков А. Кластеры и кластеризация // КомпьютерПресс. - 2000. - № 10.
9. Пресс-релиз Red Hat Enterprise Linux 5 Оптимальное решение для финансовых организаций. Материалы компании Red Hat, 2007. - Режим доступа: http://www.redhat.com, своб.
10. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. -СПб: Питер, 2003. - 877 с.
11. Вахалия Ю. UNIX изнутри. - СПб: Питер, 2003. - 844 с.
Лукьянов Николай Михайлович
Кириллов Владимир Васильевич
— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, nikolay@lukianov.net, nikolay.lukianov@gmail.com
— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, кандидат технических наук, профессор, kirillovvv@gmail.com
УДК 681.3.06
МЕТОД РАЗБОРА ИСХОДНЫХ ТЕКСТОВ ПО УПРОЩЕННОЙ ГРАММАТИКЕ ЯЗЫКА
Д.Б. Арефьев, В.Л. Верещагин, А.И. Галанов, А.А. Молдовян
Статья рассматривает метод разбора исходных текстов, основанный на упрощенном множестве порождающих правил грамматики. Приводится концепция метода и сведения об эффективности применения на практике.
Ключевые слова: защита, информация, уязвимости, анализ, грамматика, исходный текст.
Введение
Опыты, приведенные в данной статье, были выполнены в рамках создания специального комплекса, предназначенного для контроля уязвимостей программ. Данный комплекс работает с исходными текстами и создан с целью повышения эффективности существующих методов контроля. Одни методы предполагают прямой поиск заданных выражений, другие используют отладочную информацию, третьи справедливо считают, что для корректного исследования программы необходимо выполнить полный лексический и синтаксический анализы. При разработке нового комплекса был учтен опыт практического применения этих методов, и в данной статье предлагается исследование метода разбора по упрощенной грамматике языка. Для эксперимента был выбран язык ANSI C (99) по нескольким причинам: язык широко применяется в промышленности, достаточно прост для разбора и обладает низкой защищенностью.
Программный комплекс предоставляет эксперту сведения о безопасности программы на основе данных, полученных в результате разбора исходных текстов по правилам грамматики языка. Формирование полной грамматики является достаточно трудоемким занятием. С другой стороны, ни одна из исследованных программ не использовала полную мощность языка, что позволило использовать только такое количество
грамматических правил, которое необходимо и достаточно для конкретного проекта. В работе рассматривается методика, которая позволяет корректно определить количество таких необходимых и достаточных правил, при условиях, что дальнейший анализ ориентирован на оценку безопасности программного продукта.
Постановка задачи
Как уже было сказано, поиск программных закладок начинается со сбора информации об исследуемой программе. Если взять на исследование какой-либо проект средней величины, состоящий из нескольких десятков исходных файлов, то среди них обязательно окажется какое-то число избыточных. До разбора файлов проекта целесообразно выделить только те файлы, которые действительно компилируются и собираются. Для этого применяется способ [1], основанный на принципе маркировки каждого исходного файла проекта. После того, как в каждый файл будет вставлен уникальный маркер, проект компилируется, и в сформированных исполняемых файлах отыскиваются маркеры тех файлов, из которых он был собран. Этот простой способ позволяет составить список файлов, по которым необходимо собрать информацию о функциях, линейных участках, связях между ними и т.п.
В основном требования к тому, какая именно информация должна быть собрана, описаны в руководящем документе [2]. К сожалению, как показывает практика, для эффективного контроля программных закладок выполнение этих требований оказывается недостаточным, и необходимо вводить дополнительные проверки (например, методом выявления пассивных программных закладок), для которых необходима дополнительная информация.
Общие требования к информации, которая должна быть сформирована для каждого исполняемого файла после разбора, можно представить следующим образом:
- список исходных файлов;
- сведения о функциях, их связях с исходными файлами, переменными, другими функциями и линейными участками;
- сведения о начале функции в исходном файле и ее окончании;
- сведения о начале линейного участка и его окончании;
- сведения о переменных;
- сведения об аргументах функций;
- сведения о содержании проверки в условных операторах и операторах цикла;
- сведения о выражении в операторе выбора;
- сведения о передаче управления линейным участком;
- сведения об окончании файла (сдвиг от начала, завершающий оператор);
- сведения о метках для оператора безусловного перехода
и др. Весь список достаточно велик для приведения его здесь, и, видимо в этом нет никакой необходимости, так как при более подробном рассмотрении пришлось бы переписывать полную грамматику языка. Именно такой подход был использован в разработке анализатора, основывающегося на формальных грамматиках [3]. Технически он наиболее совершенен по сравнению с другими подходами, но имеет достаточно трудную реализацию в связи с тем, что для каждого языка (пусть даже такого специфического, как Avenue) необходимо написать полную грамматику, что может занять больше времени, чем даже ручной анализ. Чтобы не идти таким сложным путем, несколько лет назад в анализаторе ST (разработка одного из ведущих российских специалистов по безопасности В.Н. Стрельца) был реализован подход, основывающийся на отладочной информации [4]. Суть этого подхода заключается в следующем: Visual Studio формирует во время компиляции специальный файл, в котором содержится отладочная информация. Этой
информации достаточно для того, чтобы выполнить анализ по 3-му уровню контроля не-декларированных возможностей соответственно руководящему документу.
Достаточно простой подход используют английские и американские исследователи Джон Виега (JohnViega), Гари МакГроу (Gary McGraw) и др. В своей статье о статическом сканере безопасности ITS4 [5] они приводят аргументы в пользу упрощенной грамматики языка и доказывают ее эффективность. Сканер безопасности ITS4 предназначен для контроля таких ошибок, как переполнения буфера, утечка памяти, ошибки в работе механизма указателей, ошибки инициализации создаваемых объектов и др. Он успешно находит некорректное использование стандартных функций вроде strcpy, strcut и sprintf , используя предложенную методику. Фактически грамматика языка, используемая сканером, должна содержать правила объявления функций, переменных, указателей и некоторые другие. Этот подход позволяет им безошибочно находить необходимые места текста и анализировать их степень уязвимости.
В наших исследованиях учтен опыт использования формальных грамматик, а также опыт зарубежных специалистов. Вернемся к тому, что перед разбором исходных текстов были выбраны только те файлы, которые действительно входят в проект. Отметим, что все отобранные файлы компилируются. Это обстоятельство позволяет нам сформулировать основополагающее условие опыта - для исходного текста, подлежащего лексическому и синтаксическому анализу, существует такая однозначная контекстно-свободная грамматика, которая порождает язык, являющийся либо подмножеством исходного языка, либо совпадающий с ним. Под исходным языком в нашем опыте понимается стандарт ANSI C (99), но это лишь частный случай, на самом деле им может быть любой существующий на сегодняшний день язык программирования. В таком случае мы можем построить такой синтаксический анализатор, который будет работать на основе только тех структурных правил языка, которые используются в текстах разбираемой программы.
Резюмируя сказанное, можно отметить, что к задачам исследования относится оценка предлагаемого метода анализа, в частности, важно ответить на вопрос: «Возможно ли использовать упрощенную грамматику для анализа исходных текстов?».
Методы исследований
Чтобы оценить метод анализа, необходимо провести эксперимент и интерпретировать полученные результаты применения. Общая концепция анализа основана на синтаксическом разборе исходных текстов, и для того, чтобы получить результаты, необходимо использовать средства автоматизации. В рамках исследования был создан инструмент для анализа, который будет рассмотрен ниже.
Перед тем, как рассмотреть концептуальную схему работы анализатора, целесообразно определить его местоположение в составе специального комплекса контроля уязвимостей и программных закладок. На рис. 1 представлена схема, отображающая основные взаимосвязи модулей комплекса.
Некоторые принципы взаимодействия модулей целесообразно рассмотреть отдельно. Исходные тексты (блок 12) исследуются на наличие избыточности в блоке 9. Те файлы, которые были отобраны как «используемые», участвуют в дальнейшем анализе, а избыточные файлы помечаются в базе данных (БД, блок 10). Файлы попадают на вход модуля разбора исходных текстов (блок 1). Именно методы, применяемые в данном модуле, исследуются в данной статье. Информация о файлах сохраняется после разбора в БД, после чего используется на стадии статического анализа (блок 2). Статический анализ предназначен для исследования исходного текста программы на соответствие стандартам программирования, на наличие дефектов и уязвимостей, в частности, программных закладок. Подготовка к динамическому анализу реализуется в модуле вставки
датчиков (блок 4). Датчики вставляются в каждый линейный участок, информация о которых хранится в БД, заполненной после разбора исходных текстов. Версия исходных текстов проекта со вставленными датчиками называется лабораторной (блок 6). Последовательность сработавших датчиков формирует «трассу» программы (блок 11), которая затем попадает на вход модуля динамического анализа (блок 14). Блок 13 формирует отчеты по результатам статического и динамического анализа (список функций, связей, переменных, и т.п.). В блоках 5, 7, 8 показаны некоторые модули, теоретически входящие в процесс статического анализа, но фактически реализованные как отдельные программные модули. Среди них, соответственно, модуль построителя блок-схем, модуль контроля уязвимостей из БД и модуль обнаружения пассивных программных закладок.
Взаимообратные связи Предмет исследования
Составные элементы программного комплекса Выходные данные не уносимые в БД Входные/выходные исходные данные
Рис. 1. Упрощенная схема комплекса контроля уязвимостей
Как видно из общего описания схемы, модуль разбора исходных текстов играет основополагающую роль. Алгоритм модуля преобразует исходные тексты к такому виду, который можно использовать для статического и динамического анализов. На концептуальной схеме (рис. 2) показано взаимодействие различных составляющих модуля разбора исходных текстов.
■
Терминальный словарь
Компилируемые исходные тексты программ
.■■■' .■■■' .■■■' .■■■' .■■■' .■■■" .■■■' .■■■' .■■■' .■■■' и
; 2
'У/УРу4Ф$0У
Синтаксический анализатор
Условные обозначения
Прямые связи Взаимообратные связи
Составные элементы программного комплекса
Входные/выходные данные
Рис. 2. Концептуальная схема разбора исходных текстов
Исходные тексты (блок 7), которые не являются избыточными и собираются в проект, попадают на вход лексического анализатора (блок 4). В результате лексического разбора исходные тексты представляются в виде множества лексем (блок 5) с соответствующими им атрибутами. Терминальный словарь (блок 1) на стадии лексического анализа способствует выделению лексемы в тексте. Словарь формируется исследователем самостоятельно, либо экспортируется ранее созданный. Инструмент, позволяющий сформировать словарь для какого-либо языка, - «Редактор порождающих правил и словаря» -показан на рис. 2 под номером 2. Данный инструмент позволяет по необходимости расширять или сокращать список терминальных символов. Теоретически необходимость может состоять в прикладном использовании. Если исследуемые исходные тексты написаны на узкоспециализированном языке, например, Avenue (скриптовый язык, используемый для геоинформационных систем), то при определенных условиях может отсутствовать необходимость вводить все терминальные символы, из которых формируется язык. Таким условием, например, может быть небольшой объем исходных текстов, в которых набирается десяток терминальных символов. В таком случае может оказаться целесообразным сформировать подобный список вручную и затем его использовать для создания множества порождающих правил (блок 3).
Множество правил построения предложений языка порождают схему грамматики. Полная схема включает в себя все правила, позволяющие сформировать множество конечных цепочек терминального алфавита (словарь), т.е. конечный язык. Редактор позволяет исследователю самостоятельно сформировать порождающие правила. На рис. 3 показана обобщенная схема работы модуля «Редактор порождающих правил и словаря».
Терминальный словарь
Компилируемые исходные тексты программ
Редактор порождающих правил
Множество порождающих правил
Упрощенная грамматика языка
ш
Прямые связи Взаимообратные связи
Составные элементы программного комплекса
Входные/выходные данные
Рис. 3. Схема получения упрощенной грамматики языка
Как видно из схемы, принцип получения упрощенной грамматики несколько отличается от классических представлений о ее формировании. Показан подход не от грамматики к исходным текстам, а от исходных текстов к грамматике. Данный подход заключается в следующем.
1) Исследователь определяет язык программирования исходных текстов и формирует терминальный словарь (блок 6). Совокупность терминальных символов, характерных для конкретного языка, образует терминальный словарь. Типы данных, условные операторы, идентификаторы и пр. является терминальными символами. Словарь может быть импортирован из уже существующего варианта либо создан заново. Чтобы словарь можно было дополнить, изменить или создать, создан специальный инструмент «Редактор терминального словаря» (блок 1).
2) Исследователь берет для анализа те файлы, которые успешно компилируются (блок 10). Это гарантирует то, что все цепочки терминальных символов (исходные тексты) сформированы посредством некоторого множества порождающих правил, которое, в свою очередь, является подмножеством правил полной грамматики языка. Допустим, в полной грамматике существует 1000 различных правил вывода цепочек, а в исходных текстах используется мощность языка всего лишь на 30%, т.е. реализовано всего 300 различных цепочек. Если по ним составить выводящие правила, то мы получим упрощенный вариант правил, характерный именно для этих исходных текстов. Данный способ может быть удобен в двух основных случаях: грамматика языка отсутствует, и необходимо формировать ее самого начала; имеется грамматика языка, но устаревшая, требующая доработки. В первом случае упрощенная грамматика позволяет избежать формирования полной схемы, а во втором случае - конфликтов новых правил со старыми правилами.
3) Формируются лексемы. Исходные текспы обрабатываются лексическим анализатором (блок 7), в результате чего формируется массив лексем (блок 4). Тип каждой лексемы определяется, и затем все типы выстраиваются в соответствии с последовательностью, описанной в исходных текстах. Например, если в программе есть строчка объявления переменной: «int a;», то последовательность типов лексем будет выглядеть так: «Type ID;», где «Type» - это «тип данных», «ID» - последовательность латинских букв, не являющихся служебным словом и удовлетворяющая правилам составления идентификатора. Вся эта информация отображается в окне модуля «Обозреватель типов лексем исходного текста» (блок 2).
4) Формируется множество порождающих правил. Порождающее правило формируется исследователем вручную на основе последовательности типов лексем. «Редактор порождающих правил» (блок 3) позволяет создавать и изменять набор правил. Множество порождающих правил (блок 5) формируется по результатам проработки исходных текстов исследователем.
5) Формирование конечной грамматики. Модуль «Компилятор грамматики» (блок 8) приводит набранную грамматику к удобному для автоматической обработки виду и сохраняет в отдельный файл, который и формирует упрощенную грамматику языка (блок 8, рис. 3, и блок 3, рис. 2).
Компоненты модуля, выполняющего разбор исходных текстов (блок 1, рис. 1), можно представить в виде двух групп. Первая группа - это компоненты, изменяемые при исследовании нового языка, например, «терминальный словарь», «множество порождающих правил», «массив лексем» и «упрощенная грамматика языка». Фактически это входные данные, которые изменяются вместе с исследуемыми исходными текстами. Вторая группа - это алгоритмы, остающиеся неизменными при новых исследованиях, например, при исследовании программ, написанных на языках, для которых отсутствует сформированный словарь и набор порождающих правил. К таким компонентам относятся программы «Лексический анализатор», «Обозреватель типов лексем исходного текста», «Редактор терминального словаря», «Редактор порождающих правил» и «Компилятор грамматики». В результате получаем инструмент, который позволяет проводить разбор и анализ программ, написанных на различных языках.
Получается, что сложность анализа прямо пропорциональна мощности схемы грамматики, применяемой в данном конкретном проекте.
Эксперимент, проводимый при исследовании методики анализа, заключается в следующем. Цель - определить корректность методики анализа исходных текстов по упрощенной грамматике языка. Файлы с исходными текстами подаются на вход анализатора, над ними производятся лексический, синтаксический и статический анализы, в результате чего в БД сохраняется определенная информация1. Среди этой информации имеются сведения о функциях, линейных участках, переменных и связях между ними. Критерием правильности выполнения анализа исходных текстов, является соответствие списка функций, линейных участков и переменных действительному состоянию в исходных текстах. Исходные условия состоят в следующем:
1. 1539 исходных файлов, написанных на языке ANSI C (99);
2. все файлы компилируются и собираются в конечные исполняемые файлы;
т 2
3. в исходных текстах отсутствуют правила, не учтенные в грамматике;
4. компилятор «Watcom C 10.6»;
5. среда компиляции - операционная система реального времени «QNX» версии 4.25;
6. среда анализа - MS Windows XP (SP2) + драйвер поддержки файловой системы «ext2».
Методика проверки заключается в следующем. Для всех 1539 файлов производятся синтаксический и статический анализы. В результате формируется БД со списком функций, переменных и линейных участков. Для контроля формируется список файлов, которые будут проверены вручную. Из всех файлов выбираются такие, которые содержат максимальное число не повторяющихся порождающих правил. Из этих файлов формируется группа, которая суммарно содержит все порождающие правила упрощенной грамматики. Для сформированного списка файлов проводится ручной анализ, который сравнивается с результатами статического. В том случае, если результаты совпадают, считается, что к данным исходным текстам метод был применен корректно. Проверенные файлы удаляются из общего списка, и формируется новая группа для проверки. Общее количество таких проверок равно трем. По результатам делается вывод о корректности работы метода анализа на основе упрощенной грамматики языка.
Результаты исследований
Результаты исследования, в частности, проведенного эксперимента, целесообразно разложить на два основных этапа - анализ исходных текстов и выполнение ручного контроля полученных результатов. Результаты, полученные на первом этапе, были записаны в БД в виде таблиц. Концептуальное представление таблиц можно видеть на примере (см. таблицу).
№ Имя № № Начало Оконч. Связь Флаг 1 Флаг N
эл-та эл-та исх. исп. эл-та, эл-та, с др.
текста файла в байтах в байтах эл-ми
0 func() 27 03 1982 2401 1 1 • 0
1 if(a>b) 12 03 1863 1945 82 1 ... 1
,,, • * * • • • • • • • • • • • • • ♦ ♦ • •
L i T M 0 004 2008 X • Y
Таблица. Пример формата представления данных в БД
1 В соответствии с требованиями РД.
2 Для достижения этого условия используется механизм выявления нераспознанных конструкций в инструменте «Редактор порождающих правил» (блок 3, рис. 3)
БД содержит таблицы со сведениями об исполняемых и исходных файлах, о функциях, о линейных участках, переменных и связях между ними, а также необходимую дополнительную информацию.
Ручной анализ показал, что при автоматическом подходе были верно сформированы таблицы функций, переменных и линейных участков, а также связи между ними. На основании этого можно сделать вывод о возможном применении упрощенной грамматики при анализе исходных текстов.
К недостаткам данного подхода проверки можно отнести индукционный подход доказательства. В связи с тем, что полностью исходные тексты проверить вручную не представляется возможным, целесообразно найти эталонный вариант контроля функций, переменных и линейных участков и разработать автоматизированное средство сравнения полученных результатов. В качестве такого эталонного варианта анализа может быть использован, например, компилятор и его отладочная информация.
Заключение
Проведенные исследования позволили сформировать представление о достоинствах и недостатках метода анализа исходных текстов, основанного на использовании упрощенной грамматики языка. Упрощенная грамматика определяется на основе множества правил вывода конечных цепочек языка, характерных только для исследуемых исходных текстов. За счет такого подхода процесс формирования полной грамматики языка упрощается пропорционально мощности схемы грамматики. Исследования показали, что весь метод позволяет корректно обрабатывать исходные тексты и получать сведения о таких конструкциях языка, как переменные, функции и линейные участки. Среди достоинств метода следует отметить:
- гибкость (одними и теми же инструментами можно исследовать программы, написанные на различных языках программирования);
- достаточность (исходный текст разбирается с необходимой для анализа точностью);
- эффективность (результаты исследования превышают менее точные разборы, например, на основе отладочной информации, и не уступают анализу, основанному на применении полной грамматики языка).
К недостаткам подхода следует отнести прикладные качества - метод можно использовать при достаточном уровне знаний, касающихся теории компиляции и программирования. Другой недостаток - высокая трудоемкость формирования порождающих правил по исходным текстам.
Литература
1. Котенко Д. А. Контроль избыточности исходных файлов программ на основе вставки программных датчиков // V Санкт-Петербургская межрегион. конф. «Информационная безопасность регионов России (ИБРР-2007)», Санкт-Петербург, 23-25 октября 2007 г. - СПб: СПОИСУ, 2007. - 153 с.
2. Руководящий документ «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей» по 3 уровню контроля. - Гостехкомиссия России (в настоящее время ФСТЭК), Москва, 1999 г.
3. Котенко Д.А., Солодянников А.В. Метод использования формальных грамматик языков программирования при проведении сертификационных испытаний на отсутствие недекларированных возможностей // V Санкт-Петербургская межрегион. конф. «Информационная безопасность регионов России (ИБРР-2007)», Санкт-Петербург, 23-25 октября 2007 г. - СПб: СПОИСУ, 2007. - 153 с.
4. Верещагин В.Л., Солодяннков А.В. Анализатор исходного текста, основанный на обработке отладочной информации // V Санкт-Петербургская межрегион. конф. «Информационная безопасность регионов России (ИБРР-2007)», Санкт-Петербург, 23-25 октября 2007 г. - СПб: СПОИСУ, 2007. - 153 с.
5. J. Viega et al.. ITS4: A Static Vulnerability Scanner for C and C++ Code. // Ann. Computer Security Applications Conf. (ACSAC), Applied Computer Security Assoc., 2000.
6. Фомичев В.С. Теория автоматов. - СПб: СПбГЭТУ, 2007. - Режим доступа: http://www.eltech.ru/misc/LGA_2007_FINAL/Allpage/Section6/part_6.1_.html, своб.
7. Ахо А.В., Сети Р., Ульман Д. Компиляторы: принципы, технологии и инструменты. - М: Издательский дом «Вильямс», 2003.
Арефьев Дмитрий Борисович
Верещагин Владимир Леонидович
Галанов Алексей Игоревич
Молдовян Александр Андреевич
Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, av_dmitry@mail.ru Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, seckey@yandex.ru Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, daiverddd@yandex.ru Научный филиал Федерального государственного унитарного предприятия "НИИ"Вектор" специального центра программных систем "Спектр", директор, доктор технических наук, профессор, ma@cobra.ru
УДК 004.032.2
АВТОМАТИЗИРОВАННАЯ СИСТЕМА СБОРА И ОБРАБОТКИ ДАННЫХ СКВАЖИННЫХ ИЗМЕРЕНИЙ С ПОМОЩЬЮ АКУСТИЧЕСКОГО РАСХОДОМЕРА Т.Е. Войтюк, А.В. Демин
В статье представлены новые концепции сбора и обработки данных скважинных измерений с использованием акустического расходомера. Автоматизированная система позволяет повысить рентабельность разработки ранее неперспективных месторождений.
Ключевые слова: нефть, добыча, месторождение, акустический расходомер, волоконно-оптический.
Введение
Использование новейших информационных технологий в процессе разработки нефтяных и газовых месторождений России становится первостепенной задачей на пути увеличения и контроля эффективности месторождений. Все большее число нефтедобывающих компаний сталкивается с необходимостью вскрытия нескольких продуктивных зон одной скважиной и, в то же время, обеспечения возможности замера деби-тов из каждой отдельной зоны, что связано с поддержанием баланса между существующим подходом к разработке недр, с одной стороны, и экономическими соображениями, с другой. Затраты на строительство дополнительных эксплуатационных скважин на каждом кустовом основании в большинстве случаев превышают стоимость закачивания одной скважины по схеме, позволяющей вести одновременную добычу сразу из нескольких продуктивных горизонтов.
Для решения этой задачи применяют технологию «интеллектуальное месторождение», которая дает возможность оперативно принимать решения по оптимизации режи-
