stringtranslate.com

Фаззинг

В программировании и разработке программного обеспечения фаззинг или фазз-тестирование — это метод автоматического тестирования программного обеспечения , который предполагает предоставление недействительных, неожиданных или случайных данных в качестве входных данных для компьютерной программы . Затем программа отслеживается на предмет исключений, таких как сбои , сбои встроенных утверждений кода или потенциальные утечки памяти . Обычно фаззеры используются для тестирования программ, принимающих структурированные входные данные. Эта структура указывается, например, в формате файла или протоколе и отличает действительный ввод от недействительного. Эффективный фаззер генерирует полувалидные входные данные, которые являются «достаточно валидными» в том смысле, что они не отклоняются напрямую анализатором, но создают неожиданное поведение глубже в программе и являются «достаточно недействительными», чтобы выявить угловые случаи , которые не были должным образом обработаны. с.

В целях безопасности входные данные, пересекающие границу доверия , часто являются наиболее полезными. [1] Например, более важно фаззинг кода, который обрабатывает загрузку файла любым пользователем, чем фаззинг кода, который анализирует файл конфигурации, доступный только привилегированному пользователю.

История

Термин «нечеткость» возник в результате классного проекта, выполненного осенью 1988 года [2] на курсе продвинутых операционных систем (CS736), который преподавал профессор Бартон Миллер в Университете Висконсина , результаты которого были впоследствии опубликованы в 1990 году. [3] fuzz-тестирование утилиты UNIX , предназначенной для автоматической генерации случайных входных данных и параметров командной строки для утилиты. Проект был разработан для проверки надежности программ командной строки UNIX путем выполнения большого количества случайных входных данных в быстрой последовательности до тех пор, пока они не завершатся сбоем. Команде Миллера удалось вывести из строя от 25 до 33 процентов протестированных ими утилит. Затем они отладили каждый из сбоев, чтобы определить причину, и классифицировали каждый обнаруженный сбой. Чтобы дать возможность другим исследователям проводить аналогичные эксперименты с другим программным обеспечением, исходный код инструментов, процедуры тестирования и необработанные данные результатов были обнародованы. [4] Этот ранний фаззинг теперь будет называться «черным ящиком», неструктурированным (тупым) фаззингом поколений.

В апреле 2012 года Google анонсировала ClusterFuzz, облачную инфраструктуру фаззинга для критически важных компонентов веб- браузера Chromium . [5] Исследователи безопасности могут загружать свои собственные фаззеры и получать награды за обнаружение ошибок, если ClusterFuzz обнаружит сбой в загруженном фаззере.

В сентябре 2014 года Shellshock [6] был раскрыт как семейство ошибок безопасности в широко используемой оболочке UNIX Bash ; большинство уязвимостей Shellshock были найдены с помощью фаззера AFL . [7] (Многие интернет-сервисы, такие как некоторые веб-серверы, используют Bash для обработки определенных запросов, что позволяет злоумышленнику заставить уязвимые версии Bash выполнять произвольные команды . Это может позволить злоумышленнику получить несанкционированный доступ к компьютеру. система. [8] )

В апреле 2015 года Ханно Бёк показал, как фаззер AFL мог обнаружить уязвимость Heartbleed 2014 года. [9] [10] ( Уязвимость Heartbleed была обнаружена в апреле 2014 года. Это серьезная уязвимость, которая позволяет злоумышленникам расшифровать зашифрованную связь . Уязвимость была случайно введена в OpenSSL , который реализует TLS и используется большинством серверов на В апреле 2016 года Shodan сообщила, что в апреле 2016 года все еще уязвимы 238 000 компьютеров, в январе 2017 года — 200 000. [ 12] ).

В августе 2016 года Агентство передовых оборонных исследовательских проектов (DARPA) провело финал первого Cyber ​​Grand Challenge — полностью автоматизированного соревнования по захвату флага , которое длилось 11 часов. [13] Целью была разработка автоматических защитных систем, которые могли бы обнаруживать, использовать и исправлять недостатки программного обеспечения в режиме реального времени . Фаззинг использовался как эффективная стратегия нападения для обнаружения недостатков в программном обеспечении противников. Он продемонстрировал огромный потенциал в автоматизации обнаружения уязвимостей. Победителем стала система под названием «Mayhem» [14] , разработанная командой ForAllSecure под руководством Дэвида Брамли .

