Le pourcentage de vulnérabilités Android causées par des problèmes de sécurité de la mémoire est passé de 76% en 2019 à seulement 24% en 2024, ce qui représente une diminution massive de plus de 68% en cinq ans.
C’est bien en deçà des 70% précédemment trouvés dans Chromium, ce qui fait d’Android un excellent exemple de la façon dont un grand projet peut progressivement et méthodiquement se déplacer vers un territoire sûr sans rompre la rétrocompatibilité.
Google affirme avoir obtenu ce résultat en donnant la priorité au nouveau code à écrire dans des langages sûrs pour la mémoire comme Rust, minimisant ainsi l’introduction de nouveaux défauts avec le temps.
Dans le même temps, l’ancien code a été maintenu avec des modifications minimes axées sur des correctifs de sécurité importants plutôt que sur des réécritures approfondies qui compromettraient également l’interopérabilité.
« Sur la base de ce que nous avons appris, il est devenu clair que nous n’avons pas besoin de jeter ou de réécrire tout notre code existant dangereux pour la mémoire », lit le rapport de Google.
« Au lieu de cela, Android se concentre sur la sécurisation et la commodité de l’interopérabilité en tant que fonctionnalité principale de notre parcours de sécurité de la mémoire. »
Cette stratégie rend le code plus ancien mature et devient plus sûr au fil du temps, réduisant le nombre de vulnérabilités liées à la mémoire, quel que soit le langage dans lequel il a été écrit.
Ces deux piliers de la stratégie de construction d’Android ont eu un effet synergique sur la diminution spectaculaire des défauts de mémoire dans la plate-forme mobile la plus utilisée au monde.
Google explique que, bien qu’il puisse sembler risqué de laisser l’ancien code essentiellement inchangé et bien que le nouveau code soit censé être mieux testé et revu, c’est le contraire qui se produit, malgré le fait que cela puisse sembler contre-intuitif.
En effet, les modifications récentes du code introduisent la plupart des failles, de sorte que le nouveau code contient presque toujours des problèmes de sécurité. Dans le même temps, les bogues dans les anciens codes sont corrigés à moins que les développeurs n’y apportent des modifications importantes.
Google affirme que l’industrie, y compris elle-même, est passée par quatre étapes principales pour traiter les failles de sécurité de la mémoire, résumées comme suit:
- Correction réactive: Au départ, l’accent était mis sur la correction des vulnérabilités après leur découverte. Cette approche a entraîné des coûts permanents, des mises à jour fréquentes étant nécessaires et les utilisateurs restant vulnérables entre-temps.
- Atténuations proactives: L’étape suivante consistait à mettre en œuvre des stratégies pour rendre les exploits plus difficiles (par exemple, les canaris de pile, l’intégrité du flux de contrôle). Cependant, ces mesures s’accompagnaient souvent de compromis sur les performances et conduisaient à un jeu du chat et de la souris avec les attaquants.
- Découverte proactive des vulnérabilités: Cette génération impliquait l’utilisation d’outils tels que le fuzzing et les désinfectants pour détecter les vulnérabilités de manière proactive. Bien qu’utile, cette méthode ne traitait que des symptômes, nécessitant une attention et des efforts constants.
- Prévention à haute assurance( codage sécurisé): La dernière approche met l’accent sur la prévention des vulnérabilités à la source en utilisant des langages sûrs pour la mémoire comme Rust. Cette méthode » sécurisée dès la conception » offre une assurance évolutive et à long terme, brisant le cycle des correctifs réactifs et des atténuations coûteuses.
« Les produits de l’ensemble du secteur ont été considérablement renforcés par ces approches, et nous restons déterminés à réagir, à atténuer et à rechercher de manière proactive les vulnérabilités », a expliqué Google.
« Cela dit, il est devenu de plus en plus clair que ces approches sont non seulement insuffisantes pour atteindre un niveau de risque acceptable dans le domaine de la sécurité de la mémoire, mais entraînent des coûts continus et croissants pour les développeurs, les utilisateurs, les entreprises et les produits.
« Comme l’ont souligné de nombreuses agences gouvernementales, y compris CISA, dans leur rapport secure by design, » ce n’est qu’en intégrant des pratiques sécurisées dès la conception que nous briserons le cercle vicieux de la création et de l’application constantes de correctifs. »
En juin dernier, la Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis a averti que 52% des projets open source les plus utilisés utilisaient des langages non sécurisés pour la mémoire.
Même les projets écrits dans des langages sécurisés en mémoire dépendent souvent de composants écrits dans des langages non sécurisés en mémoire, de sorte que le risque de sécurité est compliqué à gérer.
CISA a recommandé aux développeurs de logiciels d’écrire du nouveau code dans des langages sûrs pour la mémoire tels que Rust, Java et GO et de transférer les projets existants, en particulier les composants critiques, vers ces langages.