Для специалистов по ML есть платформа Kaggle, где они могут посоревноваться с другими командами в умении решать задачи с помощью ML и даже заработать денег. Для специалистов в области ИБ есть формат соревнований CTF (Capture the flag). Для специалистов в тестировании нет ни популярного формата таких соревнований ни какой-либо платформы. Расскажу о тех соревнованиях, про которые знаю. И то и друго находится на стыке ИБ и тестирования, но тем не менее.

Rode0day - каждый месяц публикуют набор исполняемых файлов с ошибками, за каждый найденный креш вы получаете баллы. В конце месяца анонсируется победитель с максимальным количеством баллов.

Марсель Беме (Marcel Böhme), известный (см. публикации) исследователь в области безопасности ПО, вместе с Google Open Source Security Team анонсировал другое соревнование, в котором надо написать фаззер с интерфейсом, как для libFuzzer, для программ на C/C++ и добиться максимального покрытия и количества найденных багов на примерах программ из бенчмарка FuzzBench. Подробное описание - https://github.com/mboehme/FuzzingCompetition/tree/mboehme-patch-1, регистрация - https://forms.gle/QZgUYysoBizeAKRu9 Учитывая исследовательские интересы Марселя ("One part of his group develops the probabilistic foundations of automatic software testing (i.e., finding bugs by generating executions) to elucidate fundamental limitations of existing techniques and to explore the assurances that software testing provides when no bugs are found.") его интерес к этому соревнованию понятен. Формат немного противоположный формату Rode0day, но от этого не менее интересный.

Помните SETI@home? Проект анализировал радиосигнал из космоса для поиска внеземного разума используя для этого вычислительные ресурсы добровольцев. По аналогии с SETI@Home есть проект Fuzzing@Home, в котором можно запускать фаззинг проектов, добавленных в OSS Fuzz, в обычном веб браузере. Это возможно благодаря компиляции в WebAssembly. Попробуйте сами - http://fuzzcoin.gtisc.gatech.edu:8000/

На следующей неделе пройдут две популярные конференции: Гейзенбаг (22 ноября) и Highload (24 и 25 ноября) . На обоих я буду выступать с докладами. На Гейзенбаге я расскажу про фаззинг вообще и про добавление поддержки скриптового языка в libFuzzer на примере Lua. На Highload я расскажу как о том, как тестируют компиляторы и о нашем опыте тестирования LuaJIT, там доклад в первый день и один из первых в расписании, поэтому приходите к самому началу, если хотите послушать. Приходите на мои доклады или подходите просто поболтать, ведь конференции для этого и придумали.

Сравнение библиотек для тестирования с помощью свойств в разных языках. (Не все библиотеки одинаково полезны.)

Материалы к докладу "Делаем фаззер для Lua на основе libFuzzer"

Примеры кода из доклада - https://github.com/ligurio/snippets/tree/master/heisenbug-2022

Все примеры можно запустить, см. комментарии в файлах:

- add_tests.py - тестирование функции сложения с помощью примеров, Hypothesis и Atheris
- trace-pc.c - пример инструментирования программы в Clang для предоставления обратной связи
- libfuzzer-example.c - пример фаззера для libFuzzer

Здесь опубликую модуль для фаззинга Lua - https://github.com/ligurio/luzer/

Слайды

Дополнительные ссылки:

Hypothesis - расширение для тестирования с помощью свойств в Python

Atheris - фаззер с обратной связью для Python на основе libFuzzer

lua-quickcheck - модуль для тестирования с помощью свойств в Lua

afl-lua - форк PUC Rio Lua для фаззинга Lua c помощью AFL

libFuzzer - библиотека для фаззинга кода С/C++

Пример интеграции Lua с AFL без изменения интерпретатора -
https://gist.github.com/stevenjohnstone/2236f632bb58697311cd01ea1cafbbc6
Будет работать, но не так эффективно, потому что не инструментируются полезные инструкции в Lua ВМ.

Доклад, в котором Tavis Ormandy описал идею использования обратной связи, чтобы сделать фаззинг эффективнее - "Making Software Dumber". Видео и слайды.

Доклад "ClusterFuzz: Fuzzing at Google Scale".

Материалы к моему докладу "О чём я говорю, когда говорю о тестировании корректности работы компиляторов"

Примеры кода к докладу - https://github.com/ligurio/snippets/tree/master/highload-2022

Слайды - https://bronevichok.ru/papers/2022-HighLoad-Testing-correctness-of-LuaJIT.pdf

Страница доклада Антона Солдатова "Как мы работаем над стабильностью нашей реализации Lua" на сайте конференции.