В сентябре 2016 года Microsoft анонсировала Project Springfield — облачную службу фазз-тестирования для поиска критических ошибок безопасности в программном обеспечении. [15]

В декабре 2016 года Google анонсировала OSS-Fuzz, который позволяет непрерывно анализировать несколько критически важных для безопасности проектов с открытым исходным кодом. [16]

На конференции Black Hat 2018 Кристофер Домас продемонстрировал использование фаззинга для раскрытия существования скрытого RISC- ядра в процессоре. [17] Это ядро ​​смогло обойти существующие проверки безопасности для выполнения команд кольца 0 из кольца 3.

В сентябре 2020 года Microsoft выпустила OneFuzz — автономную платформу фаззинга как услуги, которая автоматизирует обнаружение ошибок в программном обеспечении . [18] Он поддерживает Windows и Linux. [19]

Раннее выборочное тестирование

Тестирование программ со случайными входными данными началось в 1950-х годах, когда данные еще хранились на перфокартах . [20] Программисты использовали перфокарты, извлеченные из мусора, или колоды карт со случайными числами в качестве входных данных для компьютерных программ. Если при выполнении выявлялось нежелательное поведение, значит, была обнаружена ошибка .

Выполнение случайных входных данных также называется случайным тестированием или тестированием на обезьянах .

В 1981 году Дюран и Нтафос официально исследовали эффективность тестирования программы со случайными входными данными. [21] [22] Хотя выборочное тестирование широко воспринималось как худший способ тестирования программы, авторы смогли показать, что это экономически эффективная альтернатива более систематическим методам тестирования.

В 1983 году Стив Кэппс из Apple разработал «The Monkey», [23] инструмент, который генерировал случайные входные данные для классических приложений Mac OS, таких как MacPaint . [24] Образное слово «обезьяна» относится к теореме о бесконечной обезьяне , которая гласит, что обезьяна, нажимающая случайным образом клавиши на клавиатуре пишущей машинки в течение бесконечного промежутка времени, в конечном итоге напечатает все произведения Шекспира. В случае тестирования обезьяна записывала определенную последовательность входных данных, которая вызывала сбой.

В 1991 году был выпущен инструмент Crashme, предназначенный для проверки надежности Unix и Unix-подобных операционных систем путем случайного выполнения системных вызовов со случайно выбранными параметрами. [25]

Типы

Фаззер можно разделить на несколько категорий: [26] [1]

  1. Фаззер может быть основан на генерации или мутации в зависимости от того, генерируются ли входные данные с нуля или путем изменения существующих входных данных.
  2. Фаззер может быть тупым (неструктурированным) или умным (структурированным) в зависимости от того, знает ли он структуру входных данных.
  3. Фаззер может быть белым, серым или черным ящиком, в зависимости от того, знает ли он структуру программы.

Повторное использование существующих входных семян

Фаззер на основе мутаций использует существующий набор начальных входных данных во время фаззинга. Он генерирует входные данные, изменяя (или, скорее, мутируя ) предоставленные начальные значения. [27] Например, при фаззинге библиотеки изображений libpng пользователь предоставляет набор допустимых файлов изображений PNG в качестве начальных значений, в то время как фаззер на основе мутаций модифицирует эти начальные значения для создания полувалидных вариантов каждого начального числа. Корпус исходных файлов может содержать тысячи потенциально похожих входных данных. Автоматический выбор исходного кода (или сокращение набора тестов) позволяет пользователям выбирать лучшие исходные данные, чтобы максимизировать общее количество ошибок, обнаруженных во время фазз-кампании. [28]

Фаззер на основе генерации генерирует входные данные с нуля. Например, интеллектуальный фаззер на основе генерации [29] использует входную модель, предоставленную пользователем, для генерации новых входных данных. В отличие от фаззеров, основанных на мутациях, фаззер на основе поколений не зависит от существования или качества набора исходных входных данных.

Некоторые фаззеры имеют возможность делать и то, и другое: генерировать входные данные с нуля и генерировать входные данные путем мутации существующих начальных чисел. [30]

Знание структуры ввода

