Par Marco Fioretti

introduction

WebAssembly est, comme nous expliqué récemment, un format binaire pour les logiciels écrits dans n’importe quelle langue, conçu pour finalement fonctionner sur n’importe quelle plate-forme sans changement. La première application de WebAssembly se trouve dans les navigateurs Web, pour rendre les sites Web plus rapides et plus interactifs. Les projets de pousser WebAssembly au-delà du Web, des serveurs de toutes sortes à l’Internet des objets (IoT), créent autant d’opportunités que de problèmes de sécurité. Cet article est une présentation introductive de ces problèmes et du modèle de sécurité WebAssembly.

WebAssembly est comme JavaScript

Dans les navigateurs Web, les modules WebAssembly sont gérés par la même machine virtuelle (VM) qui exécute le code JavaScript. Par conséquent, WebAssembly peut être utilisé pour faire une grande partie du même mal qui est faisable avec JavaScript, mais de manière plus efficace et moins visible. Étant donné que JavaScript est du texte brut que le navigateur compilera et WebAssembly un format binaire prêt à l’emploi, ce dernier s’exécute plus rapidement et est également plus difficile à analyser (même par un logiciel antivirus) pour les instructions malveillantes.

Cet effet «d’obfuscation de code» de WebAssembly a déjà été utilisé, entre autres, pour faire apparaître des publicités indésirables ou pour ouvrir de fausses fenêtres de «support technique» qui demandent des données sensibles. Une autre astuce consiste à rediriger automatiquement les navigateurs vers des pages de «destination» contenant le malware vraiment dangereux.

Enfin, WebAssembly peut être utilisé, tout comme JavaScript, pour «voler» la puissance de traitement au lieu des données. En 2019, un analyse de 150 modules Wasm différents découvert que sur 32% d’entre eux ont été utilisés pour l’extraction de crypto-monnaie.

Sandbox WebAssembly et interfaces

Le code WebAssembly s’exécute fermé dans un bac à sable géré par la VM, pas par le système d’exploitation. Cela ne lui donne aucune visibilité de l’ordinateur hôte, ni des moyens d’interagir directement avec lui. L’accès aux ressources système, qu’il s’agisse de fichiers, de matériel ou de connexions Internet, ne peut se faire que via l’interface système WebAssembly (WASI) fournie par cette machine virtuelle.

Le WASI est différent de la plupart des autres interfaces de programmation d’application, avec des caractéristiques de sécurité uniques qui conduisent vraiment à l’adoption de WASM sur les serveurs / scénarios de calcul de périphérie, et sera le sujet du prochain article. Ici, il suffit de dire que ses implications en matière de sécurité varient considérablement lors du passage du Web vers d’autres environnements. Les navigateurs Web modernes sont des logiciels terriblement complexes, mais reposent sur des décennies d’expérience et des tests quotidiens effectués par des milliards de personnes. Par rapport aux navigateurs, les serveurs ou les appareils IoT sont des terres presque inexplorées. Les VM de ces plates-formes nécessiteront des extensions de WASI et, par conséquent, introduiront sûrement de nouveaux défis en matière de sécurité.

Gestion de la mémoire et du code dans WebAssembly

Par rapport aux programmes compilés normaux, les applications WebAssembly ont un accès très limité à la mémoire et à elles-mêmes aussi. Le code WebAssembly ne peut pas accéder directement aux fonctions ou variables qui ne sont pas encore appelées, accéder à des adresses arbitraires ou exécuter des données en mémoire sous forme d’instructions de bytecode.

Dans les navigateurs, un module Wasm ne reçoit qu’un seul tableau global («mémoire linéaire») d’octets contigus avec lesquels jouer. WebAssembly peut directement lire et écrire n’importe quel emplacement dans cette zone, ou demander une augmentation de sa taille, mais c’est tout. Cette mémoire linéaire est également séparée des zones qui contiennent son code réel, sa pile d’exécution et bien sûr la machine virtuelle qui exécute WebAssembly. Pour les navigateurs, toutes ces structures de données sont des objets JavaScript ordinaires, isolés de toutes les autres à l’aide de procédures standard.

Le résultat: bon, mais pas parfait

Toutes ces restrictions font qu’il est assez difficile pour un module WebAssembly de se comporter mal, mais pas impossible.

La mémoire en bac à sable qui rend presque impossible pour WebAssembly de toucher ce qui est à l’extérieur rend également plus difficile pour le système d’exploitation d’éviter que de mauvaises choses ne se produisent à l’intérieur. Mécanismes de surveillance de la mémoire traditionnels tels que « Empiler les canaris », qui remarque si un code essaie de jouer avec des objets qu’il ne doit pas toucher, ne peut pas y travailler.

Le fait que WebAssembly ne puisse accéder qu’à sa propre mémoire linéaire, mais directement, peut également faciliter le travail des attaquants. Avec ces contraintes, et l’accès au code source d’un module, il est beaucoup plus facile de deviner quels emplacements mémoire pourraient être écrasés pour faire le plus de dégâts. Il semble aussi possible pour corrompre les variables locales, car elles restent dans une pile non supervisée dans la mémoire linéaire.

Un article 2020 sur la sécurité binaire de WebAssembly a noté que le code WebAssembly peut toujours écraser les littéraux de chaîne dans la mémoire supposée constante. Le même article décrit d’autres façons dont WebAssembly peut être moins sécurisé que lorsqu’il est compilé dans un binaire natif, sur trois plates-formes différentes (navigateurs, applications côté serveur sur Node.js et applications pour des machines virtuelles WebAssembly autonomes) et est recommandé en outre lecture sur ce sujet.

En général, l’idée que WebAssembly ne peut endommager que ce qui se trouve à l’intérieur de son propre bac à sable peut être trompeuse. Les modules WebAssembly font le gros travail du code JavaScript qui les appelle, en échangeant des variables à chaque fois. S’ils écrivent dans l’une de ces variables du code qui peut provoquer des plantages ou des fuites de données dans le JavaScript dangereux qui a appelé WebAssembly, ces choses volonté se produire.

Le chemin à parcourir

Deux fonctionnalités émergentes de WebAssembly qui auront sûrement un impact sur sa sécurité (comment et dans quelle mesure, il est trop tôt pour le dire) sont concurrenceet garbage collection interne.

La concurrence est ce qui permet à plusieurs modules WebAssembly de s’exécuter simultanément dans la même machine virtuelle. Aujourd’hui, cela n’est possible que via JavaScript travailleurs web, mais de meilleurs mécanismes sont en cours de développement. Sur le plan de la sécurité, ils peuvent apporter « Beaucoup de code… qui n’avait pas besoin de l’être auparavant », c’est plus de moyens pour que les choses tournent mal.

UNE ramasse-miettes natif est nécessaire pour augmenter les performances et la sécurité, mais surtout pour utiliser WebAssembly en dehors des machines virtuelles Java bien testées des navigateurs, qui collectent de toute façon toutes les ordures en eux. Même ce nouveau code, bien sûr, peut devenir un autre point d’entrée pour les bogues et les attaques.

Du côté positif, il existe également des stratégies générales pour rendre WebAssembly encore plus sûr qu’il ne l’est aujourd’hui. Citant à nouveau de ici, ils incluent des améliorations du compilateur, séparé mémoires linéaires pour la pile, le tas et les données constantes, et en évitant de compiler en tant que code de modules WebAssembly dans des «langages non sûrs, tels que C».

La poste Sécurité de WebAssembly, maintenant et dans le futur est apparu en premier le Linux Foundation – Formation.