IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La quasi-totalité du code informatique mondial peut être détournée par l'exploit "Trojan Source",
Selon une étude

Le , par Bill Fassinou

161PARTAGES

19  0 
Des chercheurs de l'université de Cambridge ont découvert un bogue qui affecte la plupart des compilateurs de code informatique et de nombreux environnements de développement de logiciels. La vulnérabilité concerne un composant de la norme de codage de texte numérique Unicode, qui permet aux ordinateurs d'échanger des informations indépendamment du langage utilisé. Précisément, elle concerne l'algorithme bidirectionnel ou "Bidi" d'Unicode, qui gère l'affichage de textes comprenant des écritures mixtes avec des ordres d'affichage différents, comme l'anglais et l'arabe - qui se lit de droite à gauche.

Unicode, officiellement la norme Unicode, est un standard informatique pour l'encodage, la représentation et la manipulation cohérents de textes exprimés dans la plupart des systèmes d'écriture du monde. La norme, qui est maintenue par le Consortium Unicode, définit actuellement 144 697 caractères couvrant 159 écritures modernes et historiques, ainsi que des symboles, des emoji et des codes de contrôle et de formatage non visuels. Mais une nouvelle étude a révélé que la norme contient une vulnérabilité qui pourrait (dans le pire des cas) entraîner des attaques à grande échelle de la chaîne d'approvisionnement.



La faille en question a été découverte par des chercheurs de l'université de Cambridge, en Angleterre, qui l'ont appelée la vulnérabilité "Trojan Source". Trojan Source repose sur l'utilisation de caractères de contrôle bidirectionnels dans les commentaires du code source. Aussi connus sous le nom de caractères BiDi, ces caractères de contrôle Unicode sont utilisés dans une ligne de texte pour signaler le passage d'un mode LTR (gauche à droite) à un mode RTL (droite à gauche) ou vice versa. Dans la pratique, ces caractères sont en effet destinés uniquement aux applications logicielles et sont invisibles à l'œil humain.

Ils ne sont utilisés que pour intégrer du texte dans un sens de lecture différent à l'intérieur de grands blocs de texte (comme l'insertion de chaînes arabes ou hébraïques dans de grands blocs de texte latin). L'équipe de recherche a déclaré avoir découvert que la plupart des compilateurs et éditeurs de code ne disposent pas de protocoles permettant de gérer les caractères BiDi ou de signaler leur présence dans les commentaires du code source. Les chercheurs ont déclaré que les attaquants pourraient insérer des caractères de contrôle BiDi à l'intérieur des commentaires que les réviseurs humains ne pourront pas voir.

« Vous pouvez les [les caractères BiDi] utiliser dans un code source qui semble inoffensif pour un examinateur humain et qui peut en fait faire quelque chose de méchant », a déclaré Ross Anderson, professeur de sécurité informatique à Cambridge et co-auteur de l'étude, dans un billet de blogue publié lundi. « C'est une mauvaise nouvelle pour des projets comme Linux et Webkit qui acceptent des contributions de personnes aléatoires, les soumettent à un examen manuel, puis les incorporent dans du code critique. Cette vulnérabilité est, pour autant que je sache, la première à affecter presque tout », a-t-il ajouté.

Ainsi, une fois compilés, ces caractères déplaceront le texte du champ de commentaire dans le code exécutable ou déplaceront le code (lié à la sécurité) dans une section commentée, ouvrant les applications aux attaques ou annulant les contrôles de sécurité. « Nous avons vérifié que cette attaque fonctionne contre C, C++, C#, JavaScript, Java, Rust, Go et Python, et nous soupçonnons qu'elle fonctionnera contre la plupart des autres langages modernes », explique Anderson. Selon lui, une telle attaque pourrait être difficile à détecter pour un examinateur de code humain, car le code source rendu semble parfaitement acceptable.

En plus des compilateurs de code, Anderson et son collègue Nicholas Boucher ont déclaré que de nombreux éditeurs de code et services d'hébergement de code source étaient également vulnérables [voir tableau ci-dessous]. En tant que tel, Trojan Source pourrait hypothétiquement être utilisé par les acteurs malveillants pour lancer des attaques à grande échelle de la chaîne d'approvisionnement. De telles attaques, comme la récente campagne de SolarWinds, impliquent le déploiement silencieux de programmes malveillants dans des logiciels afin de compromettre les systèmes et réseaux de cibles spécifiques.



En théorie, les pirates pourraient utiliser cet exploit pour encoder des vulnérabilités dans des écosystèmes logiciels entiers, ce qui leur permettrait d'être utilisés pour des piratages plus ciblés. Ainsi, les chercheurs indiquent que la vulnérabilité constitue "une menace immédiate". Outre l'attaque liée aux caractères BiDi, les deux chercheurs ont également découvert que les compilateurs de code source étaient également vulnérables à un deuxième problème, connu sous le nom d'attaque par homoglyphe - où les lettres latines classiques sont remplacées par des caractères similaires provenant d'autres ensembles de la famille Unicode (alphabets).

