Les mises à jour correctives Wasmtime 6.0.1, 5.0.1 et 4.0.1 ont corrigé la vulnérabilité (CVE-2023-26489), à laquelle un niveau de danger critique a été attribué. La vulnérabilité permet d'écrire des données dans une zone mémoire en dehors des limites autorisées pour le code WebAssembly isolé, qui pourrait potentiellement être utilisée par un attaquant pour exécuter son code en dehors de l'environnement WASI isolé.
Wasmtime est un environnement d'exécution permettant d'exécuter des applications WebAssembly avec des extensions WASI (WebAssembly System Interface) en tant qu'applications autonomes classiques. La boîte à outils est écrite en langage Rust et la vulnérabilité est causée par une erreur logique dans la définition des règles d'adressage 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 particulier, pour les applications WebAssembly, des adresses effectives de 35 bits ont été calculées au lieu des adresses de 33 bits autorisées dans WebAssembly, ce qui a déplacé la limite de mémoire virtuelle autorisée pour les opérations de lecture et d'écriture à 34 Go, tandis que les paramètres de l'environnement sandbox offrent une protection pour 6 Go à partir de l'adresse de base. En conséquence, la plage de mémoire virtuelle de 6 à 34 Go à partir de l'adresse de base était disponible pour la lecture et l'écriture à partir des applications WebAssembly. Cette mémoire peut héberger d'autres environnements WebAssembly ou composants d'exécution WebAssembly.
S'il n'est pas possible de mettre à jour la version Wasmtime, une solution de contournement pour bloquer l'erreur consiste à spécifier l'option "Config::static_memory_maximum_size(0)" pour activer une vérification des limites distinctes sur tous les accès à la mémoire linéaire (entraînant une pénalité de performances significative). . Une autre option consiste à utiliser le paramètre « Config::static_memory_guard_size(1 < 36) » pour augmenter le nombre de pages de garde (une exception levée lors de l'accès) placées dans la plage de mémoire virtuelle problématique (ce qui entraîne la réservation d'une grande quantité de mémoire virtuelle et limitant le nombre d'applications WebAssembly exécutant simultanément).
Source: opennet.ru