Éliminer les vulnérabilités de sûreté mémoire à la source

Éliminer à la source les vulnérabilités de sûreté mémoire

Un résultat paradoxal

• Quand une base de code écrite dans des langages non sûrs en mémoire continue de croître, le fait de basculer les nouvelles fonctionnalités vers des langages sûrs en mémoire réduit fortement les vulnérabilités de sûreté mémoire
• Cela s’explique par le fait que les vulnérabilités diminuent de manière exponentielle avec le temps

Explication mathématique

• La durée de vie des vulnérabilités suit une distribution exponentielle
• Les vulnérabilités apparaissent principalement dans le nouveau code, puis le code devient plus sûr avec le temps
• La densité de vulnérabilités dans un code âgé de 5 ans est de 3,4 à 7,4 fois plus faible que dans un nouveau code

Cas concret sur Android

• Depuis 2019, l’équipe Android a commencé à faire évoluer les nouveaux développements vers des langages sûrs en mémoire
• En 2024, la part des vulnérabilités de sûreté mémoire est passée de 76 % à 24 %
• À mesure que les vulnérabilités de sûreté mémoire diminuent, le risque de sécurité global baisse également

Évolution de la stratégie de sûreté mémoire

• 1re génération : correctifs réactifs — découvrir les vulnérabilités et les corriger
• 2e génération : atténuation proactive — rendre l’exploitation des vulnérabilités plus difficile
• 3e génération : détection proactive des vulnérabilités — les identifier à l’avance
• 4e génération : prévention à haute confiance — prévenir l’apparition même des vulnérabilités en migrant vers des langages sûrs en mémoire

Les avantages de la prévention à haute confiance

• Met fin à la compétition sans fin entre défenseurs et attaquants
• Renforce la sécurité tout en réduisant les coûts grâce aux langages sûrs en mémoire
• Améliore la justesse du code et la productivité des développeurs

Des enseignements à la pratique

• Il n’est pas nécessaire d’abandonner ou de réécrire tout le code existant non sûr en mémoire
• L’amélioration de l’interopérabilité accélère la transition vers des langages sûrs en mémoire
• Développement d’outils pour améliorer l’interopérabilité entre Rust et C++, ainsi qu’entre Rust et Kotlin

Le rôle des générations précédentes

• Utilisation sélective de l’atténuation proactive et de la détection
• À mesure que la transition vers du code sûr en mémoire progresse, le besoin d’atténuation et de détection diminue

Conclusion

• L’utilisation de langages sûrs en mémoire pour le nouveau code entraîne une baisse exponentielle des vulnérabilités
• Plus de 6 ans de résultats cohérents sur Android prouvent l’efficacité de cette approche

Le résumé de GN⁺

• Il est important de migrer vers des langages sûrs en mémoire pour réduire les vulnérabilités de sûreté mémoire
• Le cas de l’équipe Android montre une forte diminution des vulnérabilités de sûreté mémoire
• Améliorer l’interopérabilité est plus pragmatique qu’une réécriture complète du code existant
• Utiliser des langages sûrs en mémoire comme Rust peut améliorer à la fois la sécurité et la productivité

[GN⁺]

Commentaires sur Hacker News

• Faire passer les nouveaux développements vers des langages sûrs en mémoire peut apporter une amélioration significative
  • C'est bien plus simple et moins coûteux que de tout porter
• Le graphique dans l'article est clair et concis
  • Une sélection et un étiquetage soigneux des données permettent de transmettre facilement l'idée voulue
• Les vulnérabilités diminuent de façon exponentielle
  • Il est important de se concentrer sur le nouveau code
  • Les projets RiiR menés sans discernement sont un gaspillage de ressources
  • La stratégie recommandée par les experts Rust est la plus efficace pour minimiser les vulnérabilités mémoire
• L'équipe Android a observé que le taux de rollback des changements en Rust est inférieur à la moitié de celui du C++
• Il existe une corrélation entre le nouveau code et les vulnérabilités mémoire
  • Le code lié aux nouvelles fonctionnalités concentre davantage de vulnérabilités
  • Les cas limites du vieux code sont découverts à travers l'usage réel
• Il est difficile d'affirmer que le nouveau code provoque les vulnérabilités mémoire
  • Il existe des vulnérabilités à fort impact comme le bug Heartbleed
• Les vulnérabilités diminuent de façon exponentielle
  • Arrêter d'ajouter de nouvelles fonctionnalités pourrait être meilleur pour la sécurité
  • Windows LTSC est peut-être la version la plus sûre
• Le code sûr améliore l'exactitude du code et la productivité des développeurs
  • La découverte des bugs est déplacée avant le check-in du code
  • L'équipe Android a observé que le taux de rollback des changements en Rust est inférieur à la moitié de celui du C++
• Après avoir découvert Rust, certains ont retrouvé leur passion pour la programmation
• Seul Rust est mentionné comme langage à sécurité mémoire (MSL)
  • Kotlin a aussi été mentionné, mais ses garanties de sécurité mémoire ne sont pas aussi fortes que celles de Rust
• La durée de vie des vulnérabilités suit une distribution exponentielle
  • Garantir la sécurité mémoire dans le nouveau code a énormément de valeur
  • C'est utile même dans de vastes bases de code legacy
• L'ancien code n'est pas forcément suffisamment relu
  • Les journaux de commits récents sont relus plus souvent
• Différence entre Mac et Windows dans les langages utilisés pour écrire le code
  • Mac utilise Swift, sûr en mémoire, tandis que Windows utilise principalement C ou C++
• Plus les vulnérabilités deviennent rares, plus elles gagnent en valeur
  • Les vulnérabilités restantes sont susceptibles d'être utilisées par des acteurs étatiques contre des cibles à forte valeur
  • Des fonctionnalités comme le Lockdown Mode d'iOS pourraient être nécessaires
  • Les utilisateurs sensibles à la sécurité peuvent cocher une case de sécurité en échange d'une baisse de performances
  • Détecter l'attaque et l'envoyer à l'équipe sécurité pour analyse
  • Envoyer une alerte à l'utilisateur pour lui signaler qu'une attaque a été détectée
  • Au lieu de surveiller passivement l'activité de l'utilisateur, l'informer lorsqu'une attaque est détectée