Yet Another Massive Rust Security Failure, Surprising No One
Cette vidéo du Lunduke Journal critique la sécurité de l’écosystème Rust en pointant la fréquence des crates malveillantes publiées sur crates.io, et remet en question le discours des évangélistes qui vantent Rust comme langage « sûr » alors que les attaques de supply chain y ...
SYNTHÈSE STRUCTURÉE
Le contexte : des attaques répétées sur les crates Rust
L’intervenant commence par poser une question provocatrice : « Is Rust the least secure programming language right now in modern usage? » Il justifie cette interrogation par une accumulation d’incidents récents. Il cite notamment la crate arrayref (244 millions de téléchargements) qui a été compromise en août, et la crate proc-macro-one qui contenait du code malveillant. Il rappelle aussi l’incident de la crate one-ring de juin, qui exfiltrait le code source des projets vers un serveur distant. Ce n’est pas un cas isolé : « it’s rare that a month or two goes by without more malicious code being discovered in the Rust ecosystem ».
La mécanique de l’attaque : dépendances et macros procédurales
L’attaque récente repose sur une technique classique de supply chain : la crate arrayref a été publiée dans une version récente qui déclarait une dépendance vers proc-macro-one, une crate contenant le code malveillant. Le terme « proc macro » est important : il s’agit de macros procédurales, un mécanisme de méta-programmation très utilisé en Rust. Ces macros sont exécutées au moment de la compilation, ce qui en fait un vecteur d’attaque particulièrement efficace : « every Rust programmer who compiled any project which referenced one of the compromised crates » était potentiellement infecté. L’intervenant souligne que la Rust Foundation a réagi rapidement en « yankant » la version compromise, mais que le mal était déjà fait.
La réaction de la Rust Foundation : réactive mais dépassée
L’intervenant reconnaît que l’équipe de sécurité de Rust est « fairly on top of it when they find this stuff », mais il insiste sur le fait que le volume d’incidents est tel que la réactivité ne suffit plus. Il cite le rapport du 20 août de la Rust Foundation qui indique que la version compromise a été retirée, mais il note que « there’s so much coming out and it just it’s a constant onslaught of it ». Autrement dit, la réponse est correcte sur le plan procédural, mais elle ne traite pas la cause racine : la facilité avec laquelle des crates malveillantes peuvent être publiées et adoptées massivement.
La contradiction des évangélistes Rust
Le cœur de l’argumentation de l’intervenant est une accusation d’hypocrisie : « the whole selling factor of Rust has been that it’s fixing memory safety to make our code secure ». Or, selon lui, les défenseurs de Rust ignorent les failles de sécurité de l’écosystème (supply chain) tout en continuant à vanter la sécurité mémoire du langage. Il ajoute que les réécritures de code C/C++ en Rust sont souvent faites « because of mythical unknown bugs », sans qu’un bug concret soit identifié au préalable. Il conclut : « at that point they I mean they know they know they’re just full of BS and hot air, right? »
La fréquence des incidents : un signal d’alarme
L’intervenant insiste sur le fait que ces attaques ne sont plus des exceptions mais une tendance lourde : « it’s happening so regularly that it’s almost becoming blasé. It’s becoming boring ». Il mentionne que d’autres incidents ont eu lieu (comme la crate one-ring en juin) et que d’autres suivront : « I think it’s fair to assume that there’s more Rust security vulnerabilities coming just based on the past track record ». Il prévient qu’il ne pourra pas tous les couvrir, ce qui renforce son constat d’un écosystème sous pression constante.
Une conclusion pessimiste sur l’état de la sécurité Rust
L’intervenant termine sur une note très négative : « we just have to assume that if you’re programming with Rust, you have an insecure system at this point ». Cette phrase résume sa position : la sécurité mémoire du langage ne compense pas les failles de l’écosystème de paquets. Il anticipe les critiques des « Rust advocates » et les accuse de ne pas vouloir voir la réalité : « they’re going to ignore everything that I said in this one ».
CONCEPTS CLÉS
- Supply chain attack : attaque qui vise non pas le code de l’application elle-même, mais les dépendances tierces utilisées pour la construire. Ici, les crates Rust sont le vecteur d’attaque.
- Crate : paquet de code Rust distribué via crates.io, l’équivalent de PyPI pour Python ou npm pour JavaScript.
- Proc macro : macro procédurale, un mécanisme de méta-programmation en Rust qui permet de générer du code à la compilation. Elle est exécutée sur la machine du développeur, ce qui en fait une cible privilégiée pour l’exfiltration de données.
- Yank : action de retirer une version d’une crate de crates.io pour empêcher de nouvelles installations, sans supprimer les versions déjà téléchargées.
- Exfiltration : action de copier des données sensibles (code source, identifiants, etc.) vers un serveur contrôlé par l’attaquant.
CONCLUSION
Le message principal de cette vidéo est que la sécurité d’un langage ne se limite pas à ses garanties mémoire : l’écosystème de paquets qui l’entoure est un vecteur d’attaque tout aussi critique. L’intervenant accuse les défenseurs de Rust de faire preuve d’aveuglement en continuant à vanter la sécurité du langage alors que les attaques de supply chain se multiplient. Pour un administrateur système, la leçon est double : d’une part, il faut auditer rigoureusement les dépendances de tout projet Rust (comme on le ferait pour n’importe quel langage), et d’autre part, il ne faut pas considérer un langage comme « sûr » par nature, mais plutôt évaluer la sécurité de l’ensemble de la chaîne de construction et de distribution. La réactivité de la Rust Foundation est louable, mais elle ne remplace pas une stratégie de prévention et de vérification systématique des crates utilisées.