💻 computer science

Mystra: Declarative Dynamic Taint Analysis via Shadow Virtual Machine

Cet article présente Mystra, un langage déclaratif et une architecture de machine virtuelle Shadow pour l'analyse de marquage dynamique qui découple la sémantique du marquage de l'instrumentation d'exécution, permettant à l'outil Shar d'atteindre une grande précision et un surcoût considérablement plus faible sur plusieurs environirs d'exécution JavaScript et Python par rapport aux solutions existantes.

Auteurs originaux : Zhuohao Zhang, Junkun Liu, Rui Yang, Yinzhi Cao, Ziyang Li

Publié 2026-07-15

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Zhuohao Zhang, Junkun Liu, Rui Yang, Yinzhi Cao, Ziyang Li

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez d'attraper un fantôme malicieux (une vulnérabilité de sécurité) qui se faufile dans une ville géante et trépidante (un programme informatique). Le fantôme commence sous la forme d'une goutte d'encre inoffensive (des données non fiables) dans une lettre, mais s'il atteint une porte spécifique (une opération sensible comme la lecture d'un fichier), il peut détruire tout l'immeuble.

Pendant longtemps, les experts en sécurité ont essayé d'attraper ce fantôme en utilisant deux méthodes principales, et les deux présentaient de gros problèmes. Une méthode consistait à réécrire les plans de la ville avant que quiconque n'y emménage (réécriture de la source). C'était sûr, mais cela ralentissait la ville jusqu'à un pas de tortue — la rendant 20 à 50 fois plus lente ! L'autre méthode consistait à embaucher un détective spécialisé qui ne connaissait que son propre quartier (natif au moteur). C'était rapide, mais si la ville changeait sa configuration ou si vous déménagiez dans un autre quartier, le détective devait être licencié et formé à nouveau de zéro.

Entrez en scène Mystra et Shar, une nouvelle équipe d'enquêteurs de l'Université Johns Hopkins, qui ont décidé de construire une « Ville Ombre » juste à côté de la ville réelle.

La Ville Ombre (Machine Virtuelle Ombre)

Au lieu de modifier la ville réelle ou de réécrire ses plans, les chercheurs ont construit une « Machine Virtuelle Ombre » parallèle et invisible qui fonctionne parallèlement au programme réel. Imaginez une ville jumelle fantomatique qui reflète chaque mouvement de la ville réelle.

Lorsqu'une opération réelle se produit — comme un appel de fonction à une autre fonction ou l'ouverture d'un fichier — la Ville Ombre voit instantanément l'action. Mais voici la magie : la Ville Ombre ne se soucie pas de la façon dont la ville réelle est construite. Que la ville réelle fonctionne sur un moteur moderne et rapide (comme V8 dans Node.js) ou sur un moteur plus ancien (comme CPython), la Ville Ombre voit exactement les mêmes « événements ». C'est comme avoir un traducteur universel qui permet aux enquêteurs de surveiller l'action sans s'emmêler dans la machinerie spécifique du moteur.

Le Livre de Règles (Mystra)

Observer la ville ne suffit pas ; il faut savoir ce que l'on cherche. C'est là que Mystra intervient. Mystra est un langage spécial et facile à lire (un langage « déclaratif ») où les experts en sécurité écrivent des règles simples comme : « Si un chemin de fichier provient d'un utilisateur, et que ce chemin est utilisé pour ouvrir un fichier, déclenchez l'alarme ! »

L'article soutient que les outils précédents étaient trop rigides, forçant les experts à écrire du code complexe et désordonné lié à des moteurs spécifiques. Mystra est différent. C'est comme un ensemble d'instructions LEGO que l'on peut emboîter sur n'importe quel moteur.

L'astuce de l'« Injection » et de l'« Extraction » : L'une des fonctionnalités les plus cool est la façon dont Mystra gère les « fonctions d'ordre supérieur » (comme Array.map en JavaScript). Imaginez une usine où une machine prend une boîte, la passe à un ouvrier pour la peindre, puis la remet en place. Mystra peut dire : « Injectez la saleté de la boîte dans les mains de l'ouvrier, et quand l'ouvrier a terminé, extrayez cette saleté sur la boîte. » Cela permet au système de suivre le « fantôme » même lorsqu'il saute dans une fonction de rappel (callback), ce qui posait problème aux outils précédents qui finissaient par s'embrouiller.

Les Résultats : Rapide et Précis

Les chercheurs ont construit un outil appelé Shar pour tester cette idée. Ils ne se sont pas contentés de deviner ; ils ont mesuré leurs résultats par rapport à des tests de référence réels.

Vitesse : Lorsqu'ils ont fait tourner Shar sur Node.js, le programme n'a ralenti que de 1,85 fois. Comparez cela aux anciens outils de réécriture de source, qui étaient 22,7 fois plus lents que Shar ! Shar est également 22,7 fois plus rapide que le meilleur outil précédent, NodeMedic-FINE, sur les mêmes charges de travail.
Précision : Sur un ensemble de test de 493 vulnérabilités connues (appelé SecBench.js), Shar en a capturé 95,5 %. Mieux encore, lorsqu'ils l'ont testé sur des versions corrigées du logiciel (où les failles avaient déjà été colmatées), Shar n'a déclenché aucune fausse alerte. Il n'a pas crié au loup une seule fois.
Portabilité : L'équipe a prouvé que leur idée fonctionne à travers différents mondes. Ils ont pris le même moteur central et les mêmes règles et ont réussi à les porter sur trois environnements d'exécution différents : V8 (utilisé dans Node.js et Chrome), SpiderMonkey (utilisé dans Firefox) et CPython (utilisé dans Python). Ils n'ont eu qu'à écrire un petit « adaptateur » pour chacun ; le cerveau principal restait le même.

Ce qu'ils n'ont PAS résolu

Il est important de savoir ce que cet outil ne fait pas. L'article stipule explicitement que Shar ne suit pas les « flux implicites ». Imaginez si le fantôme ne laissait pas de trace d'encre, mais changeait plutôt la couleur du ciel pour signaler un piège. Shar ne surveille pas le ciel ; il ne surveille que l'encre. Les auteurs notent que le suivi de ces signaux invisibles ralentirait massivement le système (par 36,7 fois dans d'autres études), ils ont donc choisi de se concentrer sur les traces visibles pour le moment.

