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, le lPublication des mises à jour correctives Wasmtime 6.0.1, 5.0.1 et 4.0.1 Quoi ils peuvent corriger une vulnérabilité (déjà catalogué sous CVE-2023-26489) qui a été classé critique.
Vulnérabilité permet d'organiser l'écriture de données dans une zone mémoire en dehors des limites autorisées pour le code WebAssembly isolé, qui peut potentiellement être utilisé par un attaquant pour orchestrer 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 de routage de 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.
En ce qui concerne la vulnérabilité corrigée, il est mentionné qu'en particulier, les adresses 35 bits effectives ont été calculées pour les applications WebAssembly au lieu des adresses 33 bits autorisées dans WebAssembly, qui a modifié la limite de mémoire virtuelle autorisée pour les opérations de lecture et d'écriture à 34 Go, tandis que le paramètre d'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.
En conséquence, la plage de mémoire virtuelle de 6 à 34 Go à partir de l'adresse de base est devenue disponible pour la lecture et l'écriture à partir d'applications WebAssembly. Cette mémoire peut contenir d'autres environnements WebAssembly ou 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, comme toujours, il est recommandé de mettre à jour le package vers la dernière version disponibleIl convient également de mentionner qu'il existe plusieurs solutions possibles qui peuvent être utilisées pour atténuer ce problème si la mise à jour n'est pas possible.
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 pouvez vérifier les détails dans le lien suivant.