Si elles sont exploitées, ces failles peuvent permettre aux attaquants d'obtenir un accès non autorisé à des informations sensibles ou de causer des problèmes en général.
Il y a quelques jours, la publication de mises à jour correctives pour Wasmtime 6.0.1, 5.0.1 et 4.0.1 a été annoncée , qui corrigent une vulnérabilité (déjà répertoriée sous CVE-2023-26489) classée comme critique.
Cette vulnérabilité permet d'organiser l'écriture de données dans une zone mémoire située en dehors des limites autorisées pour le code WebAssembly isolé, ce qui peut potentiellement être utilisé par un attaquant pour organiser l'exécution de son code en dehors de l'environnement WASI isolé.
Pour ceux qui ne connaissent pas Wasmtime, sachez qu'il s'agit d'un environnement d'exécution permettant d'exécuter des applications WebAssembly avec des extensions WASI (WebAssembly System Interface) en tant qu'applications autonomes normales.
Wasmtime est écrit en Rust et la vulnérabilité est due à une erreur logique dans la définition des règles d'adressage mémoire linéaire dans le générateur de code Cranelift, qui traduit une représentation intermédiaire indépendante des architectures matérielles en code machine exécutable pour l'architecture x86_64.
Concernant la vulnérabilité corrigée, il est mentionné qu'en particulier, des adresses effectives de 35 bits ont été calculées pour les applications WebAssembly au lieu des adresses de 33 bits autorisées dans WebAssembly , ce qui a porté la limite de mémoire virtuelle autorisée pour les opérations de lecture et d'écriture à 34 Go, alors que la configuration de l'environnement sandbox offre une protection pour 6 Go de l'adresse de base.
Le générateur de code de Wasmtime, Cranelift, a un bogue dans les cibles x86_64 où le calcul du mode d'adresse calculerait par erreur une adresse effective 35 bits au lieu de l'adresse effective 33 bits définie par WebAssembly. Ce bogue signifie qu'avec la configuration de génération de code par défaut, une opération de chargement/stockage contrôlée par wasm peut lire/écrire des adresses jusqu'à 35 bits de la base de la mémoire linéaire.
Par conséquent, une plage de mémoire virtuelle de 6 à 34 Go à partir de l'adresse de base est disponible en lecture et en écriture pour les applications WebAssembly. Cette mémoire peut accueillir d'autres environnements WebAssembly ou des composants d'exécution WebAssembly.
Par exemple (i32.load (i32.shl (local.get 0) (i32.const 3))), est chargé à partir de l'adresse WebAssembly $local0 << 3. Lorsqu'il est traduit en Cranelift, le calcul de $local0 << 3 à une valeur de 32 bits, est étendue à zéro en une valeur de 64 bits, puis ajoutée à l'adresse de base de la mémoire linéaire. Cranelift générerait une instruction de la forme movl(%base, %local0, 8), %dst qui calcule %base + %local0 << 3.
L'erreur ici, cependant, est que le calcul de l'adresse se produit avec des valeurs 64 bits, où $local0 << 3 était censé tronquer l'adresse à une valeur 32 bits. Cela signifie que %local0, qui peut utiliser jusqu'à 32 bits pour une adresse, obtient 3 bits supplémentaires d'espace d'adressage pour être accessible via movl .
Enfin, bien qu'il soit toujours recommandé de mettre à jour le package vers la dernière version disponible , il convient également de mentionner qu'il existe plusieurs solutions possibles pour atténuer ce problème si la mise à jour est impossible.
Il est mentionné qu'aucune de ces solutions n'est activée par défaut et nécessite une configuration explicite :
- S'il n'est pas possible de mettre à jour la version de Wasmtime, l'option "Config :: static_memory_maximum_size(0)" est mentionnée pour activer la vérification des limites séparées obligatoires sur tout accès linéaire à la mémoire comme solution de contournement pour bloquer l'erreur (résulte en une dégradation significative des performances ).
- Une autre option consiste à utiliser le paramètre "Config::static_memory_guard_size(1 < 36)" pour augmenter le nombre de pages de garde (Page de garde, lancer une exception lors de l'accès) situées dans la plage de mémoire virtuelle problématique (conduit à réserver une grande quantité de mémoire virtuelle mémoire et limitation du nombre d'applications WebAssembly simultanées).
- S'il est possible d'utiliser un hôte non x86_64, cela corrigera également cette erreur. Ce bogue n'affecte pas le backend AArch64 de Wasmtime ou Cranelift, par exemple.
Enfin, si vous souhaitez en savoir plus, vous trouverez les détails en suivant ce lien.