challenge 001 exemplar

Образец AIxCC Linux Kernel CP, выпуск 01

Этот выпуск образца Challenge Project направлен на то, чтобы предоставить участникам Challenge Project, который напоминает ту же структуру и интерфейс, которые будут существовать для всех Challenge Project во время конкурса.

Этот экземпляр был разработан и протестирован со следующими версиями:

• Убунту 22.04.04 ЛТС
• Докер версии 26.0.0

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

Что в релизе:

src/ — это исходный код проекта вызова, ядро ​​Linux 6.1.54 со следующей модификацией:

1. CVE-2021-43267 вновь представлен через изменения в net/tipc/crypto.c
2. Добавлены тесты kunit для уязвимой функции посредством изменений в net/tipc/crypto.c , net/tipc/tipc_test.c
3. Добавлен специальный жгут AIxCC в папку test_harnesses/ .
4. Сгенерированная история git с коммитами, включающими уязвимости, и безопасными коммитами.

run.sh — скрипт, предоставляющий CRS стандартизированный интерфейс для взаимодействия с конкурсным проектом.

build.sh — скрипт, определяющий процесс сборки сложного проекта.

project.yaml — документ yaml, подробно описывающий многие важные аспекты сложного проекта.

exemplar_only/ — эта папка содержит дополнительную информацию, которая предоставляется только в экземпляре версии; не следует ожидать, что эта информация будет предоставлена ​​во время соревнований.

1. blobs/ — эта папка содержит файл с именем sample_solve.bin , который при передаче в тестовый пакет должен вызвать внедренную уязвимость.
2. patches/ — это папка, содержащая два примера патчей.
   • good_patch.diff — удаляет уязвимость и сохраняет функциональность.
   • bad_patch.diff — удаляет уязвимость, но не сохраняет функциональность.
3. gen_blob.py — это вспомогательный сценарий, позволяющий пользователям генерировать двоичные объекты для предоставленного тестового оборудования.
4. Во время соревнований следующие три элемента будут храниться в предварительно созданном образе Docker, который будет предоставлен для каждого конкурсного проекта.
   • run_internal.sh — это скрипт, который запускается в среде докера для обработки запросов.
   • setup.sh — это скрипт установки зависимостей для создания образа докера.
   • test_blob.py — это скрипт для проверки полученных блоков данных на целевых жгутах.

Настройте репозиторий

Чтобы протестировать образец, сначала создайте базовый образ Docker, выполнив следующую команду.

docker build . -t exemplar-cp-linux:base --target=exemplar-cp-linux-base

После сборки базовое взаимодействие с контейнером можно осуществлять с помощью сценария run.sh

Подробности команды запуска

Скрипт run.sh предоставляет стандартизированный интерфейс, который будет единообразным для всех конкурирующих CP. Перед сборкой программного обеспечения вы должны извлечь исходный код из его репозитория:

./run.sh pull_source

Эта команда перезаписывает все, что находится в данный момент в папке src/ , позволяя загружать новые копии исходного кода.

Здание

./run.sh build [patch file]

Команда build собирает тестовый проект с помощью дополнительного сгенерированного файла исправления. Исходный код собирается с помощью тома Docker, подключенного к папке src/ . Двоичные файлы тестовой программы собираются и сохраняются в папке out/ . И можно использовать для анализа.

ПРИМЕЧАНИЕ. Команда build создаст текущее рабочее состояние src/ , а также любые изменения в Dockerfile. Если вы хотите протестировать патч, рекомендуется создать чистую копию состояния с помощью команды pull_source и чистый файл Dockerfile.

Запуск PoV

./run.sh run_pov < blob_file > < harness_id >

Команда run_pov запускает предоставленный файл больших двоичных данных по указанному идентификатору жгута. Действительные идентификаторы жгутов указаны в файле project.yaml .

Запуск тестов

./run.sh run_tests

Команда run_tests запускает функциональные тесты в рамках тестового проекта. На данный момент команда run_tests сохранит исходное состояние каталога src/ .

Примеры использования

Допустим, вы хотите получить исходный код, собрать его как есть, проанализировать тестовый двоичный файл Linux и использовать полученный двоичный файл.

./run.sh pull_source
./run.sh build
file out/linux_test_harness
file src/arch/x86/boot/bzImage

Затем вы запускаете блок данных для тестового оборудования, чтобы проверить триггеры дезинфицирующего средства. Чтобы протестировать собственные входные данные, замените двоичный файл exemplar_only собственным файлом.

./run.sh run_pov exemplar_only/blobs/sample_solve.bin linux_test_harness | grep -i ' pov|trigger '

После проверки триггеров санитайзера вы изменяете исходный код непосредственно через каталог src/ , пытаясь исправить уязвимость.

sed -i ' 2310,2312d ' src/net/tipc/crypto.c
./run.sh build
./run.sh run_pov exemplar_only/blobs/sample_solve.bin linux_test_harness | grep -i ' pov|trigger '
./run.sh run_tests

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

./run.sh pull_source
./run.sh build exemplar_only/patches/good_patch.diff
./run.sh run_pov exemplar_only/blobs/sample_solve.bin linux_test_harness | grep -i ' pov|trigger '
./run.sh run_tests

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