Из Википедии, бесплатной энциклопедии
  (Перенаправлено с Fuzzer )
Перейти к навигации Перейти к поиску
Часть серии по
Информационная безопасность
Связанные категории безопасности
Угрозы
Защиты
  • Обнаружение аномалий
  • Контроль доступа к компьютеру
  • Безопасность приложений
    • Программа-антивирус
    • Программное обеспечение компьютерной безопасности
    • Безопасное кодирование
    • Безопасность по умолчанию
    • Безопасность благодаря дизайну
      • Случай неправильного использования
    • Операционная система, ориентированная на безопасность
  • Аутентификация
    • Многофакторная аутентификация
  • Авторизация
  • Безопасность, ориентированная на данные
  • Обфускация кода
  • Шифрование
  • Брандмауэр
  • Система обнаружения вторжений
    • Система обнаружения вторжений на основе хоста (HIDS)
  • Информация о безопасности и управление событиями
  • Мобильный безопасный шлюз
  • Самозащита рабочего приложения
  • Безопасность веб-приложений
  • v
  • т
  • е

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

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

История [ править ]

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

В этой нечеткой статье 1990 года также отмечалось отношение надежности к безопасности: «Во-вторых, одна из обнаруженных нами ошибок была вызвана той же практикой программирования, которая предоставила одну из дыр в безопасности Интернет-червю (ошибка« получает палец »). Мы обнаружили дополнительные ошибки, которые могут указывать на будущие бреши в безопасности ». (Имеется в виду червь Морриса, ноябрь 1988 г.)

Первоначальный проект Fuzz внес свой вклад в 1995, 2000, 2006 и последний раз в 2020 году:

  • 1995: [5] Статья о «пересмотре пуха» состояла из четырех частей. (1) Воспроизведено исходное исследование командной строки, включая более широкий спектр систем UNIX и больше утилит. Исследование показало, что надежность даже ухудшилась. Это было первое исследование, которое включало GNU и Linux с открытым исходным кодом.Утилиты, которые, что интересно, были значительно более надежными, чем у коммерческих систем UNIX. (2) Введено нечеткое тестирование графических (оконных) приложений под X-Windows. В этом исследовании использовались как неструктурированные, так и структурированные (допустимые последовательности событий мыши и клавиатуры) входные данные. Им удалось вывести из строя 25% приложений X-Windows. Кроме того, они протестировали сервер X-Windows и показали, что он устойчив к сбоям. (3) Введено нечеткое тестирование сетевых сервисов, опять же на основе структурированных тестовых входных данных. Ни одна из этих служб не вышла из строя. (4) Введено случайное тестирование возвращаемых значений вызовов системной библиотеки, в частности случайное возвращение нуля из семейства функций malloc. Почти половина стандартных программ UNIX не могла должным образом проверить такие возвращаемые значения.
  • 2000: [6] Применял нечеткое тестирование к недавно выпущенной операционной системе Windows NT , тестируя приложения, работающие в оконной системе Win32 . Они смогли вывести из строя 21% приложений и зависнуть еще 24% протестированных. И снова приложения тестировались как с неструктурированным, так и с структурированным вводом (допустимые события клавиатуры и мыши), что привело к сбою почти половины тестируемых приложений. Они определили причины сбоев и пришли к выводу, что они аналогичны предыдущим исследованиям.
  • 2006: [7] Применял нечеткое тестирование к Mac OS X как для командной строки, так и для оконных приложений. Они протестировали 135 служебных программ командной строки, что привело к аварийному завершению работы 7% из протестированных. Кроме того, они протестировали 30 приложений, работающих под оконной системой MacOS Aqua , потеряв 73% из протестированных.
  • 2020: [8] Совсем недавно они применили классическое тестирование поколений, «черный ящик», неструктурированное тестирование для текущих систем UNIX, особенно Linux, FreeBSD и MacOS, чтобы проверить, актуальны ли оригинальные методы и устойчивы ли текущие служебные программы к этому типу. тестирования. Они протестировали примерно 75 утилит на каждой платформе, с частотой отказов 12% в Linux, 16% в MacOS и 19% в FreeBSD. (Обратите внимание, что эти отказы были хужечем результаты более раннего тестирования тех же систем.) Когда они проанализировали каждый сбой и классифицировали его, они обнаружили, что классические категории сбоев, такие как ошибки указателя и массива и отсутствие проверки кодов возврата, все еще широко присутствовали в новых результатах . Кроме того, новые причины отказа возникают из-за сложного состояния программы и алгоритмов, которые не масштабируются с размером или сложностью ввода. Они также протестировали утилиты UNIX, написанные совсем недавно на Rust, и обнаружили, что они имеют такую ​​же надежность, что и написанные на C, хотя (как и ожидалось) с меньшей вероятностью будут иметь ошибки памяти.

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

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

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

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

