FI(le) SY(stem) - FUZZer

Это полноценный фреймворк для фаззинга файловых систем, который я представил на конференции Hack in the Box 2020 Lockdown Edition в апреле.

Обзор фреймворка

Цель

Цель этого фреймворка — выявлять ошибки безопасности ядра в UNIX-системах с особым акцентом на BSD-системы. Он разрабатывался и активно тестировался на FreeBSD, OpenBSD и NetBSD, но также имеет частичную поддержку хостов на Linux. Нам удалось успешно обнаружить более 100 уникальных ошибок ядра для файловых систем на основе UFS и EXT, а также получить глубокое понимание недавно добавленной ZFS.

Генератор тестовых примеров

Скрипт makeFS2.py можно использовать как отдельную утилиту для создания различных корректных файловых систем. Подробное описание использования приведено в репозитории материалов конференции

Требования

Фреймворк тестировался только на Ubuntu 18.04. Он полагается на KVM, QEMU и libvirt. Скрипт Requirements.sh устанавливает все необходимые зависимости. Фреймворк может быть полностью работоспособен на последней версии Ubuntu 20.04. Другие хост-системы, не основанные на apt, также могут быть легко поддержаны — для этого потребуются лишь небольшие изменения в Requirements.sh. После завершения установки требований можно переходить к шагам настройки!

Настройка

Обратитесь к SETUP.md. Если какие-то шаги неясны, пожалуйста, свяжитесь со мной!

Фаззинг!

Запуск фаззера выполняется командой: python3 run.py. В зависимости от вашей конфигурации могут потребоваться привилегии sudo. Когда всё успешно запущено, вы можете подключиться к сессии фаззинга в tmux с помощью:

(sudo) tmux attach-session -t fsfuzzer

Конфигурация

Фреймворк настраивается скриптом src/config/fuzzing_config.py:


# [параметры задач фаззинга]
# Список словарей, описывающих каждый экземпляр фаззинга
fuzzer = [
    {
        "name": "fuzz1",  # Имя для внутреннего учёта
        "fs_creator_vm": "genBox",  # Имя ВМ в libvirt для генерации файловой системы, может быть одинаковым для всех экземпляров
        "fuzzing_vm": "fuzzBox_0",  # Имя ВМ в libvirt для фаззинга файловой системы
        "mutation_engine": "radamsa, 0",  # Используемый движок мутации и размер мутации (radamsa аргумент размера не принимает)
        "target_fs": "ufs2",  # Целевая файловая система
        "target_size": 15,  # Максимальный размер файловой системы в мегабайтах
        "populate_with_files": 10,  # Количество генерируемых файлов
        "max_file_size": 1024,  # Максимальный размер файла в байтах для каждого сгенерированного файла
        "enable_dyn_scaling": False,  # Динамическое масштабирование периодически увеличивает размер файловой системы
    },
]

# [учётные данные]
# Учётные данные root для ВМ
# Предполагается, что они одинаковы для всех экземпляров, но не обязательно root
user = "root"
pw = "root"

Доступные движки мутации:

radamsa
byte_flip_seq
byte_flip_rnd
metadata

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

Остальные параметры конфигурации, вероятно, понятны без объяснений.

PoC

На видео ниже показана быстрая демонстрация, где два экземпляра фаззинга одновременно атакуют FreeBSD с мутированной UFS2 через radamsa и EXT с произвольной заменой байтов. Мутированная UFS напрямую приводит к сбою, показывая, как быстро можно обрушить ядро.

пример фаззинга

Набор функций

Будущие работы

Трофеи

С помощью этой установки мне удалось найти более 100 уникальных ошибок ядра в FreeBSD, NetBSD и OpenBSD для файловых систем на основе UFS и EXT. Среди этих сбоев было много очень интересных:

Чтение за границами буфера
Запись за границами буфера
Двойная ошибка в EXT
Тройная ошибка в UFS
Недетерминированная ошибка ядра с более чем 6 уникальными дампами

Большинство сбоев относились к DoS ядра. Кроме того, большинство обнаруженных сбоев до сих пор не исправлены (по состоянию на май 2020 г.). Так что дерзайте — ищите ошибки ядра в реализациях файловых систем :).

Отказ от ответственности

Всё это было построено по принципу «trust driven development», то есть проект слишком быстро разросся из простой концепции PoC. Следовательно, тесты отсутствуют, и, скорее всего, есть несколько багов. Извините, если вы столкнётесь с ошибками (не связанными с паникой ядра), но не стесняйтесь создавать PR или писать мне — я всё исправлю как можно быстрее!

Контакты

Twitter: @0xricksanchez

fisy-fuzz

Популярное