Connexion Premium

Une nouvelle attaque sur la supply chain vise les développeurs Rust via arrayref

De l'intérêt d'être INdépendant

Une nouvelle attaque sur la supply chain vise les développeurs Rust via arrayref

L’équipe Rust a signalé jeudi une attaque visant un crate très populaire, arrayref. Elle a permis, pendant un peu plus d’une heure, de distribuer des composants vérolés vraisemblablement destinés à la récupération de mots de passe sur les machines des utilisateurs finaux. L’incident, rapidement contenu, s’inscrit dans une longue liste d’attaques visant la chaîne d’approvisionnement.

L’équipe en charge de la maintenance du langage Rust et de ses composants a alerté jeudi 20 août d’une attaque visant arrayref, un crate (l’unité de compilation de base, qui se présente soit sous forme de binaires, soit comme une bibliothèque) très courant.

Pour ce faire, les auteurs ont réussi à publier sur crates.io, le registre de paquets Rust, un composant baptisé proc-macro1. Il contenait un build script (code qui s’exécute à la compilation) ayant pour objet de déclencher le téléchargement d’une charge malveillante de type infostealer (vol de données).

Une charge calculée pour extraire des données

Pour favoriser la diffusion de leur attaque (dont le nom est une forme de typosquatting d’un autre crate légitime, proc-macro2), les attaquants ont réussi à modifier le crate arrayref pour que leur charge soit appelée lors de l’utilisation de ce dernier. Ils ont également piégé de la même façon d’autres composants courants (internment, append-only-vec).

D’après l’équipe Rust, la fenêtre de diffusion s’est heureusement révélée limitée, suite à une alerte rapidement formulée par les chercheurs de Nextron Systems. Elle estime ainsi que les composants vérolés sont restés en ligne entre 90 et 107 minutes : un laps de temps trop court pour permettre une propagation à grande échelle, mais tout de même suffisamment long pour que des développeurs aient pu être touchés.

« Nous vous recommandons de vérifier vos dépendances locales pour vous assurer que ces crates n’ont pas été téléchargées », déclare ainsi l’équipe Rust, qui invite à vérifier le contenu du dossier ~/.cargo/registry/cache pour y débusquer les éventuelles versions vérolées.

Deux chercheurs de l’entreprise de cybersécurité Wiz (passée aux mains de Google en mars 2026) ont détaillé le contenu exact de la charge malveillante. Lancée donc dès la compilation, elle a vocation à reconstruire une URL de destination pour l’envoi de données volées, désactiver la validation d’un certificat TLS et ainsi autoriser le contrôle et commande à distance (C2).

Elle télécharge ensuite un composant spécifique à l’OS et à l’architecture de la machine et lance ce dernier, qui commence ensuite à extraire des informations, en s’intéressant notamment aux identifiants stockés au niveau du navigateur. Il s’installe par ailleurs de façon persistante, soit via le registre Windows, soit au moyen de LaunchAgent (macOS) ou systemd (Linux).

Le compte d’un mainteneur compromis

Les attaquants n’ont probablement pas choisi leur cible au hasard. Le crate arrayref compte en effet la bagatelle de 245 millions de téléchargements, et il est utilisé comme dépendance dans 400 autres crates populaires, utilisés notamment sur les chaînes de blocs Ethereum et Solana, associées à des cryptomonnaies bien connues.

La subtilité ici réside dans le fait que le crate arrayref ne comportait en tant que tel aucun code malveillant, notent les chercheurs de Step Security : c’est simplement son fichier de dépendances qui était modifié.

La version corrompue, arrayref@0.3.10, semble avoir été publiée depuis le compte d’un mainteneur Rust historique, et non des moindres puisqu’il s’agirait de l’auteur du crate initial, initialement publié il y a 15 ans. « Nous ne pensons pas que l’auteur d’arrayref agisse de manière malveillante, mais son ordinateur ou ses identifiants sont probablement compromis, et nous essayons de le contacter », indique l’équipe Rust.