Тот самый баг, который Mike Pall закрыл как неприемлимый. Интересно, что он сначала написал про небезопасное выполнение недоверенного байткода в LuaJIT FAQ, а потом закрыл баг сославшись на эту часть FAQ.

Фаззеры для C/C++ компиляторов: CSmith и YARPGen
Слайды про YARPGen.

Попытки рандимизированного тестирования PUC Rio Lua:

- "NAUTILUS: Fishing for Deep Bugs with Grammars"
- "GRIMOIRE: Synthesizing Structure while Fuzzing"
- "Language-Agnostic Generation of Compilable Test Programs"

Материалы про фаззер для JavaScript - FuzzIL:
- Дипломная работа
- Доклад
- Принцип работы

Слайды про Alive2.
Слайды, диссертация и пейпер про Alive. Что интересно - авторы CSmith заметили, что чаще всего баги появляются в одной конкретной оптимизации InstCombine, и, чтобы фокусно тестировать эту оптимизацию, они решили проверить корректность оптимизаций с помощью LLVM IR и SMT-решателя. Вот ещё слайды про Alive.

Проект Cosetta.

Баг в PyPy, найденный с помощью SMT-решателя.

Можно по-разному относиться к продуктам компании 1С, но как бы вы к ним не относились, это платформа 1С это один из самых крупных софтверных проектов в нашей стране - около 10 миллионов строк исходного кода. Я посмотрел доклад от разработчика платформы 1С и вцелом у них всё так же как и у всех за исключением нескольких вещей.

Полный цикл тестирования занимает 3(!) недели. Если часть тестов падает, то тестирование прекращается и ресурсы освобождаются для тестирования других сборок. Тесты приоритезируются, в первую очередь запускаются тесты, отмеченные разработчиком, недавно упавшие и починенные, быстрые и важные тесты запускаются в порядке возрастания времени выполнения, и потом запускаются давно не падавшие тесты (то есть формальный признак стабильных тестов). Говорят про приоритезацию многие, реализуют единичные проекты. Особенно такого масштаба.

~100% функционального и нагрузочного тестирования автоматизировано.

Для части изменений в непрервывной интеграции используется инкрементальная сборка для экономии времени, для полного тестирования - сборка с нуля.

Для быстрого тестирования (чтобы понять нормальная сборка или нет) не запускают "долгоиграющие" тесты. Приоритезируют тестовые окружения: тесты запускают на PostgreSQL и не запускают на DB2 и Oracle, это даёт экономию времени выполнения около 1500 тестов, а интеграция с Oracle ломается примерно 1 раз в год. Вот о таких вещах очень трудно договариваться с продуктологами и менеджерами продукта. Обычно все переживают за свою пятую точку и рисковать не хотят.

Автоматизация бисекта коммита в случае упавшего теста использует ускоренную сборку в Visual Studio, когда новая версия библиотеки прилинковывается "сверху" к бинарю. Экономия: вместо 50 мин 3 минуты на сборку.

Ну и догфудинг: если функциональные и нагрузочные тесты прошли успешно, то новая версия используется для внутренних багтрекера и тасктрекера, для внутренней системы документооборота и для разработки бизнес-приложений. Для CI они используют Jenkins (тут я удивился, что не своя разработка, ведь могли бы).

Для нагрузочного тестирования используют Apache JMeter и собственное приложение "Тест-центр" на платформе 1С:Предприятие.

Для GUI используется свой инструмент визуального тестирования по принципу записи действий пользователя и картинки на экране, для WebUI - Selenium.

Для трекинга результатов тестирования используют Grafana и докладчик честно признался, что её функциональность можно реализовать на 1С, но они уже активно используют Grafana.

Так как у нас в Tarantool тоже свой рантайм, то некоторые вещи у нас с ними похожи: у нас тоже есть набор приложений, которые участвуют в интеграционном тестировании рантайма.

Вчера Яндекс опубликовал пост на Хабре про ПБЧ (профайлер бедного человека). Если не читали, то суть в следующем: они в продакшене используют GDB (Gnu Debugger) для семплирования потоков программы и из полученных данных генерируют флеймграфы, которые используют для анализа производительности ПО. Такое профилирование называется ПБЧ (poor man profile) и даже есть сайт, посвященный такому типу профилировщиков.

Продолжая тему, поднятую Яндексом, я продолжу рассказывать про инструменты бедного человека:

assert() - это ТБЧ (тест бедного человека). Такая функция есть в любом языке, даже в Lua, и позволяет без использования сложных фреймворков и библиотек начать писать тесты.