Ils ont également constaté que si un programme décompose une chaîne de texte en petits morceaux (comme diviser une phrase en mots), le lien avec le texte « sale » d'origine peut parfois se perdre. C'est une limitation connue de ce type de suivi, et ils suggèrent que les travaux futurs devront peut-être examiner le suivi caractère par caractère pour corriger cela.

L'essentiel

L'article présente Shar et Mystra non pas comme une baguette magique qui résout tous les problèmes de sécurité, mais comme une étape majeure dans la façon dont nous suivons les données. En séparant ce que nous suivons (les règles) de la façon dont nous observons le programme (la Machine Virtuelle Ombre), ils ont créé un système qui est rapide, précis et flexible.

Dans leurs tests, ils ont démontré qu'on peut avoir un outil de sécurité qui soit à la fois un bolide et un détective aux yeux aiguisés, capable de repérer 95,5 % des vulnérabilités sans ralentir le programme qu'il protège. C'est la preuve qu'on n'a plus besoin de choisir entre vitesse et sécurité.

Résumé Technique : Mystra et Shar

Énoncé du Problème

L'analyse de propagation de marqueurs (Dynamic Taint Analysis - DTA) pour les langages interprétés comme JavaScript et Python fait face à une fragmentation architecturale fondamentale. Les systèmes existants couplent généralement les capacités d'observation des opérations du runtime hôte, le maintien des états de marqueurs parallèles et la définition de la propagation des marqueurs au sein d'un mécanisme d'instrumentation unique.

Les systèmes de réécriture de source (ex. Jalangi2, NodeMedic) instrumentent le code avant l'exécution. Bien qu'indépendants du moteur, ils introduisent une limite de transformation de la source qui nécessite que les modules soient disponibles et transpilés (souvent via Babel). Cette approche sacrifie l'exécution native et Just-In-Time (JIT), entraînant des ralentissements de performance d'un ordre de grandeur.
Les systèmes natifs aux moteurs (ex. Foxhound, PanoptiChrome) modifient les représentations de runtime ou les gestionnaires d'exécution pour gagner en visibilité. Cependant, leur état d'ombre (shadow state), leur logique de propagation et leur instrumentation sont étroitement liés aux structures internes d'un moteur spécifique. Cela rend la logique d'analyse inséparable du moteur, entravant la portabilité vers différents niveaux d'exécution, d'embarcations ou de langages.