Обычно фаззеры используются для генерации входных данных для программ, которые принимают структурированные входные данные, такие как файл , последовательность событий клавиатуры или мыши или последовательность сообщений . Эта структура отличает допустимый ввод, который принимается и обрабатывается программой, от недопустимого ввода, который программа быстро отклоняет. То, что представляет собой действительный ввод, может быть явно указано во входной модели. Примерами моделей ввода являются формальные грамматики , форматы файлов , GUI -модели и сетевые протоколы . Даже элементы, которые обычно не считаются входными, могут быть подвергнуты фаззингу, например, содержимое баз данных , разделяемая память , переменные среды или точное чередование потоков . Эффективный фаззер генерирует полувалидные входные данные, которые являются «достаточно действительными», чтобы они не были напрямую отклонены анализатором, и «достаточно недействительны», чтобы они могли подчеркивать крайние случаи и демонстрировать интересное поведение программы.

Умный (основанный на модели, [30] на основе грамматики, [29] [31] или на основе протокола [32] ) фаззер использует модель входных данных для генерации большей доли действительных входных данных. Например, если входные данные можно смоделировать как абстрактное синтаксическое дерево , то интеллектуальный фаззер на основе мутаций [31] будет использовать случайные преобразования для перемещения полных поддеревьев из одного узла в другой. Если входные данные можно смоделировать с помощью формальной грамматики , интеллектуальный фаззер на основе генерации [29] создаст экземпляры правил производства для генерации входных данных, действительных по отношению к грамматике. Однако, как правило, входная модель должна быть явно указана, что сложно сделать, если модель является частной, неизвестной или очень сложной. Если доступен большой массив действительных и недействительных входных данных, метод грамматической индукции , такой как алгоритм L* Англуина , сможет сгенерировать модель входных данных. [33] [34]

Тупой фаззер [35] [36] не требует входной модели и, таким образом, может использоваться для фаззинга более широкого спектра программ. Например, AFL — это тупой фаззер на основе мутаций, который изменяет исходный файл , переворачивая случайные биты , заменяя случайные байты «интересными» значениями, а также перемещая или удаляя блоки данных. Однако тупой фаззер может сгенерировать меньшую долю допустимых входных данных и подвергнуть нагрузке код синтаксического анализатора , а не основные компоненты программы. Недостаток «тупых» фаззеров можно проиллюстрировать посредством построения допустимой контрольной суммы для проверки циклическим избыточным кодом (CRC). CRC — это код обнаружения ошибок , который гарантирует сохранение целостности данных, содержащихся во входном файле, во время передачи . Контрольная сумма вычисляется по входным данным и записывается в файл. Если программа обрабатывает полученный файл и записанная контрольная сумма не совпадает с повторно вычисленной контрольной суммой, то файл отклоняется как недействительный. Теперь фаззер, который не знает о CRC, вряд ли сгенерирует правильную контрольную сумму. Тем не менее, предпринимаются попытки идентифицировать и перевычислить потенциальную контрольную сумму в измененных входных данных после того, как тупой фаззер, основанный на мутациях, изменил защищенные данные. [37]

Знание структуры программы

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

Фаззер черного ящика [35] [31] рассматривает программу как черный ящик и не знает о внутренней структуре программы. Например, инструмент случайного тестирования , который генерирует входные данные случайным образом, считается фаззером черного ящика. Следовательно, фаззер черного ящика может выполнять несколько сотен входных данных в секунду, его можно легко распараллелить и масштабировать для программ произвольного размера. Однако фаззеры «черного ящика» могут лишь коснуться поверхности и выявить «неглубокие» ошибки. Следовательно, предпринимаются попытки разработать фаззеры черного ящика, которые могут постепенно узнавать о внутренней структуре (и поведении) программы во время фаззинга, наблюдая за выходными данными программы с учетом входных данных. Например, LearnLib использует активное обучение для создания автомата , который отражает поведение веб-приложения.

Фаззер белого ящика [ 36] [30] использует анализ программы для систематического увеличения покрытия кода или достижения определенных критических мест программы. Например, SAGE [38] использует символическое выполнение для систематического исследования различных путей в программе (метод, известный как конколическое выполнение ). Если спецификация программы доступна, фаззер белого ящика может использовать методы тестирования на основе моделей для генерации входных данных и проверки выходных данных программы на соответствие спецификации программы. Фаззер «белого ящика» может быть очень эффективным при выявлении ошибок, спрятанных глубоко в программе. Однако время, затрачиваемое на анализ (программы или ее спецификации), может оказаться непомерно высоким. Если фаззеру «белого ящика» требуется слишком много времени для генерации входных данных, фаззер «черного ящика» будет более эффективным. [39] Следовательно, предпринимаются попытки объединить эффективность фаззеров черного ящика и эффективность фаззеров белого ящика. [40]

