Deux failles Wasmtime critiques permettraient à un module WebAssembly malveillant de s'échapper de son bac à sable.

Les mainteneurs de Wasmtime ont signalé deux failles Wasmtime jugées critiques. Ce runtime WebAssembly peut être intégré dans d’autres logiciels. Or, ces vulnérabilités pourraient permettre à un module malveillant de sortir du bac à sable censé l’isoler. Des versions corrigées ont été publiées.

Deux failles Wasmtime jugées critiques

Wasmtime exécute du code WebAssembly en dehors d’un navigateur. Les développeurs l’embarquent dans des applications, des services cloud ou des plateformes de plugins. Son rôle est simple : faire tourner du code non fiable sans qu’il touche au reste du système.

Cette promesse d’isolation est donc au cœur du produit. Si elle échoue, un module piégé peut dépasser les limites prévues. Par conséquent, les mainteneurs ont classé les deux défauts au niveau critique.

Les deux vulnérabilités ne sont pas identiques. En effet, l’une d’elles ne concerne que les systèmes ARM64. L’autre n’est pas limitée à cette architecture, d’après les informations disponibles.

Un scénario d’attaque sous conditions

L’exploitation n’est pas immédiate. D’abord, l’attaquant doit amener une version vulnérable de Wasmtime à compiler un module qu’il contrôle. Ensuite, c’est cette étape de compilation qui ouvre la voie à l’évasion du bac à sable.

Autrement dit, la menace dépend de la façon dont Wasmtime est utilisé. Un service qui n’exécute que des modules maîtrisés court moins de risques. En revanche, une plateforme qui accepte du code WebAssembly envoyé par des tiers est davantage exposée.

Cette précision compte pour évaluer l’urgence. Toutefois, elle ne justifie pas d’attendre. Beaucoup d’environnements permettent justement à des utilisateurs de fournir leurs propres modules.

Le cas particulier d’ARM64

Le premier défaut touche uniquement l’architecture ARM64. Cette plateforme est très répandue aujourd’hui. On la trouve notamment dans des serveurs cloud, des postes de travail récents et des appareils en périphérie du réseau.

Les équipes doivent donc vérifier l’architecture de leurs machines. Un parc entièrement en x86-64 ne sera pas concerné par cette faille précise. Cependant, l’autre vulnérabilité reste à traiter dans tous les cas.

Pourquoi les failles Wasmtime inquiètent les intégrateurs

Un bac à sable est une barrière de sécurité. Quand elle cède, l’attaquant peut tenter d’agir hors du périmètre prévu. Les conséquences exactes varient selon l’application hôte et ses privilèges.

Par ailleurs, Wasmtime sert souvent de brique dans une chaîne plus large. Un éditeur peut l’intégrer sans que ses clients le sachent. Ainsi, une vulnérabilité du runtime se répercute sur tous les produits qui l’embarquent.

C’est pourquoi l’inventaire des dépendances est essentiel. Beaucoup d’organisations ignorent qu’un composant WebAssembly tourne dans leur pile logicielle. Pourtant, c’est la première chose à clarifier lors d’un correctif de ce type.

De plus, les failles touchant la compilation sont délicates. Le compilateur transforme du code non fiable en instructions machine. Une erreur à ce stade peut donc produire du code qui contourne les protections prévues.

Recommandations

Les mainteneurs ont publié des versions corrigées. Les équipes concernées doivent agir sans délai.

• Mettre à jour Wasmtime vers une version corrigée. Les numéros exacts figurent dans les avis de sécurité du projet.
• Recenser les usages du runtime, y compris lorsqu’il est embarqué dans un produit tiers.
• Identifier les machines ARM64 afin de mesurer l’exposition à la faille spécifique à cette architecture.
• Limiter les sources de modules : n’acceptez que du code WebAssembly provenant de sources de confiance, tant que le correctif n’est pas déployé.
• Surveiller les mises à jour des éditeurs qui intègrent Wasmtime dans leurs solutions.

Ce qu’il faut retenir

Ces deux vulnérabilités critiques concernent l’isolation, fonction centrale de Wasmtime. L’attaque suppose qu’une version vulnérable compile un module contrôlé par l’attaquant. De plus, l’une des failles ne touche que les systèmes ARM64.

Le correctif existe, donc la priorité est de l’appliquer. Les plateformes qui exécutent du code tiers doivent agir en premier. Enfin, vérifiez les avis officiels du projet pour obtenir les identifiants CVE et les versions à installer.

Source : Two Critical Wasmtime Flaws Could Let Malicious WebAssembly Modules Escape Sandboxes