Le problème central est l'absence d'un modèle d'exécution indépendant du runtime pour la DTA. Différents runtimes exposent des opérations via des jeux d'instructions (bytecodes), des piles et des stratégies de compilation variés, pourtant l'analyse de marqueurs nécessite la même information logique (identité, arguments, résultats, contexte). Les approches actuelles échouent à séparer l' observation des opérations de l'hôte de la sémantique des transitions d'état de marqueurs, ce qui entraîne un overhead élevé ou une faible portabilité.

Méthodologie

Les auteurs proposent une solution composée de trois composants principaux : une Machine Virtuelle d'Ombre (Shadow VM), le langage de spécification déclaratif Mystra, et le framework d'implémentation Shar.

1. La Machine Virtuelle d'Ombre (Shadow VM)

La Shadow VM est une machine virtuelle parallèle qui s'exécute aux côtés de divers runtimes hôtes (ex. V8, SpiderMonkey, CPython). Elle maintient un état parallèle $\sigma = \langle S, H, G, C \rangle$ :

Pile d'Ombre (Shadow Stack - $S$ ) : Suit les cadres d'opérations actifs dans l'ordre d'imbrication des événements, mappant les opérandes à des identifiants de marqueurs. Elle gère les transferts de contrôle non locaux (exceptions, suspensions asynchrones) en se synchronisant avec la continuation logique de l'hôte.
Tas d'Ombre (Shadow Heap - $H$ ) : Suit les propriétés d'objets persistant à travers les cadres, mappant les paires adresse-objet/clé-propriété à des identifiants de marqueurs pour éviter de marquer l'intégralité des objets.
DAG de Provenance ( $G$ ) : Enregistre l'origine du marqueur, reliant les nœuds de flux aux marqueurs des opérandes pour reconstruire les chemins source-vers-puits (source-to-sink).
Contexte de Spécification ( $C$ ) : Fournit des stockages nommés pour les données persistant à travers les frontières d'invocation (ex. E/S de fichiers), comblant les lacunes où la pile/le tas d'ombre perdraient normalement la connexion.

La Shadow VM interagit avec l'hôte via une Interface Hôte médiée par des adaptateurs. Cette interface standardise six capacités : événements d'opération (entrée/sortie), adressage d'opérande, identité d'opération, cycle de vie d'objet, requêtes de runtime et synchronisation de continuation. Cela permet à la Shadow VM d'observer l'exécution interprétée, native et compilée JIT de manière uniforme sans forcer de déoptimisation.

2. Mystra : Langage de Spécification de Marqueurs Déclaratif

Mystra est un DSL (langage de domaine spécifique) compilé et déclaratif doté de sémantiques opérationnelles formelles, conçu pour piloter la Shadow VM. Il sépare le quoi suivre du comment le suivre.