Фаззер серого ящика использует инструменты , а не анализ программы, чтобы собрать информацию о программе. Например, AFL и libFuzzer используют облегченные инструменты для отслеживания базовых переходов блоков, выполняемых входными данными. Это приводит к разумным затратам на производительность, но информирует фаззер об увеличении покрытия кода во время фаззинга, что делает фаззеры серого ящика чрезвычайно эффективными инструментами обнаружения уязвимостей. [41]

Использование

Фаззинг используется в основном как автоматизированный метод выявления уязвимостей в критически важных для безопасности программах, которые могут быть использованы со злыми намерениями. [5] [15] [16] В более общем плане фаззинг используется для демонстрации наличия ошибок, а не их отсутствия. Проведение фаззинговой кампании в течение нескольких недель без обнаружения ошибки не доказывает правильность программы. [42] В конце концов, программа все равно может выйти из строя из-за ввода, который еще не был выполнен; выполнение программы для всех входов непомерно дорого. Если цель состоит в том, чтобы доказать, что программа корректна для всех входных данных, должна существовать формальная спецификация и использоваться методы формальных методов .

Выявление ошибок

Чтобы выявлять ошибки, фаззер должен уметь отличать ожидаемое (нормальное) поведение программы от неожиданного (ошибочного). Однако машина не всегда может отличить ошибку от функции. В автоматизированном тестировании программного обеспечения это также называется проблемой тестового оракула . [43] [44]

Обычно фаззер различает входные данные со сбоем и без сбоя при отсутствии спецификаций и использовании простых и объективных мер. Сбои можно легко идентифицировать и они могут указывать на потенциальные уязвимости (например, отказ в обслуживании или выполнение произвольного кода ). Однако отсутствие сбоя не означает отсутствие уязвимости. Например, программа, написанная на C , может аварийно завершиться, а может и не завершиться, когда ввод вызывает переполнение буфера . Скорее поведение программы не определено .

Чтобы сделать фаззер более чувствительным к сбоям, отличным от сбоев, можно использовать дезинфицирующие средства для внедрения утверждений, которые приводят к сбою программы при обнаружении сбоя. [45] [46] Для разных видов насекомых существуют разные дезинфицирующие средства:

Фаззинг также можно использовать для обнаружения «дифференциальных» ошибок, если доступна эталонная реализация . Для автоматического регрессионного тестирования [ 47] сгенерированные входные данные выполняются в двух версиях одной и той же программы. Для автоматического дифференциального тестирования [48] сгенерированные входные данные выполняются в двух реализациях одной и той же программы (например, Lighttpd и httpd являются реализациями веб-сервера). Если два варианта выдают разные выходные данные для одного и того же ввода, то один из них может быть ошибочным и его следует изучить более внимательно.

Проверка отчетов статического анализа

Статический анализ программы анализирует программу без ее фактического выполнения. Это может привести к ложным срабатываниям , когда инструмент сообщает о проблемах с программой, которых на самом деле не существует. Фаззинг в сочетании с динамическим анализом программы можно использовать, чтобы попытаться сгенерировать входные данные, которые действительно свидетельствуют о сообщенной проблеме. [49]

Безопасность браузера

Современные веб-браузеры подвергаются обширному фаззингу. Код Chromium Google Chrome постоянно анализируется командой безопасности Chrome с помощью 15 000 ядер. [50] Для Microsoft Edge и Internet Explorer во время разработки продукта Microsoft провела нечеткое тестирование с использованием 670 машино-лет, создав более 400 миллиардов манипуляций с DOM из 1 миллиарда HTML-файлов. [51] [50]

Инструментальная цепочка

Фаззер производит большое количество входных данных за относительно короткое время. Например, в 2016 году проект Google OSS-fuzz вводил около 4 триллионов входных данных в неделю. [16] Таким образом, многие фаззеры предоставляют набор инструментов , который автоматизирует рутинные и утомительные задачи, которые следуют за автоматическим генерированием входных данных, вызывающих сбои.

Автоматическая сортировка ошибок