В сентябре 2016 года Microsoft анонсировала Project Springfield, облачный сервис нечеткого тестирования для поиска критических с точки зрения безопасности ошибок в программном обеспечении. [19]

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

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

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

Раннее случайное тестирование [ править ]

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

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

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

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

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

Типы [ править ]

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

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

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

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

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

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

Знает о структуре ввода [ править ]

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

Интеллектуальный фаззер (на основе модели, [34], грамматики, [33] [35] или протокола [36] ) использует входную модель для генерации большей доли действительных входных данных. Например, если входные данные можно смоделировать как абстрактное синтаксическое дерево , тогда интеллектуальный фаззер на основе мутаций [35] будет использовать случайные преобразования для перемещения полных поддеревьев от одного узла к другому. Если входные данные можно смоделировать с помощью формальной грамматики , фаззер, основанный на умном генерации [33], будет создавать экземпляры производственных правил.для генерации входных данных, которые действительны с точки зрения грамматики. Однако, как правило, входная модель должна быть явно указана, что трудно сделать, если модель является частной, неизвестной или очень сложной. Если доступен большой корпус действительных и недопустимых входных данных, метод индукции грамматики , такой как алгоритм L * Angluin , сможет сгенерировать входную модель. [37] [38]

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

Зная о структуре программы [ править ]

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

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

Белый ящик fuzzer [40] [34] рычаги анализа программ для систематического увеличения охвата кода или достичь определенных мест критических программ. Например, SAGE [42] использует символическое выполнение для систематического исследования различных путей в программе. Если спецификация программы доступна, фаззер белого ящика может использовать методы тестирования на основе моделей.для генерации входных данных и проверки выходных данных программы на соответствие спецификации программы. Фаззер белого ящика может быть очень эффективным для выявления ошибок, которые прячутся глубоко в программе. Однако время, затрачиваемое на анализ (программы или ее спецификации), может стать непомерно высоким. Если фаззеру белого ящика требуется относительно слишком много времени для генерации входных данных, фаззер черного ящика будет более эффективным. [43] Следовательно, есть попытки объединить эффективность фаззеров черного ящика и эффективность фаззеров белого ящика. [44]

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

Использует [ редактировать ]

Нечеткое изображение используется в основном как автоматизированный метод выявления уязвимостей в критически важных для безопасности программах, которые могут быть использованы злонамеренно. [9] [19] [20] В более общем смысле фаззинг используется для демонстрации наличия ошибок, а не их отсутствия. Проведение кампании фаззинга в течение нескольких недель без обнаружения ошибки не означает, что программа работает правильно. [46] В конце концов, программа все еще может завершиться ошибкой для ввода, который еще не был выполнен; выполнение программы для всех входов непомерно дорого. Если цель состоит в том, чтобы доказать, что программа корректна для всех входных данных, должна существовать формальная спецификация и должны использоваться методы из формальных методов .

Выявление ошибок [ править ]

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

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

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

  • для обнаружения ошибок, связанных с памятью, таких как переполнение буфера и использование после освобождения (с помощью отладчиков памяти, таких как AddressSanitizer ),
  • для обнаружения состояний гонки и взаимоблокировок (ThreadSanitizer),
  • для обнаружения неопределенного поведения (UndefinedBehaviorSanitizer),
  • для обнаружения утечек памяти (LeakSanitizer) или
  • для проверки целостности потока управления (CFISanitizer).

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

Проверка отчетов статического анализа [ править ]

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

