12 novembre 2021

Les attaques « Trojan-Source » permettent de compiler un binaire qui ne correspond pas au code source visible

Code, HTML, php web programming source code. Abstract code background - 3d  rendering Stock Illustration | Adobe Stock

Introduction

Deux chercheurs de l’université de Cambridge, Nicholas Boucher et Ross Anderson, ont récemment publié un article détaillant un nouveau vecteur d’attaque, qui consiste à insérer dans un code source des vulnérabilités invisibles à l’œil nu.

Unicode Bidi Algorithm

La plupart des langues s’écrivent de gauche à droite, comme le français ou l’anglais, mais d’autres s’écrivent de droite à gauche, comme l’arabe. Le standard Unicode s’appuie sur son algorithme bidirectionnel (Bidirectional Algorithm en anglais), ou « Bidi », pour intégrer au sein d’un texte, une portion de texte qui se lit dans l’autre sens que le reste du document.

Assignée à l’identifiant CVE-2021-42574 , la vulnérabilité exploite les caractères de formatage de Bidi pour forcer la réorganisation visuelle du code source. En revanche, l’ordre logique des caractères lus par un compilateur ou un interpréteur ne sera pas modifié, créant une différence entre le code lu par un humain et celui évalué par un programme.

Les auteurs de l’étude précisent qu’il est possible d’obtenir une réorganisation presque arbitraire des chaînes de caractères en imbriquant plusieurs caractères de contrôle Bidi les uns dans les autres. Il est donc possible de construire toutes les combinaisons possibles à partir des caractères visuels présents.

Exploitation

Les caractères de contrôle Bidi permettent de changer le rendu visuel d’un code source. Mais ces caractères ne font pas partie de la syntaxe des compilateurs et interpréteurs standards, et provoqueront donc une erreur lors du traitement du code source.

Les deux chercheurs contournent cette limitation en plaçant les caractères dans des commentaires ou des chaînes de caractères. Le rôle d’un commentaire est en effet d’être ignoré par le compilateur, et les chaînes de caractères ne sont pas non plus analysées.

Après avoir évité les erreurs du compilateur, il reste encore à leurrer un lecteur humain. Il faut pour cela que le code source réordonné visuellement soit valide, notamment au niveau de la syntaxe, car même si ce code lu par un humain ne sera jamais traité par un programme, une erreur de syntaxe ou de logique ne passera pas inaperçue.

Figure 1 : Exemple d’attaque de mise en commentaire

Les chercheurs dégagent ainsi trois techniques pour réorganiser efficacement un code source :

  • Les retours anticipés (Early Returns) court-circuitent une fonction en exécutant une instruction return qui semble visuellement se trouver dans un commentaire.
  • La mise en commentaire (Commenting-Out) fait en sorte qu’un commentaire apparaisse visuellement comme du code, qui à son tour n’est pas exécuté.
  • Les chaînes étirées (Stretched Strings) font en sorte que des parties de chaînes de caractères apparaissent visuellement comme du code, ce qui a le même effet que la mise en commentaire et fait échouer les comparaisons de chaînes.

Impact et remédiation

En même temps que l’article, les chercheurs ont publié un dépôt git contenant des preuves de concept de ces techniques d’attaque sur les langages C, C++, C#, Go, Java, JavaScript, Python et Rust. Ces « POC » ne contiennent pas de code malicieux, mais toute l’étude a été menée en gardant en tête les utilisations malveillantes qui pourraient en être faites, en particulier des attaques sur la chaîne d’approvisionnement (supply chain attacks) de projets open-source.

Bien que n’étant pas une « vulnérabilité » au sens classique du terme, la CVE-2021-42574 impressionne par sa surface d’attaque et affecte les compilateurs, interpréteurs, éditeurs de code et services web de dépôt de code de dix-neuf entreprises et organisations indépendantes.

Une défense devrait être implémentée dans tous les outils de développement logiciel, de la spécification du langage au compilateur, de l’éditeur de texte au dépôt de code, mais les auteurs soutiennent que le moyen de prévention le plus efficace sera de sécuriser les compilateurs.

Les deux chercheurs profitent en outre de cette opportunité pour partager dans leur article leur expérience de divulgation coordonnée, et détaillent des statistiques intéressantes sur les processus de traitement de vulnérabilités des dix-neuf fournisseurs impliqués.

Références

https://trojansource.codes/trojan-source.pdf

https://trojansource.codes

https://github.com/nickboucher/trojan-source/blob/main/README.md

https://arxiv.org/abs/2111.00169

12 novembre 2021 CERT

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *