Поиск уязвимостей в программном обеспечении с использованием технологии поиска клонов кода (1133536), страница 2
Текст из файла (страница 2)
Далее с помощью методаdeserializePDGFromFile, создаются PDG для каждой функции. Аргументы метода отвечают за длину и алгоритм деления графов. Для выделения извсех функций программы с паттерном нужной вызывается метод getPattern,принимающий на вход строку – название нужной функции. Если PDG анализируемого проекта делятся, то оставшиеся графы проверяются на длинуметодом optimize и удаляются если имееют меньший размер. После удаления всех неподходящих PDG начинается анализ.
Кроме вышеперечисленныхпроектов проверялись более поздние версии nginx и libpng, в которых уязвимость была устранена. Также были созданы тесты, повторяющие функцио10нальность уязвимого кода, но с измененными инструкциями. PDG для взятых шаблонов приведены в приложениях A и B. Отвечающий им код описандалее:Buffer underrun:void pattern() {char *p="hello buffer", *c;c = p;while (*c != ’e’) {c--;}return 0;}Buffer overflow:void pattern() {char *src="buffer", *dst="overflow";int length = 10;strncpy(dst, src, length);return 0;}2.1Уязвимость в HTTP-сервере nginxВ проекте nginx рассматривалась уязвимость класса bufferunderflow (CVE-2009-2629), рассмотренная в статье [10].
Функцияngx_http_parse_complex_uri занимается разбором сложных URI и представляет собой конечный автомат. В состоянии sw_dot_dot, то есть приразборе двух точек подряд присутствует следующий код:case ’/’:state = sw_slash;u -= 4;if (u < r->uri.data) {return NGX_HTTP_PARSE_INVALID_REQUEST;}while (*(u - 1) != ’/’) {u--;}break;11где r->uri.data – выходной буфер обработанного URI, а u – указывает натекущий записываемый символ в этом буфере. Если перед началом цикла u== r->uri.data, то в цикле будет обращение к чужой памяти.
В данный caseможно попасть, обработав последовательность “//../“ при выключенном режиме merge_slashes. Это позволяет обойти проверку, что и приводит к bufferunderflow.2.2Уязвимость в библиотеке для работы срастровой графикой libpngУязвимость из библиотеки libpng класса buffer overflow (CVE-2004-0597) вфункции png_handle_tRNS:if (!(png_ptr->mode & PNG_HAVE_PLTE)) {png_warning(png_ptr, "Missing PLTE before tRNS");}else if (length > (png_uint_32)png_ptr->num_palette) {png_warning(png_ptr, "Incorrect tRNS chunk length");png_crc_finish(png_ptr, length);return;}...png_crc_read(png_ptr, readbuf, (png_size_t)length);Если не проходит проверка переменной png_ptr->mode, то управление переходит в ветку, в которой не проверяется переменная length.
Далее в этойфункции вызывается png_crc_read - функция, аналогичная strncpy, но таккак последний параметр может быть некорректным, то это потенциально ведет к переполнению буфера.12Глава 3РезультатыПри проверке проектов с неделимым на PDG шаблоном nginx, значимыерезультаты были получены только при параметре length равным 3. В этомслучае было найдено 53, 14, 13, 3, 11, 7 фрагментов схожих с паттерном дляпроектов nginx, libpng, openmpi, openssh, openssl соответственно.
При этомдля проекта nginx 8 результатов сопоставлялись именно небезопасному коду в шаблоне, но сам код не имел уязвимостей. Как и говорилось в секции1.3 такое количество обусловливается маленькой длиной поделенных PDG.При длинах 5 и 10 потенциальных уязвимостей практически не было найдено. Аналогично и для проекта libpng, при длине 3 количество найденныхсоответствий равнялось: 1, 0, 65(только 1 – с небезопасным кодом), 28(3),72(9). Стоит заметить, что даже в проектах с шаблоном самой уязвимостинебезопасный код в полном виде найден не был.Деление PDG с шаблоном дало лучшие показатели, но из-за огромного количества найденных фрагментов при длине 3, параметр length был равным5, 7 и 10. Причем при длине 7 в отличии от предыдущего случая было найдено59(18), 1, 10, 2, 0 частей подозрительного кода.
18 совпадений с небезопаснымкодом объясняется тем, что он представлял из себя цикл и под него попалимногие другие циклы. При длине 10 совпадения были только для самого проекта nginx – 25(11). Для второго шаблона результаты были только при длине5.
Сама уязвимость хоть и нашлась, но не полностью, то есть только та часть,которая вела к ней, но не исполняла. Зато проект nginx полностью соответствовал выполнению небезопасного кода. Для него результаты при длине 5таковы: 143(8 + уязвимость), 0, 15(2), 1(1), 2.Тесты так же показали лучшие результаты при деление PDG шаблона.Длина, при которой были найдены фрагменты, равнялась 2-м. Это связано стем, что из тестов была убрана вся лишняя часть и оставлена только та, которая повторяла функциональность взятого класса уязвимости. Для проектаnginx все 5 из 5 тестов были пройдены, что можно объяснить близкой расположенностью небезопасного кода в паттерне. В проекте libpng как раз из-за13относительно большого количества инструкций, оставленных в шаблоне, находились только 4 из 5 тестов.
Бо́льшую роль все-таки сыграло неполноекорректирование паттерна. В целом, похожие по функциональности участкибыли найдены.Были проверены проекты nginx и libpng версий 1.6.2 и 1.6.17 соответственно. В них уязвимости, из которых строился шаблон, устранены. Для первогосовпадения с небезопасным кодом были только при длинах 5 и 7, при деленииPDG паттерна.
Но они не соответствовали программному коду уязвимости,описанной в секции 2.1. Во втором проекте все оказалось проще: потенциальные уязвимости были только при длине 3, но деление PDG было отключено.Ни один фрагмент не был из исходного файла с уязвимостью. Далее приведены полные результаты анализа проектов.Таблица 3.1: Анализ уязвимости класса buffer underrunТаблица 3.2: Анализ уязвимости класса buffer underrun14Таблица 3.3: Анализ уязвимости класса buffer underrunТаблица 3.4: Анализ уязвимости класса buffer overflow15ЗаключениеВ процессе исследования подхода был изменен инструмент поиска клонов кода таким образом, что поиск изоморфных подграфов проводился недля каждой пары PDG, а только для графов из анализируемого проекта ипаттерна уязвимости.
Было добавлено выделение функции из набора PDG,которая использовалась для создания шаблона.В результате построения шаблона класса уязвимости из программ и использования инструмента для поиска клонов кода были найдены как подозрительные участки кода в других проектах, так и сами уязвимости. ДелениеPDG на подграфы сделало возможным выделение основного небезопасногокода из шаблона. Но в этом случае анализировалась только часть уязвимости, что привело к ложным срабатываниям. Исследование метода показало, что целостный PDG требует многих модификаций. Этот момент ещене доработан на данном этапе, поэтому результаты оказались не совпали сожиданиями.
Модифицирование PDG может быть улучшено в сторону автоматического выбора вершин, содержащих подозрительные инструкции, исоответствующих им ребер. Этот подход может быть реализован с помощьюобходов графа, описанных в статье [2].В целом, удалось выявить известные уязвимости, взятые за основу паттернов. Анализ разных по размеру проектов дал понимание того, какие параметры подавать на вход программе для наилучшего результата.
Тем неменее подход несовершенен и для более оптимистичных показателей требуетдальнейшего исследования.16Литература[1] S. B. Horwitz, T. W. Reps, and D. Binkley. Interprocedural slicing usingdependence graphs. University of Wisconsin-Madison. ACM Transactions onProgramming Languages and Systems (TOPLAS), стр. 26-60, Volume 12Issue 1, Jan.
1990.[2] Fabian Yamaguchi, Nico Goldey, Daniel Arp and Konrad Rieck. Modeling andDiscovering Vulnerabilities with Code Property Graphs. SP ’14 Proceedingsof the 2014 IEEE Symposium on Security and Privacy, стр. 590-604, May2014.[3] Sevak Sargsyan, Shamil Kurmangaleev, Andrey Belevantsev. LLVM: built-inscalable code clone detection based on semantic analysis. Institute for SystemProgramming of the Russian Academy of Sciences, FOSDEM, Feb. 2015.[4] Johannes Köbler, Sebastian Kuhnert, Osamu Watanabe. Interval graphrepresentation with given interval and intersection lengths. HumboldtUniversität zu Berlin, Inst. für Informatik.Tokyo Institute of Technology,Dept.
of Mathematical and Computing Sciences, 2012.[5] http://clang.llvm.org.clang: a C language family frontend for LLVM.[6] http://llvm.org.The LLVM Compiler Infrastructure.[7] Jens Krinke, Lehrstuhl Softwaresysteme Identifying Similar Code withProgram Dependence Graphs. Proceedings of the Eighth Working Conferenceon Reverse Engineering (WCRE’01). Universität Passau, Germany, 2001.[8] http://nginx.org/ru/.HTTP and reverse proxy server, mail proxy server and generic TCP proxyserver.[9] http://www.libpng.org/pub/png/libpng.html.The free reference library for reading and writing PNGs.17[10] Istvan Haller and Asia Slowinska, VU University Amsterdam; MatthiasNeugschwandtner, Vienna University of Technology; Herbert Bos, VUUniversity Amsterdam. Dowsing for Overflows: A Guided Fuzzer to FindBuffer Boundary Violations.
Proceedings of the 22nd USENIX SecuritySymposium, USA, Aug. 2013.18Приложение APDG шаблона bufferunderrun19Приложение BPDG шаблона buffer overflow20.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
