Analyse de WebAssembly : Assurer une exécution de code sûre

WebAssembly est un nouveau format de code qui tourne dans les navigateurs web et sur d'autres appareils. Son but principal, c'est d'être rapide et de fonctionner sur différents types de dispositifs. Ça devient populaire parce que ça permet aux programmes de tourner plus fluidement, surtout ceux qui demandent beaucoup de puissance de traitement, comme les jeux vidéo ou le streaming vidéo. Mais comme on peut l'utiliser sans navigateur, ça pose quelques risques. Des personnes malveillantes pourraient se servir de WebAssembly pour cacher des logiciels nuisibles, comme un outil qui vole de la puissance de traitement pour des tâches comme le minage de cryptomonnaies.

Ça a créé un besoin grandissant d'outils pour s'assurer que le code WebAssembly est sûr. Beaucoup de chercheurs travaillent sur des façons de vérifier que le code fait ce qu'il doit faire sans poser de problèmes de sécurité. Un aspect important de cette vérification s'appelle un graphique d'appels. Un graphique d'appels, c'est une représentation visuelle de la manière dont les fonctions d'un programme interagissent entre elles. Ça montre quelles fonctions appellent les autres, donnant une image claire de la structure du programme.

#Qu'est-ce qu'un graphique d'appels ?

Un graphique d'appels est un graphe dirigé où chaque nœud représente une fonction dans un programme. Une arête entre deux nœuds indique qu'une fonction appelle une autre. Les graphiques d'appels aident à comprendre les programmes et sont essentiels pour différents types d'analyses de programmes.

Cependant, construire un graphique d'appels exact peut être compliqué. Ça implique souvent de faire des suppositions éclairées sur les Appels de fonctions, ce qui peut inclure des appels réels et des appels supplémentaires qui pourraient ne pas se produire. Cette sur-approximation est courante parce que c'est plus facile que d'essayer de cibler chaque appel.

Dans WebAssembly, les appels de fonctions se font avec des commandes spécifiques. Une commande est l'opérateur call, qui appelle une fonction directement. L'autre est l'opérateur call_indirect, qui est moins direct et ressemble à appeler une fonction en utilisant sa position dans une liste. Cette méthode indirecte est là où les complications peuvent survenir, rendant plus difficile le maintien de la précision lors de la construction d'un graphique d'appels.

#Le défi de la construction de graphiques d'appels

Les modules WebAssembly sont conçus pour fonctionner avec l'environnement dans lequel ils tournent. Parfois, l'environnement externe peut changer des choses qui affectent le comportement du code WebAssembly. Par exemple, si l'environnement hôte change une table de références de fonctions, ça peut créer de l'incertitude dans le graphique d'appels. Ça rend difficile pour les outils d'analyser le code avec précision.

Pour simplifier les choses, on suppose que le module WebAssembly examiné est autonome. De cette façon, on peut se concentrer sur la construction d'un graphique d'appels complet sans se soucier des interactions extérieures.

#Interprétation abstraite : une méthode d'analyse

Une manière d'analyser les fonctions d'un programme, c'est par une méthode appelée interprétation abstraite. Cette approche permet d'inférer des propriétés sur un programme sans avoir à vérifier chaque chemin possible. Au lieu de regarder tous les détails spécifiques, l'interprétation abstraite offre une vue d'ensemble, ce qui peut simplifier le processus d'analyse.

Quand on réalise une interprétation abstraite, on crée un modèle simplifié de ce que fait le programme. Ce modèle ne capture peut-être pas tous les détails, mais il aide à identifier des comportements importants, comme où des erreurs pourraient survenir. Par exemple, ça peut aider à trouver des problèmes comme la division par zéro ou l'utilisation d'un pointeur nul.

#La structure de WebAssembly