Dans la foulée de la publication, les attaquants ont yanké (retiré) les versions 0.3.5 à 0.3.9 du crate arrayref pour que les développeurs soient enclins à lancer cargo update, la commande de mise à jour censée précisément les protéger lorsque leur environnement exploite une version obsolète (et donc potentiellement vulnérable) d’un composant.

L’attaque a donné lieu à la publication, vendredi, d’une CVE (2026 - 77651) qualifiée de critique avec un score de 9,8.

Pour Wiz, le mode opératoire et une adresse IP détectée par l’une des victimes de l’attaque rappellent directement de précédentes attaques sur la chaîne d’approvisionnement (supply chain) telles que celles menées ces derniers mois contre Trivy, Axios et npm.

Commentaires (18)

votre avatar
C'était attendu, tout comme avec npm, je trouve que Rust pousse fort l'utilisation de code géré par la communauté, avec les risques que cela comporte.
votre avatar
En même temps, c'est un des facteur décisif dans le choix d'un langue plutôt qu'un autre.
votre avatar
J'attends avec impatience le jour où quelqu'un aura ajouté du code malicieux dans Linpack. Tous les superordinateurs du Top 500 qui moulinent des bitcoins au lieu de prédire la météo ou la surface grillée par une bombe A, ça va déchirer.
votre avatar
Les supercalculateurs n'ont en général pas de connexion internet. Tout passe par un proxy filtrant.
votre avatar
Les supercalculateurs n'ont en général pas de connexion internet. Tout passe par un proxy filtrant.
Comme ceux qui ont récemment empếché les IA de sortir de leur prison ?
Sauf que Linpack n'est pas codé en Rust
Je répondais à un post qui dit "les librairies sont un facteur décisif dans le choix d'un langage". Rebondir sur FORTRAN me semblait judicieux.
emojis-ou-ce-que-les-smileys-que-vous-envoyez-par-messages-disent-de-votre-age
Ne pas arriver à détecter l'humour s'il n'est pas abondamment signalé par des émojis en dit long sur votre âge. Et j'ai écrit FORTRAN au lieu de Fortran, je suis vieux.
votre avatar
"Comme ceux qui ont récemment empếché les IA de sortir de leur prison ?"

Tu n'as pas lu l'article de Next qui remet en cause ces prisons mal verrouillées?

Et tout programme n'a pas forcément à voir avec de l'IA, non plus.
votre avatar
Et tout programme n'a pas forcément à voir avec de l'IA, non plus.
C'est vrai, l'intelligence artificielle n'est pas omniprésente. Les dégâts sont plus généralement imputables à l'idiotie naturelle.

Et ... je le prouve. Prompt:
Analyse ce post dans un forum dédié aux ordinateurs et dis moi ce que tu en comprends : "J'attends avec impatience le jour où quelqu'un aura ajouté du code malicieux dans Linpack. Tous les superordinateurs du Top 500 qui moulinent des bitcoins au lieu de prédire la météo ou la surface grillée par une bombe A, ça va déchirer."
Réponse de la version gratuite de Gemini :
Ce post de forum utilise l'ironie noire et la provocation pour critiquer les priorités de la recherche en supercalcul, en imaginant le détournement du benchmark Linpack pour miner des cryptomonnaies [1]. L'auteur suggère cyniquement que transformer la puissance de calcul des machines du Top 500 — normalement dédiées à la météo ou au nucléaire — en outil de "cryptojacking" géant constituerait un chaos technologique absurde. Pour en savoir plus sur les enjeux du classement des superordinateurs, consultez le site du Top 500.
votre avatar
Ok donc Gemini est plus compétent que moi pour détecter ton ironie. 😅
votre avatar
Ce n'est malheureusement pas ce que j'ai dit.

J'assume ce que je dis - puisque manifestement il faut expliquer : une IA sans aucun contexte attribue une forte probabilité au fait que le propos est ironique ; les personnes sur ce forum, confrontées au même texte, préfèrent supposer que je suis un parfait imbécile.

