Как написать нечеткие тесты против Linux KVM? - PullRequest
Новая
       18

Как написать нечеткие тесты против Linux KVM?

4 голосов
/ 20 апреля 2011

Должно быть так, что ядро ​​Linux, если оно является ядром хоста, не должно подвергаться негативному влиянию того, что гостевое ядро ​​выполняет внутри виртуальной машины.

Я хотел бы протестировать это свойствопутем фаззинга интерфейса от гостевого ядра до ядра хоста.Мне кажется ясным, что тест должен выполняться внутри гостевого ядра (скажем, в модуле ядра), генерировать произвольный код и затем выполнять этот код.Тест не пройден, если ядро ​​хоста падает (или делает что-то «интересное»).

Итак, мои вопросы:

  • Вам известны какие-либо тесты, которые уже выполняют это?
  • Существуют ли инструкции, которые ожидаются для сбоя ядра хоста, которых мне следует избегать?
  • Каков наилучший способ создания мусора внутри ядра Linux?
  • После того, как я сгенерировал мусор, как мне его выполнить?

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

Обновление: Подумав об этом дальше, запустив полный мусорне будет работать, так как я буду ломать свою гостевую машину гораздо чаще, чем я ожидаю, чтобы сломать мой хост.Итак, я думаю, что мне нужно подходить к этому хирургически с самого начала.Любой совет?

Ответы [ 2 ]

2 голосов
/ 20 апреля 2011

В значительной степени нахождение серозных 0 дней - это написание образных тестов.Когда вы создаете тестовую систему, вам необходимо определить ее поверхность атаки.В веб-приложениях это просто, запросы GET / POST.Для чего-то вроде виртуальной машины, это более сложный.Фактическое оборудование, предоставленное вам, является иллюзией, созданной KVM.В какой-то момент это взаимодействие с данным устройством будет обрабатываться хостом.

Другой важный ресурс ищет уязвимости, которые уже были обнаружены в вашей цели.Часто программисты делают очень похожие ошибки, и подобные ошибки очень распространены. Эти CVE: CVE-2010-0297 CVE-2010-0298 CVE-2010-0306 CVE-2010-0309 , являются хорошими примерами уязвимостей LInux KVM.Два аппаратных устройства, которые торчат - это процессор и USB, которые оба скомпрометированы.

Очень мощная платформа Fuzzing Peach .Многие тесты могут быть созданы с использованием одного XML, хотя, если вы знаете Python, вы можете расширить peach, чтобы сделать что-нибудь.

0 голосов
/ 28 февраля 2017

Хотя драйверы фаззиновых устройств часто производительны, большинство из них эмулируется не KVM, а компонентом пользовательского пространства.Драйверы USB, как показано в предыдущем примере, полностью эмулируются QEMU.Хотя финансирование уязвимости в эмулируемом драйвере EHCI было бы фантастическим, это не было бы уязвимостью KVM и не позволяло бы вам разрабатывать эксплойт ядра.Есть несколько драйверов, которые эмулируются в KVM, такие как определенные таймеры PIC (например, i8254 и i8259), но большинство из них хранятся в пользовательском пространстве.

Другая вещь, которую эмулирует KVM, - это определенные инструкции.Вы можете размышлять над KVM, размышляя над этими конкретными инструкциями.Прочитайте источник KVM, чтобы увидеть, какие из них наиболее сложные и как вызвать наиболее сложное или чувствительное поведение.На более старых архитектурах ЦП, где ЦП не может обеспечить выполнение в реальном режиме гостю (unrestricted_guest = 1), эмулируется даже больше инструкций.

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

...