Коллектив авторов - Защита от хакеров корпоративных сетей

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

elliptic@ellipse:~$ diff axspawn-0.2.1/axspawn.c axspawn-

0.2.1a/axspawn.c

491c491

< envc = 0;

–

> envc = 0;

493c493

< sprintf(envp[envc++], “AXCALL=%s”, call);

–

> sprintf(envp[envc++], “AXCALL=%.22s”, call);

495c495

< sprintf(envp[envc++], “CALL=%s”, (char *)user);

–

> sprintf(envp[envc++], “CALL=%.24s”, (char

*)user); 497c497

< sprintf(envp[envc++], “PROTOCOL=%s”, protocol);

–

> sprintf(envp[envc++], “PROTOCOL=%.20s”,

protocol); 500c500

< envp[envc] = NULL;

–

Видно, что в первой версии программы axspawn.c используется функция sprintf без всяких ограничений на длину выводимой строки данных, а во второй – введено ограничение на длину выводимой строки в спецификации преобразования. В некоторых случаях производитель может выпустить патч, который будет сообщать отличия между двумя версиями программы. Обычно такие патчи выпускаются для операционных систем типа BSD (BSD – Berkeley Software Design Incorporated – компания-разработчик программного обеспечения), например FreeBSD. В январе 2002 года была найдена уязвимость в пакете инструментальных средств операционной системы FreeBSD. До ее устранения пользователь мог извлечь данные во временную директорию и изменить их. До тех пор, пока уязвимость не была всесторонне изучена, патч pkg_add сообщал точное местонахождение уязвимости:

– usr.sbin/pkg_install/lib/pen.c 17 May 2001 12:33:39 -0000

+++ usr.sbin/pkg_install/lib/pen.c 7 Dec 2001 20:58:46 -0000

@@ -106,7 +106,7 @@

cleanup(0);

errx(2, __FUNCTION__ “: can’t mktemp “%s””, pen);

}

– if (chmod(pen, 0755) == FAIL) {

+ if (chmod(pen, 0700) == FAIL) {

cleanup(0);

errx(2, __FUNCTION__ “: can’t mkdir “%s””, pen);

Удаляемая патчем часть исходного текста обозначена знаком минус (-), а добавляемая – знаком плюс (+). Можно увидеть, что часть исходного текста, содержащая код создания директории с разрешениями 0755, заменяется на код, создающий директорию с разрешениями 0700.

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

Анализ двоичного кода

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

Один из методов определения потенциальных уязвимостей заключается в трассировке выполнения программы. Для трассировки используется различный инструментарий. Для этой цели в системе Solaris применяется специальный пакет программ truss компании Sun. В других операционных системах используются аналогичные программы, например strace для Linux.

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

Использование трассировки позволяет определить, где и когда проявится уязвимость в исследуемой программе.

Применение отладчиков – еще один способ поиска уязвимостей. Отладчики позволяют выявить ошибки программы во время ее выполнения. На практике применяются различные отладчики. Gnu Debugger (GDB) – один из наиболее известных среди них.

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

Другой способ аудита двоичного кода заключается в анализе принятых соглашений и документов по разработке программ (которые не следует путать с исходным кодом программ). Материалы по разработке программ обычно представляются в виде диаграмм, информационных листов или спецификаций, как, например, RFC (Requests for Comments – запросы на комментарии, серия документов IETF, первые упоминания о которой относятся к 1969 году. Документы этой серии содержат описания протоколов Internet и связанную с ними информацию).

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

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

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

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