Фаззинг

В SQLancer поддерживается около 20 наиболее популярных СУБД и во всех были найдены проблемы. В одних больше, в других меньше. Авторы SQLancer считают PostgreSQL и SQLite как наиболее протестированные СУБД, все найденные ими проблемы были исправлены. А MySQL и MariaDB они перестали тестировать, потому что найденные проблемы игнорируются разработчиками: For some other DBMSs like MySQL and MariaDB, SQLancer could still detect unreported bugs; we stopped testing these DBMSs and reporting bugs due to the large number of unfixed bugs. Примеры неисправленных проблем: - https://bugs.mysql.com/bug.php?id=113180 - https://bugs.mysql.com/bug.php?id=113298 - https://bugs.mysql.com/bug.php?id=117242 - https://bugs.mysql.com/bug.php?id=117439 - https://bugs.mysql.com/bug.php?id=117261 Делайте выводы.

Фаззинг-тесты, которые мы изначально делали для нашего форка LuaJIT, так же используются для непрерывного фаззинга оригинального проекта LuaJIT и интерпретатора PUC Rio Lua. Результат двухлетней работы: 6 багов в PUC Rio Lua, превентивно найденные до публичных релизов, и 23 бага в LuaJIT. Всё были исправлены. Использование одних и тех же тестов для разных проектов оказалось возможным благодаря тому, что PUC Rio Lua и LuaJIT предоставляют один и тот же Lua C API. Если в этих проектах получилось успешно использовать фаззинг, то было бы здорово применить их и для другого Lua рантайма, подумал я. Для Go есть популярный среди гоферов проект - GopherLua, это реализация Lua на Go. Для проекта написано много расширений, которые добавляют функциональность со стороны Lua. В Go есть встроенный тулинг для написания фаззинг-тестов: нужно всего лишь написать обёртку для функции, собрать специальной командой и вообщем-то всё. Но я не знаю про аналог libprotobuf-mutator в Go (гоферы, подскажете аналог?). Поэтому сделать фаззеры для GopherLua с неструктурированными данными проще простого, а чтобы фаззинг-тест генерировал структурированные валидные данные я не смог найти решения. Я решил попробовать изобразить из GopherLua библиотеку с Lua C API, чтобы эту библиотеку можно было скомпоновать с моими тестами и переиспользовать фаззинг для Lua применительно к GopherLua. Для интеграции Go с C есть cgo, который предоставляет возможность использования C-библиотек в Go и экспорта Go функций в интерфейс C (генерация заголовочного файла). Если кратко, то LuaJIT C FFI мне показался удобнее, чем использование cgo. Из того, с чем я столкнулся: - В коде Go нельзя указать макросы, чтобы потом эти макросы cgo добавил в сгенерированный заголовочной файл. Поэтому часть макросов из lua.h пришлось принести в сам тест. - в Go нельзя никак указать, что функция не принимает аргументов, чтобы в заголовочном файле у функции в параметрах был void. На эту тему есть тикет и вроде даже патч. - В Lua C API каждая функция первым аргументом принимает указатель на L, структуру, описывающую Lua стек. Я не придумал, как возвращать из Go/cgo эту структуру, поэтому мой модуль может работать с единственной копией стека. Но для моих целей этого достаточно. В результате этой работы можно собрать тест, который по грамматике генерирует программы на Lua и исполняет их в GopherLua. Правда не все программы исполняются одинаково успешно и иногда случаются проблемы работы с памятью (runtime error: invalid memory address or nil pointer dereference). Такие дела.

Видео доклада How Badly Do We Want Correct Compilers? (NDC TechTown 2023) Доклад известного исследователя Джона Регира (John Regehr). Докладчик, насколько можно заметить, ни разу не произносит слово "CompCert" и сомневается в успешности проектов формально верифицированных компиляторов для популярных ЯП, что, конечно, интригует. Рассматриваются инструменты, в разработке которых принял участие автор доклада: YARPGen, Souper и другие проекты. via

Опубликовано фото

Выложили слайды и видеозапись докладов с конференции ТБ Форум 2024. Из докладов, которые мне больше всего "зашли": Основные направления совершенствования сертификации средств защиты информации, Дмитрий Шевцов, начальник управления ФСТЭК России Этот доклад перевернул в моей голове представление о людях, которые пишут стандарты для нашей индустрии разработки ПО. Я представлял себе этот доклад самым скучным из сетки докладов, а вышло совершенно наоборот. Из интересного: во ФСТЭК собрали статистику, чтобы профилировать процесс сертификации ПО на разных стадиях перед получением сертификата ФСТЭК. Выяснилось, что больше всего времени уходит на проведение испытаний (38% времени), а на втором месте стадия предоставления заявителем образцов СЗИ в испытательную лабораторию (25% времени). Как следствие, ФСТЭК сократил сроки рассмотрения документов и проведения отдельных видов работ (суммарно на 105 календарных дней). Этой весной вступают в силу приказы о введении "Требования по безопасности информации к системам управления базами данных", по данным ФСТЭК в настоящее время в системе сертификации ФСТЭК России сертифицировано 15 СУБД, из них Требованиям соответствуют 4 СУБД. Центр исследования безопасности системного программного обеспечения, Алексей Хорошилов, ведущий научный сотрудник, ФГБУН "ИСП РАН" Традиционный отчет о работе "Центра исследования безопасности ядра", который объединяет усилия отечественных компаний-разработчиков ПО в Linux в стат. анализе и фаззинге Linux-ядра. Для самых интересных слайдов сделал скриншоты. Унифицированная среда безопасной разработки программного обеспечения, Вартан Падарян, ведущий научный сотрудник ФГБУН "ИСП РАН" ИСП РАН продолжает работать над средствами для безопасной разработки и их автоматизацией. На слайдах приведен план работ и отмечено, что планируют портирование технологий анализа кода на отечественные процессоры (Байкал, Эльбрус, что-то на RISC-V) и запустить облако, чтобы предоставлять инструменты для безопасной разработки как сервис. На одном из слайдов приводится сравнение статистики срабатываний в Svace и cppcheck, ожидаемо Svace показал лучшие результаты. Вот бы кто сравнил PVS Studio и Svace, результаты были бы любопытными. Postgres Professional: путь от SDL к сертификации РБПО, Шаплов Николай Николаевич В PostgresPro есть отдельная команда, которая целенаправленно занимается фаззингом PostgreSQL. На слайдах явно не указано, но насколько помню устно ребята говорили, что исправления для найденных проблем они возвращают в апстрим. Ребята тестируют сетевой протокол (libpq), функции-обработчики типов данных (28 типов: jsonb, int, line, varchar etc), функции для выполнения операций над данными (128 операций, используется структурированный фаззинг). Для libpq используют FUTAG для автоматической генерации целей. Отдельно докладчик отметил проблему с исправлением найденных проблем: > Найденный баг должен быть праздником для фаззингиста. Если приходится биться за то, чтобы найденный баг взяли в работу, если багу никто не рад, фаззингист не захочет ничего находить. Хех, игнорирование найденных проблем демотивирует не только фаззингистов. :-/ https://www.tbforum.ru/2024/program/information-security