Les nouvelles versions de Xcode arrivent en général juste après les mises à jour Apple de macOS ou d’IOS, et fournissent un support officiel et de la documentation pour les nouvelles fonctionnalités de programmation dans les dernières versions du système d’exploitation.
La version Xcode 11.2 est toutefois un peu différente, même si elle suit de près les mises à jour récentes de macOS 10.15.1 et d’iOS 13.2.1.
Xcode 11.2 a été publiée avec son propre avertissement de sécurité vous invitant à obtenir (puis à vérifier que vous l’avez correctement installée) cette nouvelle version, en mentionnant explicitement les failles de sécurité nommées CVE-2019-8800 et CVE-2019-8806.
APPLE-SA-2019-11-01-1 (SA signifiant “Security Advisory”, à savoir ‘Avertissement de Sécurité’) décrit ces défauts de manière généralement superficielle :
Le traitement d’un fichier conçu de manière malveillante pourrait permettre l’exécution de code arbitraire.
En d’autres termes, il semblerait que la tâche, à priori inoffensive, qui consiste simplement à compiler ou à construire un projet logiciel, une action qui en général n’a pas d’impact négatif particulier, pourrait injecter des malwares dans votre système.
Une telle vulnérabilité peut sembler peu spectaculaire, étant donné que la première chose que vous faites en général après le développement d’une nouvelle version de code source est de la tester, signifiant ainsi que vous allez lancer, en l’état, l’application que vous venez de créer.
Ainsi, des cybercriminels qui souhaiteraient pénétrer au sein de votre réseau via votre système de build pourraient simplement n’avoir qu’à ajouter un code malveillant dans la source elle-même, prête à être compilée directement au niveau de la sortie du processus de build.
Ensuite, ces derniers n’auraient plus qu’attendre que vous exécutiez l’application trojanisée après l’avoir développée, ce que vous allez certainement faire, sinon vous n’auriez pas pris la peine de la créer.
Pourquoi infecter le système de build ?
Cependant, le problème reste sérieux, à savoir que dans de nombreuses entreprises qui construisent leur propre logiciel, le système de build lui-même est supposé être correct et inviolable. Il est configuré avec soin et dans un but bien précis, de sorte que le logiciel qu’il permet de créer ne soit jamais exécuté dans ce même système.
En termes simples, le processus de création de votre nouveau programme à partir du code source est toujours bien séparé du test et de sa validation avant le déploiement.
Ainsi, s’il existe un bug dangereux dans cette nouvelle application, introduit accidentellement ou délibérément, vous avez une chance de le trouver pendant votre processus de test, au lieu de mettre en péril le système de build ou votre réseau.
Les systèmes de test sont généralement reconstruits à chaque utilisation, par exemple à l’aide d’un logiciel de virtualisation et de gestion de la configuration, de manière à ce que chaque test soit autonome et ne puisse être affecté, positivement ou négativement, par ce qui s’est passé durant le test précédent.
Par exemple, si une application nécessite l’installation d’une DLL spécifique en parallèle pour pouvoir fonctionner et que vous souhaitez vérifier que la DLL nécessaire soit correctement installée si elle n’est pas présente au départ, vous devez vous assurer qu’elle n’a pas été oubliée lors d’un test précédent surtout si elle correspond, en plus, à une autre version du logiciel.
Toutefois, les systèmes de build ne sont pas toujours traités de la même façon, les malwares qui ciblent spécifiquement le processus de build peuvent devenir de véritables casse-têtes et s’avérer difficiles à trouver.
Quand les développeurs deviennent des “diffuseurs de malwares approuvés”
Il y a dix ans, un virus appelé W32/Induc-A s’était répandu dans le monde entier et avait mis des mois à être éradiqué, précisément parce qu’il ciblait les développeurs de logiciels avec l’objectif de les transformer en “diffuseurs approuvés”.
Le malware Induc n’infecte activement votre système que si le compilateur Delphi est installé, sinon il reste caché bien tranquillement, faisant en sorte d’attirer très peu l’attention sur lui.
Cependant, si vous étiez un développeur Delphi, le virus a réécrit l’un des fichiers du code source faisant partie du système de build lui-même.
Au final, tout programme compilé par la suite aura été infecté par le malware, mais ne se montrera plus avant que le programme nouvellement compilé soit installé sur l’ordinateur d’un autre développeur.
Paradoxalement, dans de nombreuses entreprises disposant d’équipes de développement internes, les conseils traditionnels en matière de sécurité ont été temporairement bouleversés, car les logiciels Delphi construits en interne étaient quasiment tous infectés à coup sûr, alors que des logiciels inconnus, et à priori non fiables, téléchargés depuis des sites pris au hasard sur internet avaient certainement au moins une chance d’être inoffensif.
Dans le même genre d’attaque en deux étapes, le tristement célèbre virus Stuxnet a affecté les dispositifs industriels de contrôle (à priori les centrifugeuses de l’usine d’enrichissement d’uranium iranien de Natanz) en infectant les ordinateurs sur lesquels le logiciel de contrôle avait été développé et téléchargé sur les dispositifs eux-mêmes.
Quoi faire ?
Nous avons mis à jour notre propre installation de Xcode dès que nous avons reçu l’avertissement de sécurité.
Malheureusement, ce n’était pas aussi simple que suggéré dans l’avertissement envoyé, qui nous demandait de nous rendre à l’adresse suivante : https://developer.apple.com/xcode/downloads/, où nous n’avons trouvé que la version bêta 2 de Xcode 11.2 [2019 -11-02T16: 00Z] :
Ni ‘A propos de ce Mac’ ni l’App Store ne nous ont proposé de mises à jour de Xcode, le premier nous assurant que notre macOS était à jour et le deuxième n’affichant aucune mise à jour en attente pour nos applications installées [2019-11-02T16: 13Z] :
En fin de compte, en allant sur https://developer.apple.com/download/more/ et en recherchant le terme ‘Xcode’ nous avons réussi à atteindre notre objectif :
Si vous êtes un développeur Apple, nous vous suggérons de faire de même.
Billet inspiré de Apple developers – get this update to protect the rest of us!, sur Sophos nakedsecurity.