WebAssembly est une version simplifiée du langage d'assemblage, spécifiquement conçue pour le web. Il a un nombre limité d'instructions, ce qui le rend plus facile à manipuler. Les programmes compilés en WebAssembly tournent sur une machine virtuelle, un peu comme les applications Java tournent sur la Java Virtual Machine. Ce système permet à WebAssembly de fonctionner sur plein de plateformes différentes tant qu'une machine virtuelle compatible est disponible.

Dans WebAssembly, le Flux de contrôle est géré par des instructions de saut étiquetées, qui gardent trace de la façon dont le programme se déplace entre différents points. Ce flux prévisible aide à générer des graphes de flux de contrôle précis, qui sont essentiels pour comprendre comment les fonctions interagissent.

#Travailler avec les appels de fonctions

Pour les appels de fonctions dans WebAssembly, il y a différentes méthodes utilisées. Comme déjà mentionné, l'opérateur call appelle une fonction directement, tandis que l'opérateur call_indirect nécessite plus de soin à cause de sa dépendance aux tables de fonctions. Cette complexité complique la construction des graphiques d'appels car il est essentiel de connaître les valeurs sur la pile lors de l'utilisation de call_indirect.

De nombreux outils qui travaillent avec WebAssembly essaient de deviner les appels de fonctions en examinant les types impliqués. Cependant, sans un suivi plus détaillé des valeurs de la pile, ces outils peuvent rater des connexions importantes entre les fonctions.

#Améliorer la précision dans la construction des graphiques d'appels

Pour créer un graphique d'appels plus précis pour WebAssembly, il est nécessaire de surveiller les valeurs présentes sur la pile lors des appels indirects. Ce processus améliore la précision du graphique d'appels, menant à des résultats plus fiables lors de l'analyse du code.

Différentes études ont exploré comment construire des graphiques d'appels sains et précis pour WebAssembly. Malheureusement, atteindre à la fois la santé et la précision est un défi. Certaines méthodes privilégient l'un ou l'autre, ce qui peut mener à des analyses moins fiables.

#Outils pour analyser WebAssembly

Il existe divers outils pour analyser le code WebAssembly. Certains de ces outils se concentrent sur l'interprétation abstraite pour tirer des informations utiles sur le code. Par exemple, un de ces outils, appelé Sturdy, vise à produire des graphiques d'appels, mais il s'appuie sur des modèles plus simples, ce qui pourrait affecter la précision de ses résultats.

Un autre outil, Wassail, utilise l'interprétation abstraite pour effectuer une analyse de traçage. L'analyse de traçage vérifie comment les informations circulent dans un programme, ce qui peut aider à identifier des problèmes de sécurité potentiels.

Nous développons également un nouvel interpréteur abstrait spécifiquement pour WebAssembly. Cet outil est conçu pour créer des graphiques d'appels précis et peut être élargi pour une analyse plus approfondie.

#Modèles sémantiques dans WebAssembly

Quand on crée un outil pour analyser WebAssembly, il est crucial d'établir un modèle clair de comment fonctionne le langage. Les modèles sémantiques décrivent le sens derrière le code et comment il fonctionne. En définissant un modèle sémantique, on peut mieux comprendre le flux de données et les interactions entre fonctions dans WebAssembly.

Notre approche inclut la définition de sémantiques concrètes et abstraites pour une version simplifiée de WebAssembly. Ça inclut une méthode appelée sémantique de continuation qui aide à contrôler le flux d'exécution. En utilisant cette méthode, on peut créer des interprétations plus utiles du code WebAssembly.

#Conclusion

WebAssembly représente un outil puissant pour exécuter du code rapide et efficace sur différentes plateformes. Cependant, les risques de sécurité et les complexités liés à son utilisation demandent une analyse attentive. En construisant des graphiques d'appels précis et en appliquant des méthodes comme l'interprétation abstraite, on peut mieux comprendre la structure de WebAssembly et s'assurer que son utilisation reste sécurisée.

Au fur et à mesure que la recherche avance dans ce domaine, des outils et méthodes plus efficaces émergeront, menant à des applications WebAssembly plus sûres qui conservent les avantages de performance pour lesquels elles ont été conçues.