Or, comme tu le fais si bien remarquer, une IA n'a pas de "compétences".

Assume ce que tu en comprends.
votre avatar
Désolé, ce doit être les vacances.
Je ne comprends rien à ce que tu dis.

Tes phrases ampoulées, et/ou tes sous entendus sont trop compliqués pour moi.

Je reste sur ceci: les centres HPC qui font tourner Linpack
1/ n'ont absolument pas la même archi que les datas center des boîtes d'IA.
2/ n'ont pas les mêmes personnels
3/n'ont pas les mêmes objectifs (aka pour les boîtes d'IA, se faire mousser parce que leur nouveau super modèle en test à réussi à s'échapper de leur Sandbox)

Voilà pour je trouve ton commentaire original malvenu.
Maintenant que j'ai dit ça, j'arrête cette discussion et retourne dans mon lit.
Bonne journée
votre avatar
Voilà pour je trouve ton commentaire original malvenu.
Mais purée, cette histoire de Linpack, c'était juste un gag ! C'est vous qui prenez tout ça au premier degré !
votre avatar
C'est vous qui prenez tout ça au premier degré !
C'est pour ça que ça jette un froid. :pastaper:
votre avatar
Sauf que Linpack n'est pas codé en Rust (et puis Rust sur un supercalculateur, sans faire appel à du C ou du Fortran il faut en vouloir).

Rust est nettement plus vulnérable que le C(++)/Fortran à ceci genre d'attaque car tu n'as pas véritablement de librairies partagées. Quand tu modifies ton code, tu recompiles (presque) tout.
Quand tu déploies Rust sur un environnement, tu télécharges toutes les crates nécessaires et hop on recompile tout.

Dans le cas de ton Linpack en C++/Fortran, tu as déjà les libs d'installer sur le supercalculateur, et tu connais la version. Ce que tu fais, c'est que tu compiles ton code. Si tu utilises Linpack, le linker va s'occuper de lier tes appels à Linpack à les libs du supercalculateur (qui au passage, sont toujours ré-optimisées pour l'architecture de la machine).

La façon de faire tourner du bitcoin serait de véroler la version de Linpack installé sur un supercalculateur. Mais si penser que ça va pas trigger quelqu'un de voir du SHA dans un code d'inversion de matrice... En plus d'un code bien largement plus utilisées qu'une pauvre crate Rust embarqué dans d'autres crates... Bref, pas impossible mais significativement improbable.
votre avatar
Si, même sur un supercalculateur, tu peux faire une attaque supply chain sans problème, même sans Rust. Il suffit d'être volontaire pour reprendre des paquets orphelins et pourtant largement répandus (comme le coup de xz) dans Spack ou EasyBuild, et hop, il doit y avoir moyen d'y glisser une charge malveillante.
Mais l'intérêt est plus restreint puisque ces machines ont un accès réseau filtré, donc y amener une charge malveillante, ce serait pour ensuite y faire quoi ? Pas de minage, pas de réseau zombie, pas de pilotage à distance.
votre avatar
Un crate ??? Décidément je suis vraiment trop vieux.

Et tous ceux qui utilisent l’émoji 👍 (moi y compris) le sont :
https://www.liberation.fr/lifestyle/hightech/emojis-ou-ce-que-les-smileys-que-vous-envoyez-par-messages-disent-de-votre-age-20260821_35QEWMPYIFCUFMTSOZMYSWIQDI/
votre avatar
Haha désolé pour le jargon mais sur ce genre de sujet c'est compliqué de l'évincer ! :phiphi:
votre avatar
Lire libération est un indice fort sur ton age :iloveyou:
votre avatar
Plus généralement, lire la presse semble être un indice fort sur l’âge.
Les “djeun’s” (expression utilisée par les vieux également) seraient sur les rezos pour s’informer.

Le seul que j’utilise est Whatsapp, mais j’ai commencé avant son rachat par Facebook/Meta.
Par contre, maintenant je dois supporter la mention « from META » à chaque lancement de l’appli, et ça fait chier mal à chaque fois.