Constructions Fondamentales : Les règles définissent les source (points d'entrée), sink (opérations dangereuses), propagate (flux entre opérations) et clear (sanitisation/nettoyage).
Fonctions d'Ordre Supérieur (HOF) : Une innovation clé réside dans les actions inject et extract. Elles modélisent les fonctions natives d'ordre supérieur (ex. Array.map) en faisant le pont entre la boucle native opaque et le callback utilisateur visible. inject transfère le marqueur du conteneur vers le paramètre du callback ; extract agrège les marqueurs de retour vers le conteneur.
Prédicats Gardés : Les règles peuvent inclure des clauses where pour conditionner les actions sur des prédicats de runtime (ex. vérifier si un objet est un prototype), réduisant ainsi les faux positifs.
Contexte de Spécification : L'action set permet aux règles de persister le marqueur à travers les frontières (ex. écrire un chemin de fichier dans un stockage global et le récupérer plus tard).
Compilation : Les règles Mystra sont compilées à l'avance en une représentation binaire (.tbin). Le compilateur effectue la vérification de type et planifie les actions dans des listes d'instructions de pré et post-accroche, permettant un dispatch en $O(1)$ sans parsing au runtime.

3. Implémentation Shar

Shar est le framework de DTA concret implémentant cette architecture. Il présente un noyau partagé (moteur de marqueurs, interprète, chargeur de règles, DAG, contexte) et des adaptateurs spécifiques au runtime. Les auteurs ont instancié Shar sur trois axes orthogonaux :

Embarcation (Embedding) : V8 dans Node.js et Chromium.
Moteur (Engine) : SpiderMonkey.
Langage : CPython.

Contributions Clés

Abstraction de la Shadow VM : Une machine abstraite indépendante du runtime qui sépare l'observation du runtime de l'état et des transitions de marqueurs, permettant la portabilité entre moteurs et langages.
Langage Mystra : Un langage déclaratif compilé avec des sémantiques opérationnelles formelles qui supporte des comportements de marqueurs expressifs, incluant le pontage des fonctions d'ordre supérieur via inject/extract.
Framework Shar : Un framework de DTA multilingue démontrant la portabilité à travers V8 (Node.js/Chromium), SpiderMonkey et CPython avec un noyau partagé.
Évaluation Systématique : Benchmarks complets sur la précision de détection, les performances, l'expressivité et la portabilité.

Résultats

Précision de Détection

Évalué sur SecBench.js (493 CVE dans le périmètre à travers quatre catégories CWE) :

Rappel (Recall) : Shar a atteint un rappel global de 95,5 %.
Précision (Precision) : Aucun faux positif n'a été observé lors des tests sur les versions patchées.
Comparaison : Sur le sous-ensemble des cas d'injection de code et d'injection de commande (136 au total), Shar a détecté 97,1 % (132/136), surpassant nettement NodeMedic-FINE qui n'en a détecté que 63,9 % (87/136). Shar a détecté de manière unique 46 cas manqués par NodeMedic-FINE, principalement en raison de l'incapacité de NodeMedic à instrumenter certains packages via Babel ou de sa perte de marqueur avant le puits (sink).
Vulnérabilités Réelles : Shar a détecté avec succès 11 des 12 vulnérabilités réelles divulguées entre 2024 et 2026 à travers Node.js, Chromium et CPython. Un cas (n8n) a été partiellement détecté en raison d'une limitation dans le pontage des frontières de persistance SQL sans règles de pontage explicites.

Performance

Évalué sur le benchmark de NodeMedic :

Overhead : Shar n'a engendré qu'un overhead de runtime de 1,85× par rapport à vanilla Node.js.
Comparaison : C'est 22,7× inférieur à l'overhead de NodeMedic-FINE (41,95×) et nettement meilleur que les outils de réécriture de source comme Jalangi (28,78×).
Impact JIT : L'overhead est resté faible même avec Maglev JIT activé (1,28× par rapport à la base), démontrant que la Shadow VM ne force pas de déoptimisation.

Expressivité et Portabilité

Synthèse de Règles : Les auteurs ont démontré que les LLM pouvaient synthétiser des règles Mystra valides. Avec une seule itération de feedback diagnostique, le taux de réussite des règles synthétisées pour 32 patterns est passé de 19/32 à 29/32.
Concision : Les règles Mystra pour les bibliothèques standards de Node.js couvrent 97,2 % des API modélisées par CodeQL avec 18× moins de lignes de code (63 LoC contre 1 149 LoC).
Portabilité : Le noyau partagé (3 941 LoC) est resté identique pour V8, SpiderMonkey et CPython. L'effort de portage s'est concentré sur les adaptateurs et les liaisons spécifiques au runtime (ex. 446 LoC pour l'adaptateur CPython), confirmant la conception indépendante du runtime.

Signification

L'article affirme que Mystra et Shar représentent un passage d'une DTA lourde en instrumentation et spécifique aux moteurs vers une approche déclarative et indépendante du runtime. En séparant le mécanisme d'observation (Shadow VM) de la sémantique des marqueurs (règles Mystra), le système atteint :

Portabilité : La capacité de déployer la même logique d'analyse sur différents moteurs (V8, SpiderMonkey) et langages (JS, Python) avec une modification minimale.
Performance : Un overhead drastiquement réduit par rapport aux approches de réécriture de source, rendant la DTA viable pour les environnements de production et le code optimisé par JIT.
Expressivité : La capacité de modéliser de manière déclarative des comportements complexes comme les callbacks de fonctions d'ordre supérieur et les états de frontière (E/S de fichiers) sans coder en dur la logique spécifique au moteur.
Prêt pour l'IA : Les sémantiques formelles et la syntaxe concise de Mystra le rendent adapté à la synthèse automatisée par les modèles de langage (LLM), facilitant la création rapide de règles pour de nouvelles classes de vulnérabilités.

Les auteurs concluent que bien que des défis subsistent concernant les flux implicites, la décomposition de chaînes et les frontières de stockage externe, cette architecture fournit une fondation évolutive pour la prochaine génération d'analyse de propagation de marqueurs.