Des chercheurs de l'Université de Cambridge ont publié une technique permettant d'insérer silencieusement du code malveillant dans du code source évalué par des pairs. La méthode d'attaque préparée (CVE-2021-42574) est présentée sous le nom de Trojan Source et est basée sur la formation de texte qui semble différent pour le compilateur/interprète et la personne qui visualise le code. Des exemples de la méthode sont démontrés pour divers compilateurs et interpréteurs fournis pour C, C++ (gcc et clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go et Python.
La méthode est basée sur l'utilisation de caractères Unicode spéciaux dans les commentaires de code qui modifient l'ordre d'affichage du texte bidirectionnel. À l'aide de tels caractères de contrôle, certaines parties du texte peuvent être affichées de gauche à droite, tandis que d'autres - de droite à gauche. Dans la pratique quotidienne, de tels caractères de contrôle peuvent être utilisés, par exemple, pour insérer des lignes de code en hébreu ou en arabe dans un fichier. Mais si vous combinez des lignes avec des directions de texte différentes sur une seule ligne, en utilisant les caractères spécifiés, les passages de texte affichés de droite à gauche peuvent chevaucher le texte normal existant affiché de gauche à droite.
En utilisant cette méthode, vous pouvez ajouter une construction malveillante au code, mais ensuite rendre le texte avec cette construction invisible lors de la visualisation du code, en ajoutant dans le commentaire suivant ou à l'intérieur des caractères littéraux affichés de droite à gauche, ce qui conduira à complètement différents caractères se superposant à l'insertion malveillante. Un tel code restera sémantiquement correct, mais sera interprété et affiché différemment.
Lors de la révision du code, un développeur sera confronté à l'ordre visuel des caractères et verra un commentaire non suspect dans un éditeur de texte, une interface Web ou un IDE moderne, mais le compilateur et l'interprète utiliseront l'ordre logique des caractères et traiter l'insertion malveillante telle quelle, sans prêter attention au texte bidirectionnel dans les commentaires. Le problème affecte divers éditeurs de code populaires (VS Code, Emacs, Atom), ainsi que les interfaces de visualisation du code dans les référentiels (GitHub, Gitlab, BitBucket et tous les produits Atlassian).
Il existe plusieurs manières d'utiliser la méthode pour mettre en œuvre des actions malveillantes : ajouter une expression « return » cachée, qui conduit à l'achèvement de la fonction à l'avance ; commenter des expressions qui seraient normalement visibles en tant que constructions valides (par exemple, pour désactiver des vérifications importantes) ; attribuer d'autres valeurs de chaîne qui conduisent à des échecs de validation de chaîne.
Par exemple, un attaquant pourrait proposer une modification incluant la ligne : if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {
qui sera affiché dans l'interface de révision comme si access_level != "user" { // Vérifiez si admin
De plus, une autre variante d'attaque a été proposée (CVE-2021-42694), associée à l'utilisation d'homoglyphes, des caractères d'apparence similaire, mais de signification différente et ayant des codes Unicode différents (par exemple, le caractère « ɑ » ressemble à « a", "ɡ" - "g", "ɩ" - "l"). Des caractères similaires peuvent être utilisés dans certaines langues dans les noms de fonctions et de variables pour induire les développeurs en erreur. Par exemple, deux fonctions avec des noms indiscernables peuvent être définies et effectuer des actions différentes. Sans une analyse détaillée, il n’est pas immédiatement clair laquelle de ces deux fonctions est appelée à un endroit précis.
Par mesure de sécurité, il est recommandé que les compilateurs, les interprètes et les outils d'assemblage prenant en charge les caractères Unicode affichent une erreur ou un avertissement s'il existe des caractères de contrôle non appariés dans les commentaires, les littéraux de chaîne ou les identifiants qui modifient le sens de sortie (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E et U+200F). De tels caractères doivent également être explicitement interdits dans les spécifications du langage de programmation et doivent être respectés dans les éditeurs de code et les interfaces de référentiel.
Addendum 1 : Des correctifs de vulnérabilité ont été préparés pour GCC, LLVM/Clang, Rust, Go, Python et binutils. GitHub, Bitbucket et Jira ont également résolu le problème. Un correctif pour GitLab est en cours. Pour identifier le code problématique, il est suggéré d'utiliser la commande : grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ source
Addendum 2 : Russ Cox, l'un des développeurs du système d'exploitation Plan 9 et du langage de programmation Go, a critiqué l'attention excessive portée à la méthode d'attaque décrite, connue depuis longtemps (Go, Rust, C++, Ruby) et n'a pas été prise au sérieux . Selon Cox, le problème concerne principalement l'affichage correct des informations dans les éditeurs de code et les interfaces Web, qui peut être résolu en utilisant les outils et analyseurs de code appropriés lors de la révision. Par conséquent, au lieu d’attirer l’attention sur les attaques spéculatives, il serait plus approprié de se concentrer sur l’amélioration des processus de révision du code et des dépendances.
Ras Cox estime également que les compilateurs ne sont pas le bon endroit pour résoudre le problème, car en interdisant les symboles dangereux au niveau du compilateur, il reste une énorme couche d'outils dans lesquels l'utilisation de ces symboles reste acceptable, comme les systèmes de construction, les assembleurs, gestionnaires de packages et divers analyseurs de configuration et données. A titre d'exemple, le projet Rust est donné, qui a interdit le traitement du code LTR/RTL dans le compilateur, mais n'a pas ajouté de correctif au gestionnaire de packages Cargo, qui permet une attaque similaire via le fichier Cargo.toml. De même, des fichiers tels que BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml et Requirements.txt peuvent devenir des sources d'attaques.
Source: opennet.ru