cat /dev/urandom - это ФБЧ (фаззинг бедного человека). В любой Unix-подобной ОС есть генератор псевдослучайных чисел, который можно использовать для фаззинга программ. radamsa и zzuf лишь делают использование /dev/urandom удобнее.

awk - это МЧБЧ (модел-чекинг бедного человека), интерпретатор awk для обработки текста можно использовать для проверки протоколов, см. работу "X.21 Analysis Revisited: the Micro Tracer" за авторством Джерарда Хольцманна

recidiv - это НИБЧ (непрерывная интеграция бедного человека), скрипт на языке Tcl для запуска сборки, тестирования и визуализации результатов для Redis DB. Сам сайт не доступен, но сам скрипт здесь - https://github.com/antirez/recidiv

Какая здесь мораль? Не знаю, наверное в том, что инструменты вторичны.

В LLVM появится поддержка измерения покрытия кода по критерию MC/DC, патч уже на этапе ревью - https://reviews.llvm.org/D136385
На последней встрече разработчиков LLVM был доклад про эту работу - https://llvm.org/devmtg/2022-11/

Вообще, критерий MC/DC обычно нужен при разработке авионики или для соответствия автомобильным стандартам, но инструментов для измерения MC/DC не так уж и много (я знаю только про BullseyeCoverage и он, кстати, бесплатен для проектов с открытым исходным кодом) и потенциальная поддержка в LLVM это уже хорошая новость.

Proposing an IRTF Usable Formal Methods Research Group
https://csperkins.org/research/protocol-standards/2022-11-30-usable-formal-methods/

На сайте ФСТЭК есть хорошие короткие видеолекции на тему фаззинга, статического анализа, динамического символьного выполнения и др. То, что надо, если вы хотите погрузиться в тему или планируете внедрять SDL в проекте. И не обращайте внимание на пометку "для специалистов в области информационной безопасности", лекции будут полезны всем, кто так или иначе связан с разработкой безопасного ПО.

https://bdu.fstec.ru/education

Организаторы Highload любезно предоставили запись доклада, которой я делюсь с вами.
https://www.youtube.com/watch?v=qwynLfpf9zk

На HackerNews сегодня интересная дискуссия - "What would happen if we prioritised all bugs over all new features?"
https://news.ycombinator.com/item?id=34907970

Порекламирую доклад Юры Грибова, который он расскажет на CppRussia.

В стандартных библиотеках C и C++ есть функции, которые используют функции сравнения, т.н. компараторы: в С++ это std::sort, std::binary_search, std::set, std::map и в C qsort или bsearch. Компараторы должны удовлетворять некоторым требованиям, а нарушение требований приводит к Undefined Behavior. Такие требования (или аксиомы) неинтуитивны и в них легко ошибиться, о чём свидетельствует большое количество соответствующих багов в open-source проектах.

Аксиомы, которым должны подчиняться компараторы, изложены в стандарте языка, их можно посмотреть в Cppref.

Популярные ошибки при написании компараторов:

1) Использование <= вместо <.
2) Сравнение особых объектов отдельным алгоритмом и нарушение условия транзитивности.
3) Неправильная реализация лексикографического порядка, когда не сравнивается первый элемент структуры на равенство при сравнение второго.
4) Массивы содержащие NaN.
5) Некорректная обработка специального случая.
6) Отрицание строгого порядка не является строгим порядком.

Для поиска таких проблем Юра предлагает два варианта: использование опций в тулчейне и использование динамического анализа.

В первом случае макрос -D_GLIBCXX_DEBUG в libstdc++ включает дополнительную проверку иррефлексивности, а в Libc++ c помощью -D_LIBCPP_ENABLE_DEBUG_MODE включаются проверки согласованности компараторов. Обе опции имеют существенный (2x) оверхед, поэтому их рекомендуется использовать только для тестирования.

Во втором случае динамические чекеры позволяют выполнять проверки компараторов в рантайме: SortChecker позволяет перехватывать компараторы для функций qsort и bsearch в C c помощью динамической инструментации (LD_PRELOAD), SortChecker++ позволяет проверять компараторы типа std::sort в программах на C++ и использует source-to-source инструментацию (Clang-based).

Организаторы Heisenbug выложили видео моего доклада про реализацию поддержки фаззинга Lua-скриптов, чтобы тестировать сервер приложений в СУБД Tarantool.

https://youtu.be/TRNifH9N5zM

"Blender: Automatic whole-program fuzzing"

> Blender is a new type of fuzzer that does not require writing the fuzz target function, instead it accepts the binary one wants to test as is (ideally compiled with sanitizers and coverage, but no source code changes). This is intended to solve one of the main problems with fuzzing -- scalability.

https://github.com/dvyukov/centipede/blob/dvyukov-blender/blender/README.md

