gamozolabs/applepieГипервизор для фаззинга, построенный на WHVP и Bochs
Привет! Добро пожаловать в applepie! Это инструмент, предназначенный для фаззинга, интроспекции и поиска ошибок! Это гипервизор, использующий Windows Hypervisor Platform API, доступный в последних версиях Windows (в частности, разработано и протестировано на Windows 10 17763). Bochs используется для обеспечения глубокой интроспекции и эмуляции устройств.
Windows Hypervisor Platform API (WHVP) — это набор API для доступа к возможностям гипервизора Hyper-V. Этот API позволяет нам легко реализовать виртуальную машину полностью в пользовательском пространстве без необходимости в специальных драйверах или разрешениях.
Это быстро развивающийся проект. Я, вероятно, буду твитить о выходе новых функций до того, как они будут задокументированы.
Мне нравится иметь материальные вещи для своих проектов:
Это инструмент, предназначенный для фаззинга и интроспекции во время исследований безопасности. Используя гипервизор, можно применять распространенные методы фаззинга к любому целевому объекту, будь то ядро или пользовательское пространство. Эта среда позволяет фаззить целые системы без необходимости иметь исходный код цели. На уровне гипервизора можно собирать покрытие кода, а при необходимости эмуляция Bochs может обеспечить произвольную интроспекцию в среде эмуляции. Эта информация о покрытии может использоваться для определения эффективности тестовых случаев фаззинга. Тестовый случай, вызвавший увеличение покрытия, может быть сохранен как интересный. Эти входные данные можно использовать позже, дополняя новыми искажениями.
Фаззинг со снимками — основное применение этого инструмента. Вы делаете снимок системы в определенном состоянии и сохраняете его. Затем этот снимок можно загрузить для фаззинга, внедрить тестовый случай и возобновить выполнение. Поскольку ВМ можно сбросить очень дешево, ее можно часто перезапускать. Если Word загружается 5 секунд, но вы можете сделать снимок прямо в момент чтения вашего файла, вы сокращаете тестовый случай только до того, что имеет отношение к входным данным. Это позволяет создать очень плотный цикл фаззинга без необходимости иметь доступ к исходному коду. Поскольку ВМ являются полностью отдельными системами, многие из них могут работать параллельно для масштабирования на все ядра.
В настоящее время этот инструмент поддерживает только сбор покрытия кода, динамическую загрузку символов для Windows, а также разбор символов/модулей для целей Windows. Поддержка фаззинга будет добавлена совсем скоро.
Учитывая, что я уже писал почти все эти функции ранее (покрытие, фаззинг, быстрые сбросы и т.д.). Я ожидаю, что этот проект довольно быстро станет готов к фаззингу, если я не отвлекусь :D
Я стремлюсь к концу января для покрытия (готово!), фидбека, списков модулей (готово!), списков процессов, быстрых сбросов и поддержки символов (готово!). Это сделает его очень мощным фаззером.
Основная поддерживаемая цель — современная Windows 10. Цели Windows имеют возможность загрузки символов из хранилища символов. Это обеспечивает символьное покрытие для целей Windows из коробки. Однако код написан таким образом, что поддержка Linux может быть легко добавлена.
Без какой-либо поддержки, любая ОС, которая загружается, все еще может быть подвергнута фаззингу, и может быть собрано базовое покрытие.
Перед сообщением о проблемах с поддержкой ОС, пожалуйста, проверьте, что проблема связана с гипервизором/изменениями в Bochs, попробовав загрузить вашу цель с использованием стандартного предварительно собранного Bochs без гипервизора. Bochs не является широко используемым и часто может содержать критические ошибки даже для таких распространенных вещей, как загрузка Linux. Особенно с учетом быстрых внутренних изменений в использовании CPUID/MSR с внедрением мер защиты от Spectre/Meltdown в ОС.
Смотрите страницу issues на Github для списка проблем. Я уже добавил несколько. Некоторые из них необходимо решить быстро, прежде чем начнется разработка фаззинга.
Для сборки вам понадобится несколько вещей:
Установите Visual Studio 2017 и убедитесь, что он обновлен. Мы используем некоторые самые современные API, заголовки и библиотеки.
Я использовал версию cl.exe: Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64
И версию SDK 10.0.17763.0
Установите Rust через https://rustup.rs/. Я использовал rustc 1.32.0-nightly (b3af09205 2018-12-04)
Убедитесь, что вы установили цепочку инструментов x86_64-pc-windows-msvc, так как для этого проекта поддерживается только 64-битная версия.
Убедитесь, что cargo находится в вашем PATH. Обычно это так по умолчанию.
Скачайте python https://www.python.org/ и убедитесь, что он находится в вашем PATH, чтобы можно было вызвать python.
Установите 64-битный Cygwin (https://www.cygwin.com/setup-x86_64.exe) именно в C:\cygwin64. При установке Cygwin убедитесь, что вы установили пакеты autoconf и make.
Зайдите в "Включение или отключение компонентов Windows" и отметьте флажок рядом с "Hyper-V" и "Windows Hypervisor Platform". Это, конечно, требует, чтобы ваш компьютер поддерживал Hyper-V.
Это руководство по установке было проверено на следующем:
Clean install of Windows 10, Build 17763
rustc 1.33.0-nightly (8e2063d02 2019-01-07)
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64
Visual Studio Community 2017 version 15.9.4
applepie commit `f84c084feb487e2e7f31f9052a4ab0addd2c4cf9`
Python 3.7.2 x64
git version 2.20.1.windows.1
autoconf package)make package)git clone https://github.com/gamozolabs/applepiepython build.py
Этот начальный процесс сборки может занять около 2 минут, на современном компьютере, вероятно, 20-30 секунд.
Просто выполните python build.py из корневого каталога этого проекта. Он проверит корректность окружения, и все должно "просто работать".
Выполните python build.py clean для очистки бинарных файлов Bochs и Rust.
Выполните python build.py deepclean для полного удаления всех бинарных файлов Bochs и Rust, а также всей конфигурации Bochs. Используйте это, если вы меняете конфигурацию Bochs каким-либо образом.
Ознакомьтесь с конфигурацией Bochs, чтобы понять, как настроить вашу среду. У нас есть несколько требований, таких как sync=none, ips=1000000, и в настоящее время поддержка только одного процессора. Они принудительно применяются в самом коде, чтобы вы не навредили себе.
Используйте включенные конфигурации bochservisor_test\bochsrc.bxrc и bochservisor_test_real\bochsrc.bxrc в качестве примеров. bochservisor_test_real, вероятно, самая актуальная конфигурация, на которую следует ориентироваться.
Цели Windows имеют поддержку списков модулей, что позволяет нам видеть списки всех модулей в контексте, в котором мы работаем. С помощью этого мы можем преобразовать адреса инструкций в модуль + смещение. Этот модуль + смещение помогает сохранять информацию о покрытии между тестовыми случаями, когда состояние ASLR меняется. Это также позволяет раскрашивать модуль в таком инструменте, как IDA, чтобы визуально увидеть, какой код был затронут.
Для целей Windows символы будут динамически загружаться из хранилища символов с использованием вашего _NT_SYMBOL_PATH и symchk. Если symchk нет в пути, он молча завершится ошибкой. С символами можно сохранить удобочитаемую версию покрытия для просмотра. Кроме того, с частными символами покрытие может быть преобразовано в исходный файл:строка, чтобы можно было раскрашивать исходный код.
Ладно, на самом деле тестов нет, но есть bochservisor_test — крошечная ОС, которая просто проверяет, что все загружается с гипервизором.
Есть также bochservisor_test_real — конфигурация, которую я использую для таких вещей, как Windows/Linux. Она, вероятно, будет обновляться наиболее часто.
Эта кодовая база добавляет небольшое количество кода в Bochs для обеспечения модульного доступа к контексту ЦП, гостевой физической памяти к поддерживающей памяти и пошагового выполнения как состояния устройства, так и ЦП.
Основной код, на который стоит обратить внимание, находится в lib.rs в проекте Rust bochservisor.
В основном цикле ЦП Bochs мы вместо этого используем LoadLibrary() для загрузки DLL bochservisor. Эта DLL экспортирует одну процедуру — цикл ЦП на Rust, который будет вызван.
Bochs передаст структуру этой процедуре bochs_cpu_loop, которая будет содержать указатели на функции для получения информации от Bochs и для пошагового выполнения состояния устройства и ЦП в нем.
Когда происходит MMIO или I/O, гипервизор выйдет с ошибкой памяти или ошибкой инструкции I/O. Хотя WHVP предоставляет API эмуляции, он действительно недостаточен.
Вместо этого мы используем Bochs, который уже есть, и выполняем несколько инструкций. Поддерживая состояние ЦП гипервизора синхронизированным с Bochs, мы можем динамически переключаться между гипервизором и эмуляцией в любое время (или, по крайней мере, мы должны иметь такую возможность).
Это означает, что полное состояние гипервизора всегда синхронизировано с Bochs, и, следовательно, такие вещи, как снимки Bochs, должны работать как обычно и могут быть загружены без гипервизора (за исключением, возможно, некоторого состояния CPUID, которое необходимо сохранить в информации снимка).
Когда происходит MMIO или I/O, мы выполняем определенное количество инструкций под эмуляцией, а не эмулируем только одну. Из-за затрат API на вход и выход из гипервизора и вероятности того, что похожие операции MMIO происходят рядом друг с другом, мы выполняем несколько инструкций. Это позволяет снизить накладные расходы API и уменьшить частоту VMEXIT. Это настраиваемое число, но то, что есть в кодовой базе, вероятно, установлено не просто так.
Прерывания мы обрабатываем очень интересным способом. Вместо планирования доставки прерываний гипервизору мы обрабатываем все прерывания в самой эмуляции Bochs. Такие вещи, как исключения, происходящие полностью внутри гипервизора, конечно, не обрабатываются Bochs.
Это также дает нам функции, которые WHVP не поддерживает, такие как SMI (для SMM). BIOS Bochs по умолчанию использует SMM, и без поддержки SMI необходимо создавать пользовательский BIOS. Я делал это в своей первой итерации... не рекомендую.
Этот проект предназначен для фаззинга, однако он настолько новый (всего несколько дней от роду), что не имеет ни одной из этих функций.
Некоторые из первых вещей, которые появятся:
Мы потенциально могли бы запустить устройства Bochs в одном потоке в цикле в реальном времени, а другой поток — гипервизор. Асинхронные события будут передаваться через IPC и позволят обновлять устройства во время выполнения гостя.
В настоящее время все происходит в одном потоке, что означает, что гипервизор должен выходить через определенные интервалы, чтобы мы могли выполнять шаги устройств. Это как если бы мы написали свой собственный планировщик.
Это может быть немного быстрее, но также увеличивает сложность и добавляет потенциальные проблемы с гонками. Трудно сказать, произойдет ли это когда-нибудь.
Я не уверен, какой метод буду использовать для сбора покрытия кода, но будет как минимум несколько вариантов. От точного до быстрого и т.д. Все эти механизмы покрытия будут на уровне системы и не будут требовать исходного кода или символов целей.
Разбор структур ОС для получения базовой информации, такой как списки процессов, списки модулей и т.д. Затем это будет использоваться для запроса PDB для получения информации о символах.
Сообщение о сбоях в осмысленном виде. В идеале минидампы были бы хороши, так как их можно загрузить и обработать в WinDbg. Это может быть довольно легко, так как DMP — это просто физическая память и контекст процессора, которые у нас уже есть.
У меня есть несколько интересных методов для определения первопричины ошибок, которые исторически были успешными. Я планирую применить их здесь.
Отслеживая грязные страницы и восстанавливая только измененные данные, мы сможем очень быстро сбрасывать ВМ. Это дает нам возможность фаззить на максимальной скорости на всех ядрах целевой системы. Это похоже на то, что я сделал в falkervisor, так что это уже продумано и спроектировано. Нужно просто перенести это сюда.
Чрезвычайно быстрый фаззинг, который отменяет выполнение при возникновении MMIO или I/O. Это позволяет тратить все процессорное время на гипервизор и не тратить время на эмуляцию. Недостатком является отсутствие поддержки таких вещей, как дисковый I/O во время тестового случая, но это удобно.
Одной из основных концепций этого проекта является минимальное изменение Bochs. Это позволяет нам поддерживать часть Bochs в этом репозитории в актуальном состоянии.
Цель также состоит в том, чтобы перенести как можно больше кода в Rust и DLL, чтобы сделать систему гораздо более модульной и безопасной. Это, надеюсь, уменьшит вероятность появления глупых ошибок повреждения в самом гипервизоре, приводящих к неверным результатам фаззинга.
В настоящее время гипервизор представляет собой DLL, и его можно заменить без изменений в Bochs (если только не изменится FFI API).
Дальнейшие изменения в самом Bochs должны быть четко задокументированы, и я вскоре сделаю документ для этого, чтобы отслеживать изменения Bochs, которые необходимо переносить и переоценивать при обновлениях Bochs.