CVE-2023-26489 in wasmtime
Résumé
par VulDB • 09/05/2026
wasmtime est un runtime rapide et sécurisé pour WebAssembly. Dans les versions concernées, le générateur de code de wasmtime, Cranelift, présente un bug sur les cibles x86_64 où le calcul du mode d'adressage calcule par erreur une adresse effective de 35 bits au lieu de l'adresse effective de 33 bits définie par WebAssembly. Ce bug signifie qu'avec les paramètres de génération de code par défaut, une opération de chargement/stockage contrôlée par le wasm pourrait lire/écrire des adresses jusqu'à 35 bits éloignées de la base de la mémoire linéaire. En raison de ce bug, des adresses jusqu'à `0xffffffff * 8 + 0x7ffffffc = 36507222004 = ~34G` octets éloignées de la base de la mémoire linéaire sont accessibles depuis le code invité (guest). Cela signifie que la mémoire virtuelle située à 6G de la base de la mémoire linéaire jusqu'à ~34G peut être lue/écrite par un module malveillant. Un module invité peut, sans la connaissance de l'intégrateur (embedder), lire/écrire de la mémoire dans cette région. La mémoire peut appartenir à d'autres instances WebAssembly lors de l'utilisation de l'allocation par pool, par exemple. Il est recommandé aux intégrateurs concernés d'analyser les modules wasm préexistants pour voir s'ils sont affectés par les règles de génération de code incorrectes et éventuellement de corréler cela avec un nombre anormal de pièges (traps) lors de l'exécution historique afin de localiser les modules potentiellement suspects. Le bug spécifique dans le backend x86_64 de Cranelift est qu'une adresse WebAssembly qui est décalée vers la gauche (left-shifted) d'une quantité constante de 1 à 3 sera intégrée dans les modes d'adressage de x86_64 qui effectuent des décalages. Par exemple, `(i32.load (i32.shl (local.get 0) (i32.const 3)))` charge depuis l'adresse WebAssembly `$local0 << 3`. Lors de la traduction vers Cranelift, le calcul `$local0 << 3`, une valeur 32 bits, est étendu sur 64 bits (zero-extended) puis ajouté à 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`. Le bug ici, cependant, est que le calcul de l'adresse se fait avec des valeurs 64 bits, alors que le calcul `$local0 << 3` était censé être tronqué à 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 accessibles via cette instruction `movl`. La correction dans Cranelift consiste à supprimer les règles de réduction (lowering) erronées dans le backend qui gèrent ces expressions étendues sur 64 bits. L'exemple ci-dessus est alors traduit en `movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst` ce qui tronque correctement le calcul intermédiaire de `%local0 << 3` à 32 bits à l'intérieur du registre `%temp` qui est ensuite ajouté à la valeur `%base`. Les versions 4.0.1, 5.0.1 et 6.0.1 de wasmtime corrigent ce problème.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.