Faille de sécurité de 11 ans trouvée dans le vérificateur de durée de vie Rust
Sommaire
En bref
- Un chercheur a découvert une faille de sécurité majeure dans le vérificateur de durée de vie de Rust qui permet de contourner les garanties d'emprunt en passant une référence courte à une structure qui l'attend statique.
- Le bug existe depuis la version 1.18.0 (2017) et affecte toutes les versions stables actuelles jusqu'à 1.85.0.
- L'exploitation requiert une implémentation Drop intentionnellement malveillante, ce qui limite l'impact pratique immédiat.
- Le Types Team de Rust a classé ce bug en P-critical malgré son ancienneté, car il viole le contrat fondamental de sécurité mémoire du langage.
- Le vérificateur doit simplement rejeter ce code ; le problème n'est pas dans les règles de durée de vie mais dans leur application par le compilateur.
Ce que dit la source
Un bug d'unsoundness (violation de sécurité mémoire) a été découvert dans le vérificateur de durée de vie du compilateur Rust. Le problème permet de contourner les garanties d'emprunt en stockant une référence de courte durée dans une structure qui exige une durée de vie 'static, puis de la récupérer après son invalidation via une implémentation Drop malveillante. L'auteur démontre que le compilateur accepte du code qui violerait les règles de durée de vie énoncées, provoquant un accès mémoire dangereux (stack-use-after-scope). Cette faille existe sans interruption depuis Rust 1.18.0 en 2017.
- Le bug permet à une référence courte de contourner les contraintes de durée de vie 'static via l'assignation covariante d'un champ dans une structure avec un Drop malveillant
- L'exploitation nécessite une implémentation Drop intentionnellement malveillante pour extraire et conserver une référence expirée, limitant l'impact sur le code réel
- Le code problématique compile avec des AddressSanitizer et provoque un crash avec asan ou un comportement indéfini sans outils de détection
- Le bug est présent depuis 1.18.0 (2017) et reproduit sur toutes les versions stables jusqu'à 1.85.0
- Le compilateur devrait rejeter ce code selon les règles de durée de vie existantes ; la faille est dans l'implémentation, pas dans la conception du système de types
- Les mainteneurs de Rust ont classé l'issue en P-critical car elle viole le contrat de sécurité mémoire, malgré sa rareté pratique et ses 11 années sans découverte
Dans les commentaires
Débat partagé entre consternation technique et contexte pragmatique. Plusieurs commentateurs reconnaissent la gravité théorique mais questionnent l'impact réel sur les crates existantes ; quelques-uns minimisent le risque en soulignant que la faille nécessite du code Drop malveillant, tandis que d'autres expriment de la surprise qu'elle soit restée cachée si longtemps.
- Plusieurs commentateurs demandent si du code réel en dépend : Eridrus pose explicitement la question d'un compilateur fix causant une régression, suggérant que l'impact pratique peut être nul malgré la violation théorique
- Un argument récurrent : le bug requiert une implémentation Drop intentionnellement malveillante pour être exploité, pas un accident de programmation, ce qui réduit le risque en production
- Quelques commentateurs rapportent que plus de 100 issues unsoundness existaient déjà, normalisant légèrement cette découverte dans un paysage de complexité croissante du système de types
- Un commentateur soulève le rôle du testing limité autour de la variance : elle n'est rarement écrite manuellement, ce qui explique pourquoi ce bug a dormi 11 ans sans être détecté
- Un question sur Ferrocene (le compilateur Rust certifié pour les usages critiques) et si elle partage le même bug, mettant en relief l'enjeu pour la sécurité critique
Notre lecture
Un bug réel, grave théoriquement, mais contextualisé. Rust n'a pas échoué ; le système de types a échoué à appliquer ses propres règles, un défaut du compilateur plutôt que de la conception. Le fix est clair (rejeter le code), et l'impact probable sur les crates existantes semble marginal puisque la faille a dormi 11 ans sans incident signalé. Pour les équipes utilisant Rust en production, aucune action immédiate n'est justifiée, mais cette découverte renforce l'intérêt d'un test formalisé et d'une vérification des outils de sécurité critique comme Ferrocene. À surveiller surtout pour les projets critiques.