Les chercheurs ont déclaré que cette deuxième attaque pouvait être utilisée pour créer deux fonctions différentes qui semblent identiques aux yeux d'un réviseur de code humain, mais qui sont en réalité différentes l'une de l'autre. Selon l'équipe, un attaquant pourrait utiliser une dépendance ou un plug-in pour définir la fonction homoglyphe en dehors de la base de code principale de l'application et ajouter du code malveillant à un projet à l'insu du responsable.

Étant donné que la plupart des processus de codage actuels reposent sur les contributions d'une équipe de plusieurs développeurs, l'équipe de recherche a fait valoir qu'il était important que les compilateurs et les éditeurs de code détectent les caractères BiDi et les homoglyphes et signalent aux réviseurs de code humains que des glyphes Unicode non standard sont utilisés dans le code source - généralement écrit dans le jeu de caractères latins.

Les deux chercheurs ont déclaré avoir donné à toutes les parties concernées un délai de 99 jours pour corriger les deux attaques dans leurs outils avant de publier les détails de l'attaque Trojan Source lundi. Le document suggère de mettre en œuvre diverses nouvelles protections visant spécifiquement à défendre les compilateurs comme moyen d'écarter ce nouveau problème majeur. Quelques heures après, l'équipe à l'origine du compilateur officiel du langage Rust a publié une mise à jour de sécurité pour corriger les deux attaques - identifiées comme CVE-2021-42574 (l'attaque utilisant les caractères BiDi) et CVE-2021-42694 (l'attaque utilisant les homoglyphes).

D'autres corrections sont attendues dans les jours à venir. « Avant de lire cet article, l'idée qu'Unicode puisse être exploité d'une manière ou d'une autre ne m'aurait pas surpris », a déclaré Matthew Green, professeur associé à l'Institut de sécurité informatique Johns Hopkins. « Ce qui me surprend, c'est le nombre de compilateurs qui analysent joyeusement l'Unicode sans aucune défense, et l'efficacité de leur technique d'encodage de droite à gauche pour introduire du code dans les bases de données. C'est une astuce très intelligente que je ne savais même pas possible. Oups ! », a jouté Green.

Selon lui, la bonne nouvelle est que les chercheurs ont procédé à une analyse généralisée des vulnérabilités. Mais qu'ils n'ont pas pu trouver de preuves que quelqu'un exploitait cette technique. « La mauvaise nouvelle, c'est qu'il n'y avait aucune défense contre cette faille, et maintenant que les gens sont au courant, ils pourraient commencer à l'exploiter. Espérons que les développeurs de compilateurs et d'éditeurs de code appliqueront rapidement des correctifs. Mais comme certaines personnes ne mettent pas à jour leurs outils de développement régulièrement, il y aura un certain risque pendant un certain temps au moins », a déclaré Green.

Sources : Rapport de l'étude (PDF), Trojan Source, Preuve de concept

Et vous ?

Que pensez-vous de la vulnérabilité Trojan Source ?

Voir aussi

Unicode 14.0 est disponible et s'accompagne 37 nouveaux émojis pour un total de 112 nouveaux personnages disponibles dans les mois à venir sur tous les appareils

La vulnérabilité d'un plug-in WordPress a ouvert un million de sites à une prise de contrôle à distance, cette faille permet à toute personne non identifiée d'accéder aux informations sensibles

Des logiciels malveillants ont été découverts dans le très populaire paquet npm "ua-parser-js", notamment un mineur de cryptomonnaie et un cheval de Troie

Le trojan bancaire IcedID entre directement à la 2e place dans le classement Check Point Research sur les malwares de mars 2021 après avoir exploité la pandémie de la COVID-19

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 03/11/2021 à 17:50
Citation Envoyé par Jeff_67 Voir le message
En général, les langages de programmation s'écrivent de gauche à droite. Les caractères de contrôle bidirectionnel devraient tout simplement être proscrits du code. Un code en anglais de gauche à droite, avec des sections de commentaires en Hébreu ou en Arabe de droite à gauche, doit poser d'autres problèmes plus prégnants que la sécurité. Je n'ose imaginer ce que ça donne niveau affichage et lisibilité.
Aucun langage à ma connaissance ne gère les caractères bidirectionnels dans le code. Il ne sont normalement utilisables que dans les endroits où tout Unicode est autorisé, à savoir les commentaires et les chaines de caractères, des endroits ou leur usage est justifiable.