Автоматическая сортировка ошибок используется для группировки большого количества входных данных, вызывающих сбои, по основной причине и для определения приоритета каждой отдельной ошибки по серьезности. Фаззер выдает большое количество входных данных, и многие из них, вызывающие сбой, могут эффективно выявить одну и ту же программную ошибку . Лишь некоторые из этих ошибок являются критическими для безопасности и должны быть исправлены с более высоким приоритетом. Например, Координационный центр CERT предоставляет инструменты сортировки Linux, которые группируют входные данные о сбоях по созданной трассировке стека и перечисляет каждую группу в соответствии с вероятностью их использования . [52] Центр исследования безопасности Microsoft (MSEC) разработал инструмент !exploitable, который сначала создает хеш для входных данных о сбое, чтобы определить его уникальность, а затем присваивает рейтинг уязвимости: [53]

Ранее не сообщавшиеся об ошибках, прошедших сортировку, могут быть автоматически отправлены в систему отслеживания ошибок . Например, OSS-Fuzz проводит крупномасштабные и длительные кампании по фаззингу для нескольких критически важных для безопасности программных проектов, где о каждой ранее не сообщаемой отдельной ошибке сообщается непосредственно в систему отслеживания ошибок. [16] Система отслеживания ошибок OSS-Fuzz автоматически информирует сопровождающего об уязвимом программном обеспечении и через регулярные промежутки времени проверяет, исправлена ​​ли ошибка в самой последней версии, используя загруженные минимизированные входные данные, вызывающие сбои.

Автоматическая минимизация ввода

Автоматическая минимизация входных данных (или сокращение тестовых примеров) — это метод автоматической отладки , позволяющий изолировать ту часть входных данных, вызывающих сбой, которая на самом деле вызывает сбой. [54] [55] Если вводимые данные, вызывающие сбой, велики и в основном имеют неверный формат, разработчику может быть сложно понять, что именно вызывает ошибку. Учитывая входные данные, вызывающие сбой, автоматический инструмент минимизации удалит как можно больше входных байтов, воспроизводя при этом исходную ошибку. Например, дельта-отладка — это автоматизированный метод минимизации входных данных, который использует расширенный алгоритм двоичного поиска для поиска таких минимальных входных данных. [56]

Список популярных фаззеров

Ниже приводится список фаззеров, описанных в академической литературе как «популярные», «широко используемые» или аналогичные. [57] [58]

Смотрите также

