challenge 001 exemplar

AIxCC Linux Kernel CP exemplar versão 01

Este lançamento do Modelo de Projeto Desafio tem como objetivo fornecer aos competidores um Projeto Desafio que se assemelhe à mesma estrutura e interface que existirá para todos os Projetos Desafio durante a competição.

Este exemplar foi desenvolvido e testado com as seguintes versões:

• Ubuntu 22.04.04LTS
• Docker versão 26.0.0

Nota: O conteúdo aqui está sujeito a alterações, por favor, verifique e fique atento para futuras atualizações!

O que há no lançamento:

src/ - este é o código fonte do projeto de desafio, kernel Linux 6.1.54 com a seguinte modificação:

1. CVE-2021-43267 reintroduzido por meio de alterações em net/tipc/crypto.c
2. Adicionados testes kunit para funções vulneráveis ​​por meio de alterações em net/tipc/crypto.c , net/tipc/tipc_test.c
3. Adicionado um chicote específico do AIxCC na pasta test_harnesses/ .
4. Histórico git gerado com commits que incluem a vulnerabilidade e commits benignos

run.sh - um script que fornece ao CRS uma interface padronizada para interagir com o projeto do desafio.

build.sh – um script que define o processo de construção do projeto de desafio.

project.yaml - um documento yaml detalhando muitos aspectos importantes do projeto desafio.

exemplar_only/ - esta pasta contém informações suplementares que são fornecidas apenas com o lançamento do exemplar, esta informação não deve ser fornecida durante a competição.

1. blobs/ - esta pasta contém um arquivo chamado sample_solve.bin que, quando passado para o equipamento de teste, deve acionar a vulnerabilidade injetada.
2. patches/ - esta é uma pasta que contém dois exemplos de patches.
   • good_patch.diff - remove a vulnerabilidade e mantém a funcionalidade.
   • bad_patch.diff - remove a vulnerabilidade, mas não mantém a funcionalidade.
3. gen_blob.py - este é um script auxiliar para os usuários gerarem blobs binários para o equipamento de teste fornecido.
4. No momento da competição, os três itens a seguir serão armazenados em uma imagem docker pré-construída que será fornecida para cada projeto do desafio.
   • run_internal.sh - este é um script executado no ambiente docker para lidar com solicitações.
   • setup.sh - este é um script de instalação de dependência para construir a imagem do docker.
   • test_blob.py - este é um script para testar blobs de dados recebidos em relação aos chicotes de destino.

Configure o repositório

Para testar o exemplo, primeiro construa a imagem base do Docker executando o seguinte.

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

Depois de construído, as interações básicas com o contêiner podem ser alcançadas por meio do script run.sh

Detalhes do comando de execução

O script run.sh fornece uma interface padronizada que será consistente em todos os CPs da competição. Antes de compilar o software, você deve extrair o código-fonte de seu repositório de origem:

./run.sh pull_source

Este comando substitui qualquer coisa atualmente na pasta src/ , permitindo o carregamento de novas cópias do código-fonte.

Prédio

./run.sh build [patch file]

O comando build cria o projeto de desafio com um arquivo de patch gerado opcional. O código-fonte é construído por meio do volume docker montado na pasta src/ . Os binários do equipamento de teste são criados e armazenados na pasta out/ . E pode ser usado para análise.

NOTA: o comando build construirá o estado de funcionamento atual de src/ , bem como quaisquer modificações no Dockerfile. Se você quiser testar um patch, é aconselhável criar uma cópia limpa do estado com o comando pull_source e um Dockerfile limpo.

Executando PoV

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

O comando run_pov executa o arquivo blob de dados binários fornecido no ID de chicote especificado. Os IDs de chicote válidos estão listados no arquivo project.yaml .

Executando testes

./run.sh run_tests

O comando run_tests executa os testes de funcionalidade no projeto de desafio. A partir de agora, o comando run_tests preservará o estado original do diretório src/ .

Exemplos de casos de uso

Digamos que você queira extrair o código-fonte, construí-lo como está e analisar o binário de teste do Linux e aproveitar o binário resultante.

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

Em seguida, você executa um blob de dados no equipamento de teste para verificar os gatilhos do desinfetante. Para testar seus próprios dados de entrada, substitua o binário exemplar_only pelo seu próprio arquivo.

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

Depois de verificar os gatilhos do sanitizer, você modifica o código-fonte diretamente por meio do diretório src/ , tentando corrigir a vulnerabilidade.

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

Você descobre que removeu o gatilho do desinfetante, mas falhou nos testes de funcionalidade. Você cria uma solução melhor e gera um arquivo de patch. Você obtém uma cópia limpa da fonte para testar adequadamente o patch em relação à fonte original e executa novamente os testes funcionais e de pov. Para testar seus próprios patches, substitua o patch exemplar_only pelo seu próprio arquivo.

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

Agora você gerou um blob de dados que aciona um sanitizador quando passado para o chicote linux_test_harness , bem como um patch que corrige essa vulnerabilidade ao passar nos testes de funcionalidade.