Citation Envoyé par Jeff_67 Voir le message
Pour les homoglyphes, c'est un peu plus compliqué. Je pense pour ma part qu'utiliser les caractères autres que l'ASCII est une très mauvaise pratique (sauf s'ils sont dans une string ou un commentaire bien entendu). Hélas, wokisme oblige, tout le monde ne va pas être de cet avis.
Merci de ne pas lancer une nouvelle opposition idiote wokisme/anti-wokisme. Ce sujet est certes un moyen à la mode pour discréditer un propos sans chercher à y réfléchir en profondeur, que l'on soit pro ou anti, mais ça ne grandit pas un débat.
Le sujet de l'acceptation docile de hégémonie de l'anglais n'a juste rien à voir avec le wokisme qui est un mouvement social, pas linguistique.
16  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 03/11/2021 à 22:45
Pour les homoglyphes, c'est un problème connu depuis longtemps maintenant et ça fait un moment que certains compilateur sont capables d'émettre des warnings. Je sais de c'est au moins le cas du compilateur Rust.
6  0 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 03/11/2021 à 18:13
Citation Envoyé par Bill Fassinou Voir le message

Que pensez-vous de la vulnérabilité Trojan Source ?
Le concept est intéressant mais les exemples qu'ils mettent en avant ne sont pas si effrayants: le code injecté n'est pas invisible, lui. C'est juste un jeu pour tromper la compréhension des humains.

Sur leur dépôt Github, ils ont mis trois concepts basés sur cette vulnérabilité:
  • Commenting out
  • Stretched string
  • Homoglyph function


Pour les deux premiers cas, je vois un fix rapide à appliquer sur vos dépôts, qu'ils soient publics ou privés: un pre-push hook (ou pre-commit si vous avez un système centralisé à la Subversion) qui refuse les contributions qui contiennent LTR ou RTL. Quant au code existant, appliquer un script qui remplace des caractères par des espaces pour les rendre innoffensifs.

Pour ce qui est des fonctions homoglyphes c'est un peu plus complexe, malheureusement. Mais de même que l'on impose des normes de développement, on peut (et on devrait) aussi imposer une langue de communication afin de permettre à une équipe projet de travailler ensemble. Et dans ce cas, même traitement: pre-push hook qui vire les contributions qui contiennent des caractères en dehors d'une certaine plage.
1  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 21/11/2021 à 14:57
Concernant la CVE-2021-42574 avec le texte bidirectionnel, l'équipe Rust avait vite réagi en publiant, dès le 1er novembre, une nouvelle version de rustc avec des lints qui avertissent du problème.

Plus d'infos :
1  0 
Avatar de JPLAROCHE
Membre expérimenté https://www.developpez.com
Le 07/11/2021 à 10:46
Citation Envoyé par Jeff_67 Voir le message
En général, les langages de programmation s'écrivent de gauche à droite. Les caractères de contrôle bidirectionnel devraient tout simplement être proscrits du code. Un code en anglais de gauche à droite, avec des sections de commentaires en Hébreu ou en Arabe de droite à gauche, doit poser d'autres problèmes plus prégnants que la sécurité. Je n'ose imaginer ce que ça donne niveau affichage et lisibilité.

Pour les homoglyphes, c'est un peu plus compliqué. Je pense pour ma part qu'utiliser les caractères autres que l'ASCII est une très mauvaise pratique (sauf s'ils sont dans une string ou un commentaire bien entendu). Hélas, wokisme oblige, tout le monde ne va pas être de cet avis.
je programme en utf8, voir unicode , et fait du hack clavier et screen , l'ASCII ne reprend pas toutes les lettres de l'alphabet international .... j'ai des chinois ou japonais qui vienne récupérer mon code , et quand tu programmes et pense ne pas te limiter aux langues latines, mais par exemple en hébreux ou arabe de droite à gauche ce n'est pas vraiment un problème ce sont tes indices dans la zone de saisie qui fonctionne dans l'autre sens .........
0  0 
Avatar de
https://www.developpez.com
Le 03/11/2021 à 17:22
En général, les langages de programmation s'écrivent de gauche à droite. Les caractères de contrôle bidirectionnel devraient tout simplement être proscrits du code. Un code en anglais de gauche à droite, avec des sections de commentaires en Hébreu ou en Arabe de droite à gauche, doit poser d'autres problèmes plus prégnants que la sécurité. Je n'ose imaginer ce que ça donne niveau affichage et lisibilité.

Pour les homoglyphes, c'est un peu plus compliqué. Je pense pour ma part qu'utiliser les caractères autres que l'ASCII est une très mauvaise pratique (sauf s'ils sont dans une string ou un commentaire bien entendu). Hélas, wokisme oblige, tout le monde ne va pas être de cet avis.
4  8