Рекомендации

  1. ^ аб Джон Нейштадт (февраль 2008 г.). «Автоматическое тестирование на проникновение с фаззингом белого ящика». Майкрософт . Проверено 14 мая 2009 г.
  2. ^ Бартон П. Миллер (сентябрь 1988 г.). «Список проектов CS736 осенью 1988 г.» (PDF) . Факультет компьютерных наук Университета Висконсин-Мэдисон . Проверено 30 декабря 2020 г.
  3. ^ Бартон П. Миллер; Ларс Фредриксен; Брайан Со (декабрь 1990 г.). «Эмпирическое исследование надежности утилит UNIX». Коммуникации АКМ . 33 (11): 32–44. дои : 10.1145/96267.96279 . S2CID  14313707.
  4. ^ «Нечеткое тестирование надежности приложений» . Университет Висконсин-Мэдисон . Проверено 30 декабря 2020 г.
  5. ^ ab «Анонс ClusterFuzz» . Проверено 9 марта 2017 г.
  6. ↑ Перлрот, Николь (25 сентября 2014 г.). «Эксперты по безопасности ожидают, что программная ошибка Shellshock в Bash будет серьезной». Нью-Йорк Таймс . Проверено 25 сентября 2014 г.
  7. ↑ Залевский, Михал (1 октября 2014 г.). «Ошибка Bash: два других RCE, или как мы сократили исходное исправление (CVE-2014-6277 и '78)». Блог lcamtuf . Проверено 13 марта 2017 г. .
  8. ↑ Зельцер, Ларри (29 сентября 2014 г.). «Shellshock заставляет Heartbleed выглядеть незначительным». ЗДНет . Проверено 29 сентября 2014 г.
  9. ^ Бёк, Ханно. «Фуззинг: Wie man Heartbleed hätte finden können (на немецком языке)». Golem.de (на немецком языке) . Проверено 13 марта 2017 г. .
  10. ^ Бёк, Ханно. «Как можно было найти Heartbleed (на английском языке)». Блог Ханно . Проверено 13 марта 2017 г.
  11. ^ «Поисковая система Интернета вещей – устройства все еще уязвимы для Heartbleed» . shodan.io . Проверено 13 марта 2017 г.
  12. ^ "Отчет о кровотечении из сердца (2017-01)" . shodan.io . Проверено 10 июля 2017 г.
  13. ^ Уокер, Майкл. «Грандиозный кибер-вызов DARPA». darpa.mil . Проверено 12 марта 2017 г.
  14. ^ «Mayhem занимает первое место в CGC» . Проверено 12 марта 2017 г.
  15. ^ ab «Анонс проекта Спрингфилд». 26 сентября 2016 г. Проверено 8 марта 2017 г.
  16. ^ abcd «Анонс OSS-Fuzz» . Проверено 8 марта 2017 г.
  17. ^ Кристофер Домас (август 2018 г.). «РЕЖИМ БОГА РАЗБЛОКИРОВАН — Аппаратные бэкдоры в процессорах x86» . Проверено 3 сентября 2018 г.
  18. ^ «Microsoft: Windows 10 усилена этими непонятными инструментами безопасности - теперь они с открытым исходным кодом» . ЗДНет . 15 сентября 2020 г.
  19. ^ «Среда тестирования фаззинга с открытым исходным кодом Microsoft» . Инфомир . 17 сентября 2020 г.
  20. ^ Джеральд М. Вайнберг (5 февраля 2017 г.). «Нечеткое тестирование и история фаззинга» . Проверено 06 февраля 2017 г.
  21. ^ Джо В. Дюран; Симеон К. Нтафос (9 марта 1981 г.). Отчет о случайном тестировании. Айсе '81. Материалы Международной конференции ACM SIGSOFT по программной инженерии (ICSE'81). стр. 179–183. ISBN 9780897911467.
  22. ^ Джо В. Дюран; Симеон К. Нтафос (1 июля 1984 г.). «Оценка случайного тестирования». Транзакции IEEE по разработке программного обеспечения . Транзакции IEEE по разработке программного обеспечения (TSE) (4): 438–444. дои : 10.1109/TSE.1984.5010257. S2CID  17208399.
  23. ^ Энди Херцфельд (2004). Революция в долине: безумно великая история о том, как был создан Mac? . О'Рейли Пресс. ISBN 978-0596007195.
  24. ^ «Истории Macintosh: Обезьяна жива» . Фольклор.орг. 22 февраля 1999 г. Проверено 28 мая 2010 г.
  25. Ссылки _ КодПлекс . Проверено 21 мая 2021 г.
  26. ^ Майкл Саттон; Адам Грин; Педрам Амини (2007). Фаззинг: обнаружение уязвимостей методом грубой силы . Аддисон-Уэсли. ISBN 978-0-321-44611-4.
  27. ^ Оффатт, Джефф; Сюй, Учжи (2004). «Создание тестовых примеров для веб-сервисов с использованием искажения данных». Семинар по тестированию, анализу и верификации веб-сервисов . 29 (5): 1–10. дои : 10.1145/1022494.1022529. S2CID  52854851.
  28. ^ Реберт, Александр; Ча, Санг Киль; Авгеринос, Танассис; Фут, Джонатан; Уоррен, Дэвид; Греко, Густаво; Брамли, Дэвид (2014). «Оптимизация выбора начального числа для фаззинга» (PDF) . Материалы 23-й конференции USENIX по симпозиуму по безопасности : 861–875.
  29. ^ abc Патрис Годфруа; Адам Киезун; Майкл Ю. Левин. «Фаззинг белого ящика на основе грамматики» (PDF) . Исследования Майкрософт.
  30. ^ abc Ван-Туан Фам; Марсель Бёме; Абхик Ройчоудхури (07 сентября 2016 г.). «Фаззинг белого ящика на основе моделей для двоичных файлов программ». Материалы 31-й Международной конференции IEEE/ACM по автоматизированной разработке программного обеспечения — ASE 2016 . Труды по автоматизированной разработке программного обеспечения (ASE'16). стр. 543–553. дои : 10.1145/2970276.2970316. ISBN 9781450338455. S2CID  5809364.
  31. ^ abc "Персиковый фаззер" . Проверено 8 марта 2017 г.
  32. ^ Грег Бэнкс; Марко Кова; Виктория Фельметсгер; Кевин Альмерот; Ричард Кеммерер; Джованни Винья. SNOOZE: на пути к фаззеру сетевых протоколов с отслеживанием состояния. Материалы конференции по информационной безопасности (ISC'06).
  33. ^ Осберт Бастани; Рахул Шарма; Алекс Эйкен; Перси Лян (июнь 2017 г.). Синтез грамматик ввода программы . Материалы конференции ACM SIGPLAN по проектированию и реализации языков программирования (PLDI 2017). arXiv : 1608.01723 . Бибкод : 2016arXiv160801723B.
  34. ^ «Лаборатории VDA - Система эволюционного фаззинга» . Архивировано из оригинала 05.11.2015 . Проверено 14 мая 2009 г.
  35. ^ аб Ари Таканен; Джаред Д. Демотт; Чарльз Миллер (31 января 2018 г.). Фаззинг для тестирования безопасности и обеспечения качества программного обеспечения, второе издание. Артех Хаус. п. 15. ISBN 978-1-63081-519-6.доступен полный документ (архивировано 19 сентября 2018 г.)
  36. ^ аб Виджай Ганеш; Тим Лик; Мартин Ринар (16 мая 2009 г.). «Направленный фаззинг белого ящика на основе Taint». ИИЭЭ . Материалы Международной конференции ACM SIGSOFT по программной инженерии (ICSE'09).
  37. ^ Ван, Т.; Вэй, Т.; Гу, Г.; Цзоу, В. (май 2010 г.). «TaintScope: инструмент направленного фаззинга с учетом контрольной суммы для автоматического обнаружения уязвимостей программного обеспечения». Симпозиум IEEE 2010 по безопасности и конфиденциальности . стр. 497–512. CiteSeerX 10.1.1.169.7866 . дои :10.1109/СП.2010.37. ISBN  978-1-4244-6894-2. S2CID  11898088.
  38. ^ Патрис Годфруа; Майкл Ю. Левин; Дэвид Молнар (8 февраля 2008 г.). «Автоматическое нечеткое тестирование Whitebox» (PDF) . Материалы симпозиума по сетям и распределенным системам (NDSS'08).
  39. ^ Марсель Бёме; Сумья Пол (05.10.2015). «Вероятностный анализ эффективности автоматизированного тестирования программного обеспечения». Транзакции IEEE по разработке программного обеспечения . 42 (4): 345–360. дои :10.1109/TSE.2015.2487274. S2CID  15927031.
  40. ^ Ник Стивенс; Джон Грозен; Кристофер Саллс; Эндрю Датчер; Жоюй Ван; Якопо Корбетта; Ян Шошитаишвили; Кристофер Крюгель; Джованни Винья (24 февраля 2016 г.). Бурильщик: Дополняю. Фаззинг посредством выборочного символического выполнения (PDF) . Материалы симпозиума по сетям и распределенным системам (NDSS'16).
  41. ^ Марсель Бёме; Ван-Туан Фам; Абхик Ройчоудхури (28 октября 2016 г.). «Фаззинг Greybox на основе покрытия как цепь Маркова». Материалы конференции ACM SIGSAC 2016 г. по компьютерной и коммуникационной безопасности . Материалы конференции ACM по компьютерной и коммуникационной безопасности (CCS'16). стр. 1032–1043. дои : 10.1145/2976749.2978428. ISBN 9781450341394. S2CID  3344888.
  42. ^ Гамлет, Ричард Г.; Тейлор, Росс (декабрь 1990 г.). «Тестирование разделов не внушает доверия». Транзакции IEEE по разработке программного обеспечения . 16 (12): 1402–1411. дои : 10.1109/32.62448.
  43. ↑ Вейкер, Элейн Дж. (1 ноября 1982 г.). «О тестировании нетестируемых программ». Компьютерный журнал . 25 (4): 465–470. дои : 10.1093/comjnl/25.4.465 .
  44. ^ Барр, Эрл Т.; Харман, Марк; Макминн, Фил; Шахбаз, Музаммил; Ю, Шин (1 мая 2015 г.). «Проблема Oracle в тестировании программного обеспечения: опрос» (PDF) . Транзакции IEEE по разработке программного обеспечения . 41 (5): 507–525. дои : 10.1109/TSE.2014.2372785 . S2CID  7165993.
  45. ^ «Документация компилятора Clang» . clang.llvm.org . Проверено 13 марта 2017 г. .
  46. ^ «Параметры дезинфицирующего средства GNU GCC» . gcc.gnu.org . Проверено 13 марта 2017 г. .
  47. ^ Орсо, Алессандро; Се, Тао (2008). "БЕРТ". Материалы международного семинара по динамическому анализу 2008 г.: проведенного совместно с Международным симпозиумом ACM SIGSOFT по тестированию и анализу программного обеспечения (ISSTA 2008) . АКМ. стр. 36–42. дои : 10.1145/1401827.1401835. ISBN 9781605580548. S2CID  7506576.
  48. ^ Маккиман, Уильям М. (1998). «Дифференциальное тестирование программного обеспечения» (PDF) . Цифровой технический журнал . 10 (1): 100–107.
  49. ^ Бабич, Домагой; Мартиньони, Лоренцо; МакКамант, Стивен; Песня, Рассвет (2011). «Статически-направленное динамическое автоматизированное создание тестов». Материалы Международного симпозиума по тестированию и анализу программного обеспечения 2011 г. АКМ. стр. 12–22. дои : 10.1145/2001420.2001423. ISBN 9781450305624. S2CID  17344927.
  50. ^ аб Сестерхенн, Эрик; Вевер, Беренд-Ян; Орру, Микеле; Вервье, Маркус (19 сентября 2017 г.). «Информационный документ по безопасности браузера» (PDF) . X41D SEC GmbH.
  51. ^ «Усовершенствования безопасности для Microsoft Edge (Microsoft Edge для ИТ-специалистов)» . Майкрософт . 15 октября 2017 г. Проверено 31 августа 2018 г.
  52. ^ "Инструменты сортировки CERT" . Подразделение CERT Института программной инженерии (SEI) Университета Карнеги-Меллон (CMU) . Проверено 14 марта 2017 г.
  53. ^ "Microsoft! Exploitable Crash Analyzer" . КодПлекс . Проверено 14 марта 2017 г.
  54. ^ «Сокращение тестовых примеров» . 18 июля 2011 г.
  55. ^ «Методы сокращения тестовых случаев IBM» . 18 июля 2011 г. Архивировано из оригинала 10 января 2016 г. Проверено 18 июля 2011 г.
  56. ^ Целлер, Андреас; Хильдебрандт, Ральф (февраль 2002 г.). «Упрощение и изоляция входных данных, вызывающих сбои». Транзакции IEEE по разработке программного обеспечения . 28 (2): 183–200. CiteSeerX 10.1.1.180.3357 . дои : 10.1109/32.988498. ISSN  0098-5589 . Проверено 14 марта 2017 г. 
  57. ^ Хазиме, Ахмад; Эррера, Адриан; Пайер, Матиас (15 июня 2021 г.). «Магма: эталон фаззинга на основе истины». Труды АКМ по измерению и анализу вычислительных систем . 4 (3): 49:1–49:29. arXiv : 2009.01120 . дои : 10.1145/3428334. S2CID  227230949.
  58. ^ Ли, Ювэй; Цзи, Шулин; Чен, Юань; Лян, Сычжуан; Ли, Вэй-Хан; Чен, Юэяо; Лю, Чэньян; У, Чуньмин; Бейя, Рахим; Ченг, Пэн; Лу, Канцзе; Ван, Тин (2021). {UNIFUZZ}: целостная и прагматичная {управляемая метриками} платформа для оценки фаззеров. стр. 2777–2794. ISBN 978-1-939133-24-3.
  59. ^ Хазиме, Herrera & Payer 2021, стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (AFL, ...)».
  60. ^ Ли и др. 2021, с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL,…».
  61. ^ Хазиме, Herrera & Payer 2021, стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (..., AFL++, ...)».
  62. ^ Ли и др. 2021, с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, AFLFast, ...».
  63. ^ Ли и др. 2021, с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL,..., Angora,...».
  64. ^ Хазиме, Herrera & Payer 2021, стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (..., honggfuzz, ...)».
  65. ^ Ли и др. 2021, с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL,..., Honggfuzz,...».
  66. ^ Ли и др. 2021, с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL,..., QSYM,...».
  67. ^ Хазиме, Herrera & Payer 2021, стр. 1: «Мы оцениваем семь широко используемых фаззеров на основе мутаций (... и SymCC-AFL)».
  68. ^ Хазиме, Herrera & Payer 2021, стр. 14.
  69. ^ Ли и др. 2021, с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL,..., T-Fuzz,...».
  70. ^ Ли и др. 2021, с. 1: «Используя UniFuzz, мы проводим углубленные оценки нескольких известных фаззеров, включая AFL, ... и VUzzer64».

дальнейшее чтение

Внешние ссылки