Безопасность браузера [ править ]

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

Набор инструментов [ править ]

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

Автоматическая сортировка ошибок [ править ]

Основная статья: Сортировка ошибок

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

  • Пригодный для использования
  • Возможно использование
  • Вероятно, не может быть использован, или
  • Неизвестный.

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

Автоматическая минимизация ввода [ править ]

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

См. Также [ править ]

  • Американский fuzzy lop (фаззер)
  • Конколическое тестирование
  • Обезьянье тестирование
  • Случайное тестирование
  • Ответственное раскрытие
  • Обнаружение ошибок во время выполнения
  • Тестирование безопасности
  • Дымовое тестирование (программное обеспечение)
  • Символическое исполнение
  • Системное тестирование
  • Автоматизация тестирования

Ссылки [ править ]

  1. ^ a b Джон Нейштадт (февраль 2008 г.). «Автоматизированное тестирование на проникновение с фаззингом белого ящика» . Microsoft . Проверено 14 мая 2009 .
  2. ↑ Бартон П. Миллер (сентябрь 1988 г.). «Список проектов CS736, осень 1998 г.» (PDF) . Департамент компьютерных наук, Университет Висконсин-Мэдисон . Проверено 30 декабря 2020 .
  3. ^ Бартон П. Миллер; Ларс Фредриксен; Брайан Со (декабрь 1990 г.). «Эмпирическое исследование надежности утилит UNIX» (PDF) . Коммуникации ACM .
  4. ^ "Fuzz-тестирование надежности приложений" . Университет Висконсин-Мэдисон . Проверено 30 декабря 2020 .
  5. ^ Бартон П. Миллер; Дэвид Коски; Cjin P. Lee; Вивекананда Маганти; Равби Мурти; Аджиткумар Натараджан; Джефф Стейдл (апрель 1995 г.). «Новый взгляд на Fuzz: повторный анализ надежности утилит и служб UNIX» (PDF) . Технический отчет по информатике № 1268, Университет Висконсин-Мэдисон .
  6. ^ Джастин Форрестер; Бартон П. Миллер (сентябрь 2000 г.). «Эмпирическое исследование устойчивости приложений Windows NT с использованием случайного тестирования» (PDF) . 4-й симпозиум USENIX по системам Windows .
  7. ^ Бартон П. Миллер; Грегори Кукси; Фредрик Мур (июль 2006 г.). «Эмпирическое исследование устойчивости приложений MacOS с использованием случайного тестирования» (PDF) . Первый международный семинар по случайному тестированию .
  8. ^ Бартон П. Миллер; Мэнсяо Чжан; Элиза Хейманн (2021 г.). «Актуальность классического Fuzz-тестирования: удалось ли это решить?» (PDF) . IEEE Transactions по разработке программного обеспечения .
  9. ^ a b «Объявление ClusterFuzz» . Проверено 9 марта 2017 .
  10. ^ Perlroth, Николь (25 сентября 2014). «Эксперты по безопасности ожидают, что программная ошибка Shellshock в Bash будет значительной» . Нью-Йорк Таймс . Проверено 25 сентября 2014 года .
  11. ^ Залевский, Михал (1 октября 2014). «Ошибка Bash: два других RCE, или как мы отказались от исходного исправления (CVE-2014-6277 и '78)» . Блог lcamtuf . Проверено 13 марта 2017 года .
  12. ^ Зельцер, Ларри (29 сентября 2014). «Shellshock делает Heartbleed незначительным» . ZDNet . Проверено 29 сентября 2014 года .
  13. ^ Бёк, Ханно. "Fuzzing: Wie man Heartbleed hätte finden können (на немецком языке)" . Golem.de (на немецком языке) . Проверено 13 марта 2017 года .
  14. ^ Бёк, Ханно. «Как можно было найти Heartbleed (на английском языке)» . Блог Ханно . Проверено 13 марта 2017 года .
  15. ^ «Поисковая машина Интернета вещей - устройства, все еще уязвимые для Heartbleed» . shodan.io . Проверено 13 марта 2017 года .
  16. ^ «Heartbleed Report (2017-01)» . shodan.io . Проверено 10 июля 2017 года .
  17. ^ Уокер, Майкл. «DARPA Cyber ​​Grand Challenge» . darpa.mil . Проверено 12 марта 2017 года .
  18. ^ «Mayhem занимает первое место в CGC» . Проверено 12 марта 2017 года .
  19. ^ a b «Объявление о проекте Спрингфилд» . 2016-09-26 . Проверено 8 марта 2017 .
  20. ^ a b c d "Объявление OSS-Fuzz" . Проверено 8 марта 2017 .
  21. ^ Кристофер Домас (август 2018). «РЕЖИМ БОГА РАЗБЛОКИРОВАН - Аппаратные бэкдоры в процессорах x86» . Проверено 3 сентября 2018 .
  22. ^ «Microsoft: Windows 10 усилена этими нечеткими инструментами безопасности - теперь они с открытым исходным кодом» . ZDNet . 15 сентября 2020.
  23. ^ «Фреймворк для тестирования фаззинга с открытым исходным кодом Microsoft» . InfoWorld . 17 сентября 2020.
  24. ^ Джеральд М. Вайнберг (2017-02-05). «Тестирование Fuzz и история Fuzz» . Проверено 6 февраля 2017 .
  25. ^ Джо В. Дюран; Симеон К. Нтафос (1981-03-09). Отчет о случайном тестировании . Icse '81. Труды Международной конференции по разработке программного обеспечения ACM SIGSOFT (ICSE'81). С. 179–183. ISBN 9780897911467.
  26. ^ Джо В. Дюран; Симеон К. Нтафос (1 июля 1984 г.). «Оценка случайного тестирования». IEEE Transactions по разработке программного обеспечения . IEEE Transactions по разработке программного обеспечения (TSE) (4): 438–444. DOI : 10.1109 / TSE.1984.5010257 . S2CID 17208399 . 
  27. ↑ Энди Херцфельд (2004). Революция в долине: безумно великая история создания Mac? . О'Рейли Пресс. ISBN 978-0596007195.
  28. ^ «Истории Macintosh: Обезьяны Жизни» . Folklore.org. 1999-02-22 . Проверено 28 мая 2010 .
  29. ^ "crashme" . CodePlex . Проверено 26 июня 2012 .
  30. ^ Майкл Саттон; Адам Грин; Педрам Амини (2007). Fuzzing: обнаружение уязвимости грубой силы . Эддисон-Уэсли. ISBN 978-0-321-44611-4.
  31. ^ Оффатт, Джефф; Сюй, Учжи (2004). «Создание тестовых примеров для веб-служб с использованием возмущения данных» . Практикум по тестированию, анализу и проверке веб-сервисов .
  32. ^ Реберт, Александр; Ча, Санг Кил; Авгеринос, Танассис; Фут, Джонатан; Уоррен, Дэвид; Гриеко, Густаво; Брамли, Дэвид (2014). «Оптимизация выбора семян для фаззинга» (PDF) . Труды 23-й конференции USENIX по безопасности симпозиума : 861–875.
  33. ^ a b c Патрис Годфройд; Адам Кизун; Михаил Юрьевич Левин. "Фаззинг белого ящика на основе грамматики" (PDF) . Microsoft Research.
  34. ^ a b c Ван-Туан Фам; Марсель Бёме; Абхик Ройчоудхури (07.09.2016). «Основанный на модели фаззинг белого ящика для двоичных файлов программ». Материалы 31-й Международной конференции IEEE / ACM по автоматизированной разработке программного обеспечения - ASE 2016 . Труды по автоматизированной разработке программного обеспечения (ASE'16). С. 543–553. DOI : 10.1145 / 2970276.2970316 . ISBN 9781450338455. S2CID  5809364 .
  35. ^ a b c "Персиковый фаззер" . Проверено 8 марта 2017 .
  36. ^ Грег Бэнкс; Марко Кова; Виктория Фельметсгер; Кевин Альмерот; Ричард Кеммерер; Джованни Винья. SNOOZE: к фаззеру сетевого протокола с отслеживанием состояния . Материалы конференции по информационной безопасности (ISC'06).
  37. ^ Осберт Bastani; Рахул Шарма; Алекс Айкен; Перси Лян (июнь 2017 г.). Синтез входных грамматик программы . Труды конференции ACM SIGPLAN по проектированию и реализации языков программирования (PLDI 2017). arXiv : 1608.01723 . Bibcode : 2016arXiv160801723B .
  38. ^ "VDA Labs - эволюционная система фаззинга" . Архивировано из оригинала на 2015-11-05 . Проверено 14 мая 2009 .
  39. ^ a b Ари Таканен; Джаред Д. Демотт; Чарльз Миллер (31 января 2018 г.). Фаззинг для тестирования безопасности программного обеспечения и обеспечения качества, второе издание . Артек Хаус. п. 15. ISBN 978-1-63081-519-6. доступен полный документ ( архивирован 19 сентября 2018 г.)
  40. ^ a b Виджай Ганеш; Тим Лик; Мартин Ринард (16 мая 2009 г.). «Направленный фаззинг белого ящика на основе искажений» . Материалы Международной конференции по программной инженерии ACM SIGSOFT (ICSE'09).
  41. ^ Ван, Т .; Wei, T .; Gu, G .; Цзоу, В. (май 2010 г.). TaintScope: ориентированный на контрольную сумму инструмент фаззинга для автоматического обнаружения уязвимостей программного обеспечения . Симпозиум IEEE 2010 г. по безопасности и конфиденциальности . С. 497–512. CiteSeerX 10.1.1.169.7866 . DOI : 10,1109 / SP.2010.37 . ISBN  978-1-4244-6894-2. S2CID  11898088 .
  42. ^ Патрис Годфройд; Михаил Юрьевич Левин; Дэвид Мольнар (2008-02-08). «Автоматизированное тестирование методом« белого ящика »» (PDF) . Труды симпозиума по сетям и распределенным системам (NDSS'08).
  43. ^ Марсель Бёме; Сумья Пол (2015-10-05). «Вероятностный анализ эффективности автоматизированного тестирования программного обеспечения». IEEE Transactions по разработке программного обеспечения . 42 (4): 345–360. DOI : 10.1109 / TSE.2015.2487274 . S2CID 15927031 . 
  44. ^ Ник Стивенс; Джон Гросен; Кристофер Саллс; Эндрю Датчер; Жоюй Ван; Якопо Корбетта; Ян Шошитаишвили; Кристофер Крюгель; Джованни Винья (24.02.2016). Бурильщик: Дополнение. Нечеткое изображение посредством выборочного символьного исполнения (PDF) . Труды симпозиума по сетям и распределенным системам (NDSS'16).
  45. ^ Марсель Бёме; Ван-Туан Фам; Абхик Ройчоудхури (28.10.2016). "Фаззинг серого ящика на основе покрытия как цепь Маркова". Фаззинг серого ящика на основе покрытия как цепь Маркова . Труды конференции ACM по компьютерной и коммуникационной безопасности (CCS'16). С. 1032–1043. DOI : 10.1145 / 2976749.2978428 . ISBN 9781450341394. S2CID  3344888 .
  46. ^ Гамлет, Ричард G .; Тейлор, Росс (декабрь 1990). «Тестирование перегородок не внушает доверия». IEEE Transactions по разработке программного обеспечения . 16 (12): 1402–1411. DOI : 10.1109 / 32.62448 .
  47. ^ Weyuker, Элейн J. (1 ноября 1982). «О тестировании нетестируемых программ» . Компьютерный журнал . 25 (4): 465–470. DOI : 10.1093 / comjnl / 25.4.465 .
  48. ^ Барр, граф Т .; Харман, Марк; Макминн, Фил; Шахбаз, Музаммил; Ю, Шин (1 мая 2015 г.). «Проблема Oracle в тестировании программного обеспечения: обзор» (PDF) . IEEE Transactions по разработке программного обеспечения . 41 (5): 507–525. DOI : 10.1109 / TSE.2014.2372785 . S2CID 7165993 .  
  49. ^ "Документация по компилятору Clang" . clang.llvm.org . Проверено 13 марта 2017 года .
  50. ^ "Параметры дезинфицирующего средства GNU GCC" . gcc.gnu.org . Проверено 13 марта 2017 года .
  51. ^ Орсо, Алессандро; Се, Тао (2008). BERT: поведенческое регрессионное тестирование . Материалы Международного семинара по динамическому анализу 2008 г. (WODA 2008) . ACM. С. 36–42. DOI : 10.1145 / 1401827.1401835 . ISBN 9781605580548. S2CID  7506576 .
  52. ^ МакКиман, Уильям М. (1998). «Дифференциальное тестирование программного обеспечения» (PDF) . Цифровой технический журнал . 10 (1): 100–107.
  53. ^ Бабич, Домагой; Мартиньони, Лоренцо; Маккамант, Стивен; Песня, Рассвет (2011). Статически управляемая динамическая автоматическая генерация тестов . Материалы Международного симпозиума 2011 года по тестированию и анализу программного обеспечения . ACM. С. 12–22. DOI : 10.1145 / 2001420.2001423 . ISBN 9781450305624. S2CID  17344927 .
  54. ^ a b Сестерхенн, Эрик; Вевер, Беренд-Ян; Орро, Микеле; Вервье, Маркус (19 сентября 2017 г.). «Белая книга по безопасности браузера» (PDF) . X41D SEC GmbH.
  55. ^ «Улучшения безопасности для Microsoft Edge (Microsoft Edge для ИТ-специалистов)» . Microsoft . 15 октября 2017 . Проверено 31 августа 2018 года .
  56. ^ "Инструменты сортировки CERT" . Подразделение CERT Института программной инженерии (SEI) Университета Карнеги-Меллона (CMU) . Проверено 14 марта 2017 года .
  57. ^ «Microsoft! Эксплуатационный анализатор сбоев» . CodePlex . Проверено 14 марта 2017 года .
  58. ^ «Сокращение тестового примера» . 2011-07-18.
  59. ^ "IBM Test Case Reduction Techniques" . 2011-07-18. Архивировано из оригинала на 2016-01-10 . Проверено 18 июля 2011 .
  60. ^ Зеллер, Андреас; Хильдебрандт, Ральф (февраль 2002 г.). «Упрощение и изоляция входа, вызывающего отказ» . IEEE Transactions по разработке программного обеспечения . 28 (2): 183–200. CiteSeerX 10.1.1.180.3357 . DOI : 10.1109 / 32.988498 . ISSN 0098-5589 . Проверено 14 марта 2017 года .  

Дальнейшее чтение [ править ]

  • Ари Таканен, Джаред Д. ДеМотт, Чарльз Миллер, Fuzzing for Software Security Testing and Quality Assurance , 2008, ISBN 978-1-59693-214-2 
  • Майкл Саттон, Адам Грин и Педрам Амини. Нечеткость: обнаружение уязвимости грубой силы , 2007, ISBN 0-321-44611-9 . 
  • Х. Поль, Экономически эффективная идентификация уязвимостей нулевого дня с помощью моделирования угроз и фаззинга , 2011 г.
  • Фабьен Дюшен, Обнаружение уязвимостей в Интернете с помощью эволюционного фаззинга с помощью вывода модели, 2014 г., докторская диссертация
  • Братус, С., Дарли, Т., Локасто, М., Паттерсон, М.Л., Шапиро, Р.Б., Шубина, А., Помимо установленных ошибок в «Доверие доверия»: граница обработки входных данных , Безопасность и конфиденциальность IEEE, том 12, Выпуск 1 (январь-февраль 2014 г.), стр. 83–87 - В основном подчеркивается, почему фаззинг работает так хорошо: потому что входными данными является управляющая программа интерпретатора.

Внешние ссылки [ править ]

  • Fuzzing Project , включает учебные пособия, список критически важных для безопасности проектов с открытым исходным кодом и другие ресурсы.
  • Fuzz Testing Университета Висконсина (исходный проект по фаззингу) .Источник статей и программное обеспечение для фаззинга.
  • Проектирование входов, вызывающих сбой программного обеспечения , видео конференции, включая нечеткое тестирование
  • Ссылка на группу безопасного программирования Университета Оулу (Финляндия)
  • Создание фреймворков фаззинга с учетом протокола