challenge 001 exemplar

AIxCC Linux Kernel CP Ejemplar Versión 01

Esta versión del Proyecto Desafío Ejemplar tiene como objetivo proporcionar a los competidores un Proyecto Desafío que se asemeje a la misma estructura e interfaz que existirá para todos los Proyectos Desafío durante la competencia.

Este ejemplo ha sido desarrollado y probado con las siguientes versiones:

• Ubuntu 22.04.04 LTS
• Versión acoplable 26.0.0

Nota: El contenido de este documento está sujeto a cambios, ¡esté atento a futuras actualizaciones!

Qué hay en el comunicado:

src/ : este es el código fuente del proyecto de desafío, kernel de Linux 6.1.54 con la siguiente modificación:

1. CVE-2021-43267 reintroducido mediante cambios en net/tipc/crypto.c
2. Se agregaron pruebas de kunit para funciones vulnerables mediante cambios en net/tipc/crypto.c , net/tipc/tipc_test.c
3. Se agregó un arnés específico de AIxCC en la carpeta test_harnesses/ .
4. Historial de git generado con confirmaciones que incluyen la vulnerabilidad y confirmaciones benignas

run.sh : un script que proporciona a un CRS una interfaz estandarizada para interactuar con el proyecto de desafío.

build.sh : un script que define el proceso de construcción del proyecto de desafío.

project.yaml : un documento yaml que detalla muchos aspectos importantes del proyecto de desafío.

exemplar_only/ : esta carpeta contiene información complementaria que solo se proporciona con la versión ejemplar; no se debe esperar que esta información se proporcione durante la competencia.

1. blobs/ : esta carpeta contiene un archivo llamado sample_solve.bin que, cuando se pasa al arnés de prueba, debería activar la vulnerabilidad inyectada.
2. patches/ : esta es la carpeta que contiene dos parches de ejemplo.
   • good_patch.diff : elimina la vulnerabilidad y mantiene la funcionalidad.
   • bad_patch.diff : elimina la vulnerabilidad pero no mantiene la funcionalidad.
3. gen_blob.py : este es un script de ayuda para que los usuarios generen blobs binarios para el arnés de prueba proporcionado.
4. En el momento de la competencia, los siguientes tres elementos se almacenarán dentro de una imagen acoplable prediseñada que se proporcionará para cada proyecto del desafío.
   • run_internal.sh : este es un script que se ejecuta dentro del entorno acoplable para manejar solicitudes.
   • setup.sh : este es un script de instalación de dependencias para crear la imagen de la ventana acoplable.
   • test_blob.py : este es un script para probar los blobs de datos recibidos con los arneses de destino.

Configurar el repositorio

Para probar el ejemplo, primero cree la imagen base de la ventana acoplable ejecutando lo siguiente.

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

Una vez creado, se pueden lograr interacciones básicas con el contenedor a través del script run.sh

Ejecutar detalles del comando

El script run.sh proporciona una interfaz estandarizada que será consistente en todos los CP de la competencia. Antes de compilar el software, debe extraer el código fuente de su repositorio de código fuente:

./run.sh pull_source

Este comando sobrescribe cualquier cosa que se encuentre actualmente en la carpeta src/ , lo que permite cargar copias nuevas del código fuente.

Edificio

./run.sh build [patch file]

El comando build crea el proyecto de desafío con un archivo de parche generado opcional. El código fuente se construye a través del volumen acoplable montado en la carpeta src/ . Los archivos binarios del arnés de prueba se crean y almacenan en la carpeta out/ . Y puede usarse para análisis.

NOTA: el comando build generará el estado de funcionamiento actual de src/ , así como cualquier modificación al Dockerfile. Si desea probar un parche, se recomienda crear una copia limpia del estado con el comando pull_source y un Dockerfile limpio.

Ejecución de punto de vista

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

El comando run_pov ejecuta el archivo de blob de datos binarios proporcionado con el identificador de arnés especificado. Los ID de arnés válidos se enumeran en el archivo project.yaml .

Ejecución de pruebas

./run.sh run_tests

El comando run_tests ejecuta las pruebas de funcionalidad dentro del proyecto de desafío. A partir de ahora, el comando run_tests preservará el estado original del directorio src/ .

Ejemplos de casos de uso

Supongamos que desea extraer el código fuente, compilarlo tal cual y analizar el binario de prueba de Linux y aprovechar el binario resultante.

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

Luego, ejecuta un blob de datos en el arnés de prueba para comprobar los desencadenadores del desinfectante. Para probar sus propios datos de entrada, reemplace el binario exemplar_only con su propio archivo.

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

Después de verificar los activadores del desinfectante, modifica el código fuente directamente a través del directorio src/ , intentando parchear la vuln.

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

Descubre que eliminó el activador del desinfectante, pero no pasó las pruebas de funcionalidad. Usted crea una mejor solución y genera un archivo de parche. Obtiene una copia limpia de la fuente para probar adecuadamente el parche con la fuente original y vuelve a ejecutar las pruebas funcionales y de punto de vista. Para probar sus propios parches, reemplace el parche exemplar_only con su propio archivo.

./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

Ahora ha generado un blob de datos que activa un desinfectante cuando se pasa al arnés linux_test_harness , así como un parche que corrige esa vulnerabilidad mientras pasa las pruebas de funcionalidad.