Выглядит интересно, но серьезных багов с таким подходом пока не нашли.

Курс по тестированию ПО для студентов в Вышке образца 2019 года:

"Тестирование ПО. В основном много теории, которая даёт имена всяким стандартным практикам, которые студенты уже наверняка изобрели на других предметах: тестирование потока управления или потока данных, попарное тестирование (all-pairs testing)… Немного специфичной практики тоже есть — составить тестовый план по такой-то методике, найти крайние случаи в таком-то приложении, да несколько сценариев в веб-приложении при помощи Selenium прогнать, чтобы не было скучно просто кейсы составлять."

Выглядит старомодно. Может с тех у них программа поменялось.

via

Прошлым летом мы в Tarantool организовали и провели Летнюю школу для студентов, где они работали над реальными задачами, а им в этом помогали.

От меня были две задачи по созданию фаззеров по грамматике для LuaJIT и для SQL: нужно было описать грамматику в формате Protobuf, написать сериализатор из Protobuf с SQL запрос или Lua-программу и написать сам тест для LibFuzzer/LibProtobufMutator. Для LuaJIT в приниципе никто рандомизированное тестирование никогда не использовал, а для SQL был похожий фаззер для SQLit, но as is его все равно нельзя было взять из-за различий в грамматике. Идеи сделать фаззеры были давно, но времени на это в команде не было.

Мне повезло и на обе задачи нашлись студенты, которым было интересно этим заняться. До начала ноября мы занимались с ними, созванивались, обсуждали, дебажили, и к завершению Школы у них были готовы пулл-реквесты с тестами в репозиторий Tarantool. Ребята справились с задачами, сделали не только запланировонную работу, но и прошли полноценное ревью в несколько итераций. Мы получили два теста, ребята по условиям получили деньги и опыт разработки.

Все фаззеры для Tarantool запускаются в OSS-Fuzz с помощью libfuzzer, afl, centipede и honggfuzz (то есть все доступные движки) и с двумя санитайзерами (ASAN и UBSan) и в OSS-Sydr-Fuzz с помощью Sydr, движка для гибридного фаззинга от ИСП РАН. По итогам первых запусков новых фаззеров мы нашли: две утечки памяти в SQL и три бага в LuaJIT (некоторые были уже известными, но фиксы отсутствовали в Tarantool). Значит вся работа была проделана не зря! Сейчас в фаззере для LuaJIT есть проблема с зацикливаниями: иногда генерируется структура программы с рекурсивным вызовом функций или бесконечные циклы. С этим нам ещё предстоит разобраться. У меня есть идеи как этого можно избегать, но готов выслушать, если у вас есть идеи или опыть разработки подобных тестов.

Два года назад мне посчастливилось поучаствовать в Летней школе Лялямбда. Это выездное мероприятие, посвященное изучению формальных методов (наверное в первую очередь это формальная верификация и спецификация) и функциональному программированию. В прошлом году, например, был недельный трек введения в формальную верификацию ПО с помощью автоматического прувера Coq, введение в функциональное программирование на Haskell и множество докладов по темам Летней школы. В промежутках между занятиями было много других активностей как например спортивные игры, развлекательные мероприятия, потому что сложно непрерывно потреблять большой объём новой информации. В прошлом году Школа проходила в доме отдыха Ершово, недалеко от Звенигорода. Вообщем, если кратко описывать Школу, то это возможность познакомиться с формальными методами в неформальной обстановке. Для меня Школа была возможностью познакомиться поближе с Coq и у меня получилось это сделать.

Слово организаторам:

"Друзья! Мы рады анонсировать новую школу — Лялямбда.

15-23 июля в получасе от Тбилиси пройдёт летняя школа сложного программирования и современного искусства «Лялямбда». День на школе — это семь пар: четыре пары курса и три арт-попурри. В этом году на школе будут курсы не только про формальные методы, странные логики спецификации и ФП, но и про стэйт оф зэ арт теории музыки и проектирование микропроцессоров. В арте будут перформансы и джемы, утренняя йога, лежать на пуфике и слушать музыку, стоять на руках, плавать под водой, танцевать хип-хоп или танго, гулять по берегу озера — можно выбирать.

В этот раз мы в модном отеле на озере. Форма для регистрации - https://forms.gle/GFuJiGFA4VctHz178

Так же можно запросить грант, если он вам нужен, а здесь подать заявку на курс, мы помогаем их готовить. Вопросики можно писать @lalambda_bot."

"A Framework and Toolkit for Testing the Correctness of Recommendation Algorithms"

https://dl.acm.org/doi/abs/10.1145/3591109