LAVA : Ajout automatisé de vulnérabilités à grande échelle

L'évaluation et l'amélioration des outils de recherche de bogues sont actuellement difficiles en raison d'une pénurie de corpus de référence (c'est-à-dire de logiciels comportant des bogues connus avec des entrées déclenchantes). LAVA tente de résoudre ce problème en injectant automatiquement des bogues dans les logiciels. Chaque bogue LAVA est accompagné d'une entrée qui le déclenche, alors que les entrées normales ont une probabilité extrêmement faible de le faire. Ces vulnérabilités sont synthétiques mais, selon nous, toujours réalistes, dans le sens où elles sont intégrées profondément dans les programmes et sont déclenchées par de vraies entrées. Notre travail constitue la base d'une approche permettant de générer à la demande de grands corpus de référence de vulnérabilités, ce qui permet une évaluation rigoureuse des outils et fournit une cible de haute qualité aux développeurs d'outils.

LAVA est le fruit d'une collaboration entre le MIT Lincoln Laboratory, la NYU et la Northeastern University.

Démarrage rapide

Docker

La dernière version de la branche master de LAVA est automatiquement construite sous forme d'images Docker basées sur Ubuntu 22.04 et publiée sur Docker Hub. La plupart des utilisateurs voudront utiliser le conteneur lava qui dispose de PANDA et LAVA installés avec leurs dépendances d'exécution, mais sans artefacts de construction ni code source afin de réduire la taille du conteneur.

Pour utiliser le conteneur lava, vous pouvez le récupérer depuis Docker Hub :

$ docker pull pandare/lava

Ou compilez à partir de ce dépôt :

$ DOCKER_BUILDKIT=1 docker build -t pandare/lava:local .

Si Docker Engine s'exécute directement dans WSL et que les étapes de build ne peuvent pas accéder au réseau (par exemple, APT signale Temporary failure resolving), essayez d'utiliser le réseau hôte de WSL pour le build :

DOCKER_BUILDKIT=1 docker build --network=host -t pandare/lava:local .

Cela s'applique uniquement aux étapes de build ; les conteneurs lancés ultérieurement utilisent leurs propres paramètres réseau.

Espace de travail du conteneur

Depuis un espace de travail contenant target_bins/ et target_configs/, utilisez le lanceur pour ouvrir un shell ou exécuter une commande. Il monte l'espace de travail au même chemin absolu afin que les chemins écrits dans host.json restent valides entre les exécutions. Remplacez /path/to/lava par la copie de travail contenant le lanceur :

/path/to/lava/scripts/docker-shell.sh
/path/to/lava/scripts/docker-shell.sh -- lava-init
/path/to/lava/scripts/docker-shell.sh -- lava --help

Docker s'exécute avec votre UID/GID et stocke son répertoire personnel inscriptible dans .lava-container-home/ au sein de l'espace de travail. Si votre ~/.panda/ hôte existe, le lanceur le monte comme cache PANDA du conteneur afin que les QCOW et fichiers de noyau existants soient réutilisés. Les téléchargements et les modifications du cache persistent dans ce répertoire hôte. Utilisez --panda-cache /path/to/cache pour sélectionner un autre cache existant. Sans cache hôte, PANDA stocke les téléchargements dans .lava-container-home/.panda/. Le lanceur utilise pandare/lava:latest par défaut ; utilisez --image pandare/lava:v3.3.4 pour sélectionner une version, ou --image pandare/lava:local pour la compilation locale ci-dessus.

PostgreSQL doit déjà être en cours d'exécution. Exportez POSTGRES_USER et POSTGRES_PASSWORD, vers le point de terminaison de la base de données accessible depuis l'intérieur du conteneur. Pour une base de données sur un réseau Docker, passez --network NETWORK et utilisez son nom de conteneur comme host. localhost à l'intérieur de Docker fait référence au conteneur LAVA lui-même. Une fois configuré :

/path/to/lava/scripts/docker-shell.sh --network NETWORK -- lava -ak toy

-k supprime les données de projet existantes sans confirmation. Le lanceur remplace l'ancienne interface où le nom du projet venait en premier ; les commandes suivent désormais --.

HPC avec Apptainer / Singularity

Sur un nœud de calcul alloué, utilisez le runtime fourni par le cluster. Récupérez une image versionnée une seule fois dans un stockage persistant, puis réutilisez-la pour les tâches :

apptainer pull /path/to/scratch/lava-v3.3.4.sif docker://pandare/lava:v3.3.4
/path/to/lava/scripts/docker-shell.sh --runtime apptainer \
  --image /path/to/scratch/lava-v3.3.4.sif -- lava-init
/path/to/lava/scripts/docker-shell.sh --runtime apptainer \
  --image /path/to/scratch/lava-v3.3.4.sif -- lava -tc toy

Utilisez --runtime singularity si c'est la commande installée. Ces runtimes utilisent l'identité et le réseau de l'utilisateur hôte ; configurez host.json pour un service PostgreSQL accessible et exportez les mêmes identifiants. Le lanceur ne démarre ni la base de données ni ne demande d'allocation de planificateur. Exécutez-le à l'intérieur de l'allocation interactive ou du script batch de votre cluster. Cela ne garantit pas qu'une image de version prend en charge le pipeline complet ; vérifiez l'installation de l'image et exécutez un projet de test avant de soumettre une tâche de minage volumineuse.

Ubuntu, Debian

Installation locale

Sur un système exécutant Ubuntu 22.04, vous devriez pouvoir simplement exécuter bash install.sh. Notez que ce script d'installation installera des paquets et apportera des modifications à votre système. Vous pouvez supprimer les binaires avec sudo apt-get remove lava.

Une fois l'installation du binaire terminée, vous pouvez installer localement en exécutant pip install ..

NOTE : le paquet Python nécessite un fichier SQL généré à partir de la compilation des binaires, placé dans python/src/pyroclastic/data/lava.sql. Sans ce fichier, le paquet Python ne fonctionnera pas correctement.

Installation standard

Alternativement, vous pouvez installer manuellement les dépendances de LAVA puis compiler depuis les sources. Téléchargez les paquets Debian situés dans les releases. Installez ensuite le paquet python pip install pyroclastic.

Étapes finales

Utilisation de host.json

Ensuite, exécutez init-host pour générer un host.json dans votre répertoire de travail courant. Ce fichier est utilisé par LAVA pour stocker les paramètres spécifiques à votre machine. Vous pouvez modifier ces paramètres selon vos besoins, mais les valeurs par défaut devraient fonctionner, voir vars.py.

Quelques valeurs à garder à l'esprit sont les suivantes :

• host est le nom de la base de données Postgres SQL contenant tous les bugs LAVA. Actuellement, il vaut par défaut database, bien que si vous avez installé LAVA localement, vous devriez probablement le remplacer par localhost

NOTE : vous avez également besoin de deux variables d'environnement pour la base de données Postgres SQL :

• POSTGRES_PASS Il s'agit du mot de passe de l'utilisateur Postgres SQL`
• POSTGRES_USER Il s'agit du nom d'hôte de la base de données Postgres SQL

Configurations de projet

Les configurations de projet sont situées dans le répertoire target_configs, où chaque configuration se trouve à target_configs/projectname/projectname.json. Les chemins spécifiés dans ces fichiers de configuration sont relatifs aux valeurs définies dans votre fichier host.json.