Les développeurs en langage Rust ont été alertés d’une faille sérieuse dans la bibliothèque TAR et ses forks. Elle entraîne l’exécution de code à distance.
Des chercheurs de la société Edera ont découvert une vulnérabilité importante dans le langage Rust et plus exactement la bibliothèque async-tar Rust et ses dérivés dont le très utilisé tokio-tar. Baptisée TARmageddon (CVE-2025-62518), elle affiche un score de gravité de 8,1 et « peut conduire à l’exécution de code à distance via des attaques par écrasement de fichiers, telles que le remplacement de fichiers de configuration ou le détournement de backends de compilation », ont alerté les experts dans un rapport. La propagation de l’infection via des applications, également connue sous le nom d’attaque de type supply chain, fait partie des autres impacts possibles.
Selon les chercheurs, la première mesure recommandée consiste à corriger tous les forks actifs, car cette vulnérabilité affecte des projets majeurs et largement utilisés, notamment les projets uv (le gestionnaire de paquets Python d’Astral), testcontainers et wasmCloud. « En raison de la très large utilisation de tokio-tar sous diverses formes, il n’est pas possible de quantifier à l’avance l’ampleur réelle de ce bug dans l’écosystème », ont-ils affirmé. Pour aggraver les choses, les chercheurs avertissent que le fichier tokio-tar, très téléchargé, n’a toujours pas été corrigé, probablement parce qu’il n’est plus maintenu activement. Edera suggère aux développeurs qui s’en servent d’envisager de migrer vers une version activement maintenue, comme astral-tokio-tar version 0.5.6 ou ultérieure, qui a été corrigée. Les responsables IT doivent également analyser leurs applications pour voir si certaines ont été développées en Rust et si elles présentent un risque.
Pourquoi il faut s’en inquiéter
« Les fichiers TAR sont utilisés dans les systèmes Unix et Linux pour regrouper plusieurs répertoires et fichiers dans une archive qui conserve la structure complète du répertoire et les métadonnées des informations d’origine », a expliqué Robert Beggs, directeur de l’entreprise canadienne de réponse aux incidents DigitalDefence. Les archives servent couramment dans les sauvegardes ou pour compresser des logiciels, en particulier pour la distribution de code source. « La manière dont certaines versions des bibliothèques TAR ont été écrites expose à une vulnérabilité potentielle », a-t-il déclaré par courriel, en précisant que « dans le pire des cas, cela permettrait à un pirate d’exécuter un code arbitraire sur un système hôte et de se livrer à des actions malveillantes, par exemple, l’écrasement de fichiers critiques (fichiers de configuration, scripts de compilation) ou l’obtention d’un accès non autorisé au système de fichiers. » L’exploitation pourrait également compromettre tout système qui extrait des fichiers du TAR malveillant. « Cette faille est particulièrement grave car les bibliothèques TAR vulnérables sont souvent présentes dans des applications qui ne font pas l’objet d’une maintenance active et peuvent être oubliées lors de l’application de correctifs ou d’autres mesures visant à atténuer le problème », a-t-il ajouté. Même s’il n’y a pour l’instant aucune exploitation connue de cette vulnérabilité, M. Beggs pense que cela pouvait changer rapidement. « Cette vulnérabilité étant de gravité élevée – 8,1 sur une échelle de 1 à 10 – elle est susceptible d’attirer l’attention des pirates. »
Recommandations
Le spécialiste formule plusieurs recommandation aux responsables en cybersécurité. En premier lieu, il est nécessaire d’auditer le code afin d’identifier les dépendances pour les forks ou les wrappers de tokio-tar et de s’assurer qu’ils sont également corrigés. Par ailleurs, il convient d’examiner l’utilisation des fichiers TAR dans les environnements d’intégration continue/déploiement continu CI/CD ainsi que dans les conteneurs, et de s’assurer qu’ils sont corrigés. De même, il est judicieux d’isoler (sandbox) les archives lors du traitement et d’éviter d’extraire des fichiers TAR provenant de sources non fiables. Une surveillance continue des éventuels exploits ou d’autres vulnérabilités associés à la bibliothèque est conseillée.
Les administrateurs pourraient également être intéressés par cet avis expliquant le problème publié par Astral Security, qui gère astral-tokio-tar. Le bogue a été découvert en juillet et divulgué le même mois aux responsables de toutes les bibliothèques, à la Rust Foundation et à un certain nombre de projets. Il a été convenu que les détails ne seraient pas divulgués avant cette semaine. Étant donné que le fork le plus populaire, tokio-tar, qui cumule plus de 5 millions de téléchargements sur crates.io, ne semble plus faire l’objet d’une maintenance active, Edera a coordonné une divulgation décentralisée à travers la lignée complexe des forks.
Conséquences possibles
Selon Edera, cette vulnérabilité est un défaut de désynchronisation qui permet à un cybercriminel « d’introduire clandestinement » des entrées d’archive supplémentaires dans les extractions TAR. Elle se produit lors du traitement de fichiers TAR imbriqués qui présentent une incompatibilité spécifique entre leurs en-têtes étendus PAX et leurs en-têtes ustar. La faille provient de la logique incohérente du parseur lors de la détermination des limites des données des fichiers.
Parmi les scénarios d’infection possibles décrits par Edera, on peut citer :
– une attaque contre les gestionnaires de paquets Python utilisant tokio-tar. Un pirate télécharge un paquet malveillant sur le référentiel open source PyPI, à partir duquel les développeurs téléchargent des utilitaires. Le conteneur TAR externe du paquet contient un fichier légitime, mais le TAR interne caché contient un fichier malveillant qui détourne le backend de compilation. Ce TAR interne caché introduit des fichiers inattendus ou écrasés, ce qui compromet l’environnement de test et pollue la chaîne d’approvisionnement ;
– une attaque contre tout système comportant des phases distinctes de « scan/approbation ». Un scanner de sécurité analyse le TAR externe, qui est propre, et approuve son ensemble de fichiers limité. Cependant, le processus d’extraction utilisant la bibliothèque vulnérable extrait des fichiers supplémentaires, non approuvés et non analysés du fichier TAR interne, ce qui entraîne un contournement des contrôles de sécurité et une violation de la politique.
Les développeurs Rust affirment que ce langage crée des applications en mémoire sécurisées, mais selon les chercheurs d’Edera, « la découverte de TARmageddon nous rappelle de manière importante que Rust n’est pas une solution miracle ». Le rapport souligne que « le langage ne supprime pas les erreurs logiques, et cette incohérence d’analyse est fondamentalement un défaut logique. Les développeurs doivent rester vigilants face à toutes les catégories de vulnérabilités, quel que soit le langage utilisé. » Le rapport rappelle également les dangers liés à l’utilisation de bibliothèques open source non maintenues dans le code.
Les responsables Kali Linux ont perdu la clé de signature de la distribution. Ils ont ainsi bloqué les mises à jour attendues par les administrateurs. Cette affaire repose la question de la gestion des clés aux RSSI.
« C’est entièrement notre faute » explique les responsables de Kali dans un blog. Le problème est la perte d’une clé de signature de la distribution Linux dans un incident qui s’est déroulé à la mi-avril. Kali a dû geler le dépôt. C’est la raison pour laquelle personne n’a encore été affecté. Cependant, cette semaine, le référentiel sera disponible, et ceux qui n’ont pas récupéré la nouvelle clé de signature ne pourront pas faire de mises à jour automatiques.
Les administrateurs doivent télécharger et installer la nouvelle clé manuellement, puis vérifier que la somme de contrôle du fichier correspond à celle créée par Kali. Si certains administrateurs préfèrent reconstruire leur système Kali à partir de zéro, Kali a mis à jour toutes ses images avec la récente clé. L’éditeur a précisé que l’ancienne clé n’avait pas été compromise. À noter que le fournisseur n’a pas répondu à une demande de commentaire envoyée avant la mise en ligne de cet article. Comme l’a rappelé Robert Beggs, responsable du fournisseur canadien de tests de pénétration et de réponse aux incidents DigitalDefence, ce n’est pas la première fois que Kali a un problème de clé de signature. En 2018, le fournisseur avait laissé passer la date d’expiration d’une clé. « C’est un petit problème facile à surmonter », a déclaré M. Beggs dans une interview, qui se résout en tapant une simple ligne de code, comme l’indique le blog de Kali.
Une absence de gestion centralisée pointée du doigt
La perte des clés de signature est « très rare » chez les éditeurs d’applications parce que cette responsabilité se situe typiquement au niveau de l’entreprise », a fait remarquer M. Beggs. « Le fait que cela se soit produit deux fois chez Kali suggère qu’il n’y a tout simplement pas de gestion centralisée. La perte de la clé ne disqualifie pas le produit, ni l’excellent travail réalisé. Elle indique simplement un défaut de gestion centralisée », a-t-il ajouté. « Les seules personnes qui seront gênées sont les administrateurs qui ne comprendront pas le message d’erreur qu’ils recevront en essayant de mettre à jour la distribution, et qui ne savent pas que la clé n’est plus à jour ». Ce dernier pense néanmoins que la plupart des administrateurs Kali sont déjà au courant du problème et savent comment le résoudre. « La leçon à tirer pour les RSSI dont les entreprises ont des clefs ou des licences logicielles à renouveler, est de considérer cette tâche au même titre que la maintenance des objets », a conseillé M. Beggs.
Celui-ci recommande également de se préoccuper de la continuité. Selon lui, le problème le plus courant n’est pas celui d’une personne qui oublie de renouveler sa licence, mais d’une personne connaissant la clé ou la licence qui est partie ou a changé de poste. « Souvent, les entreprises ne parviennent pas à assurer la continuité. Il faut arrêter de penser que cette responsabilité incombe à une seule personne. C’est une responsabilité d’entreprise », a-t-il insisté. « Il faut s’assurer de la continuité de la gestion des objets, de sorte que si une personne change de poste, a un accident ou qu’elle oublie, des contrôles d’entreprise peuvent garantir une continuité dans le processus de gestion ».
Pour éviter les accès illégitimes aux entrepôts de données managés de Redshift, AWS a décidé de désactiver par défaut les accès publics et de renforcer le chiffrement des connexions et des données.
Si les experts en cybersécurité pointent régulièrement les problèmes de configuration des buckets S3 d’AWS, les entrepôts de données de Redshift constituent un point de vigilance. Dans ce cadre, le fournisseur de cloud a renforcé la protection de ce service cloud en désactivant l’accès public. Pour Loris Degioanni, directeur de la technologie chez Sysdig, cette évolution est la bienvenue et « nécessaire pour accompagner l’adoption accélérée du cloud dans les…
Il vous reste 94% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
La stratégie des groupes de ransomware évolue. Après avoir volé des clés de connexion, un pirate a eu accès à des buckets S3 (stockage objet) d’AWS. Il s’est servi du chiffrement de l’espace de stockage pour bloquer les données et demander une rançon.
La vigilance est de mise pour les RSSI face à une nouvelle méthode d’attaques par ransomware. Ils doivent redoubler la surveillance sur les clés d’accès aux ressources AWS et en particulier les espaces de stockage objet S3. Le problème a été observé par l’éditeur en sécurité Halcyon avec une attaque menée par un pirate nommé Codefinger. Il a réussi à obtenir les clés d’accès aux comptes AWS et a ensuite utilisé le propre chiffrement du…
Il vous reste 93% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Citrix a réparé des vulnérabilités dans la solution virtual apps et desktops permettant aux pirates authentifiés d’utiliser http pour s’y introduire. Les correctifs sont à appliquer sans attendre.
Les RSSI disposant du service de virtualisation du poste de travail de Citrix dans leur environnement sont invités à corriger deux failles qu’un pirate authentifié pourrait exploiter pour élever ses privilèges et exécuter du code à distance. Les chercheurs de watchTowr, à l’origine de la découverte, mettent en garde contre l’exploitation possible d’une « instance MSMQ (Microsoft Message Queuing) exposée sans précaution » via http, pouvant déboucher sur l’exécution de code à distance non authentifié contre l’application. « Il semble y avoir un désaccord entre Citrix et watchTowr sur la gravité de la vulnérabilité », a commenté Michelle Abraham, directrice de recherche au sein du groupe de sécurité et de confiance d’IDC. « Mais l’exécution de code à distance est à prendre au sérieux. »
Correctifs disponibles
Dans un bulletin de sécurité publié mardi, Citrix « recommande vivement aux clients concernés de Citrix Session Recording d’installer les mises à jour correspondantes dès que le permet leur calendrier de mise à niveau. » Deux failles sont concernées : la première, référencée CVE-2024-8068, dont le score CVSS est de 5.1, peut entrainer une escalade de privilèges vers l’accès au compte NetworkService ; la seconde, référencée CVE-2024-8069, avec le même score CVSS de 5.1, peut déboucher sur une exécution de code à distance limitée avec privilège d’accès au compte NetworkService. Des correctifs sont disponibles pour la version actuelle et les versions LTS. « Les RSSI devraient vérifier s’ils utilisent cette application dans leurs environnements IT et déterminer si la faille présente un risque », a conseillé Mme Abraham, en particulier si elle est utilisée sur des actifs critiques pour l’entreprise.
La criticité doit être prise en compte dans la priorisation de la remédiation. « Chaque environnement IT étant différent, les risques et les priorités sont aussi différents. Il est nécessaire de disposer d’une solution de gestion des vulnérabilités capable d’établir des priorités et de suivre le processus de remédiation pour gérer les CVE susceptibles d’être présentes dans l’environnement IT de l’entreprise, » a-t-elle ajouté. « 29 004 enregistrements de CVE ont été publiés au cours des trois premiers trimestres de l’année 2024, soit plus que pour l’ensemble de l’année 2023. » Les vulnérabilités se situent dans la fonction d’enregistrement de session Session Recording de Citrix Virtual Apps and Desktops, qui propose aux services IT de fournir un bureau de travail sécurisé sur n’importe quel terminal utilisé par un employé ou un partenaire approuvé. L’enregistrement de session crée une vidéo des mouvements du clavier et de la souris que les administrateurs ou l’assistance IT peuvent utiliser à des fins de surveillance, de conformité et de dépannage. Les vidéos sont stockées dans un dossier de la base de données du serveur Citrix. L’application comprend le gestionnaire de stockage de l’enregistrement de session Session Recording Storage Manager, qui est un service Windows.
Une autre faille découverte
Mais ce n’est pas tout : les chercheurs de watchTowr ont aussi découvert une faille, décrite dans un blog. Le gestionnaire de stockage Session Recording Storage Manager reçoit des fichiers via Microsoft Message Queuing (MSMQ) et utilise un processus de sérialisation pour convertir les messages de données d’enregistrement de session en une forme qui peut être interprétée par les processus Windows. L’API de sérialisation autorise plusieurs permissions « critiques », a commenté watchTowr, y compris l’accès au contrôle total à presque tous les utilisateurs authentifiés. De plus, selon les chercheurs, Citrix utilise le BinaryFormatter de .NET pour la désérialisation. « Nous savons depuis longtemps que l’utilisation d’un BinaryFormatter pour la désérialisation est presque toujours dangereuse », indique le rapport. « Il expose de nombreuses fonctionnalités à quiconque peut lui fournir des messages et, même s’il peut être utilisé en toute sécurité, son usage est tellement pénalisant que Microsoft elle-même dit qu’il ne devrait pas être utilisé. » Le rapport cite un document de Microsoft publié en juillet détaillant les risques liés à l’utilisation de BinaryFormatter, dans lequel il est écrit qu’il n’est pas recommandé pour le traitement des données.
Alors que MSMQ est généralement accessible via le port TCP 1801, qui n’est pas ouvert par défaut dans un environnement Citrix, un bogue dans MSMQ, référencé CVE-2024-21554, permet d’accéder à MSMQ via HTTP. Malheureusement, pour une raison quelconque, le support HTTP est activé lorsque Virtual Apps and Desktop est installé. Les administrateurs qui savent résoudre ce problème peuvent décocher cette option dans la liste du menu Message Queuing de l’application. Sur la base de toutes ces données, les chercheurs de watchTowr ont construit une preuve de concept d’exploit qui, selon eux, pourrait être utilisée par un acteur de la menace. « Il ne s’agit pas vraiment d’un bogue dans le BinaryFormatter lui-même, ni d’un bogue dans MSMQ », a fait savoir watchTowr « mais plutôt d’une conséquence malheureuse liée au fait que Citrix s’est appuyé sur le BinaryFormatter documenté comme étant non sécurisé pour maintenir une frontière de sécurité. Ce bogue s’est manifesté pendant la phase de conception, quand Citrix a choisi la bibliothèque de sérialisation à utiliser. »