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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

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


Sujet :

Sécurité

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Dirigeant
    Inscrit en
    Juin 2016
    Messages
    3 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Dirigeant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2016
    Messages : 3 160
    Points : 66 249
    Points
    66 249
    Par défaut La quasi-totalité du code informatique mondial peut être détournée par l'exploit "Trojan Source"
    La quasi-totalité du code informatique mondial peut être détournée par l'exploit "Trojan Source"
    selon une étude

    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.

    Nom : trojansource.png
Affichages : 65356
Taille : 390,3 Ko

    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.

    Nom : TrojanSource-editors-vulnerable.png
Affichages : 8988
Taille : 28,5 Ko

    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
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Invité
    Invité(e)
    Par défaut
    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.

  3. #3
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    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.

  4. #4
    Expert éminent Avatar de kain_tn
    Homme Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 562
    Points : 7 263
    Points
    7 263
    Par défaut
    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.
    Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include <stdio.h>
     
    int main(int argc, char **argv) {
     
        printf("So long, and thanks for the fish, Dennis...\n");
        return 0;
    }

  5. #5
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    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. #6
    Membre expérimenté

    Homme Profil pro
    Retraite
    Inscrit en
    Octobre 2005
    Messages
    477
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 72
    Localisation : France, Aude (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Retraite
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2005
    Messages : 477
    Points : 1 333
    Points
    1 333
    Billets dans le blog
    1
    Par défaut
    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 .........

  7. #7
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    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 :

Discussions similaires

  1. Réponses: 2
    Dernier message: 24/10/2019, 17h31
  2. [XL-2013] Fichier xlsm non partagé peut être ouvert par deux personnes en même temps
    Par J-MDavid dans le forum Macros et VBA Excel
    Réponses: 2
    Dernier message: 22/05/2019, 23h46
  3. Un lien qui ne peut être atteint par tabulation
    Par Benzeghiba dans le forum Balisage (X)HTML et validation W3C
    Réponses: 3
    Dernier message: 24/09/2010, 18h34
  4. Virus ? peut être eu par USB ?
    Par rpatruno dans le forum Sécurité
    Réponses: 24
    Dernier message: 15/09/2008, 00h10
  5. MMORPG : Ryzom peut être libre (code et data)
    Par PatB38 dans le forum Développement 2D, 3D et Jeux
    Réponses: 5
    Dernier message: 05/12/2006, 12h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo