Cette page décrit les bugs et les outils liés à la sécurité de la mémoire.
Insécurité de la mémoire
Les bugs de sécurité au niveau de la mémoire, qui sont des erreurs de gestion de la mémoire dans les langages de programmation natifs, sont le problème le plus courant dans les bases de code Android. Ils représentent plus de 60% des failles de sécurité de gravité élevéeet des millions de plantages visibles par les utilisateurs.
Figure 1. Bugs de sécurité au niveau de la mémoire et leur impact négatif sur la qualité, la sécurité et les coûts
Les bugs de sécurité au niveau de la mémoire ont un impact négatif sur la qualité et la stabilité, et représentent une
part importante des plantages observés sur les appareils des utilisateurs finaux. Par conséquent, une forte
densité de bugs de sécurité au niveau de la mémoire est directement corrélée à une mauvaise expérience utilisateur.
Le code natif, écrit dans des langages non sécurisés au niveau de la mémoire tels que C, C++ et Assembly
représente plus de 70% du code de la plate-forme Android et est présent dans environ
50% des applications du Google Play Store.
Compte tenu de la complexité croissante du code, si rien n'est fait, les bugs de sécurité au niveau de la mémoire
vont augmenter au fil du temps. Par conséquent, il est essentiel pour notre succès à long terme de fournir à notre écosystème
les outils et les technologies permettant de détecter et d'atténuer ces bugs.
Au cours des dernières années, nous avons collaboré étroitement avec nos partenaires matériels
pour développer des technologies matérielles telles que le balisage de la mémoire Arm et avons
introduit Rust dans la base de code Android.
Ces technologies vont accélérer notre transition vers la sécurité de la mémoire et
aider l'ensemble du secteur des logiciels à résoudre un problème clé.
Les bugs de sécurité au niveau de la mémoire ont un impact négatif sur la qualité
Les bugs de sécurité au niveau de la mémoire latents peuvent entraîner des résultats non déterministes, en fonction de l'état du système. Ce comportement imprévisible entraîne des plantages et des désagréments pour nos utilisateurs.
Chaque jour, nous observons des millions de plantages natifs sur les appareils des utilisateurs finaux et
avec l'introduction de GWP-ASan, nous avons constaté que la majorité d'entre eux étaient dus à des bugs de sécurité au niveau de la mémoire.
Ce point de données valide la corrélation entre la qualité
et la densité des bugs de sécurité au niveau de la mémoire, et correspond à ce que nos collègues de Chrome
observent (voir la liste des bugs les plus importants de Chrome GWP-ASan).
Les bugs de sécurité au niveau de la mémoire ont un impact négatif sur la sécurité
Les bugs de sécurité au niveau de la mémoire ont toujours été la principale cause des failles de sécurité Android, depuis la première version d'Android.
Figure 2. Contribution des bugs de sécurité au niveau de la mémoire aux failles Android
Bien qu'il soit encourageant de savoir qu'il ne s'agit pas uniquement d'un problème Android
(voir les statistiques de Chrome
et de Microsoft
), nous devons faire plus pour la sécurité de nos utilisateurs.
L'équipe Project Zero
de Google suit
les exploits zero day qui ont été utilisés dans des attaques réelles contre des utilisateurs en tant que failles zero day
vulnerabilities. Il ne s'agit pas de bugs hypothétiques, mais d'exploits activement utilisés dans des attaques contre des utilisateurs. Les bugs de sécurité au niveau de la mémoire (corruption de la mémoire et utilisation après libération)
représentent une majorité écrasante.
Les bugs de sécurité au niveau de la mémoire augmentent les coûts
Maintenir les appareils à jour avec des correctifs de sécurité protège nos utilisateurs, mais cela a un coût monétaire pour notre écosystème.
La forte densité de bugs de sécurité au niveau de la mémoire dans le code fournisseur de bas niveau, qui comporte souvent des modifications personnalisées, augmente considérablement les coûts de correction et de test. Toutefois, la détection précoce de ces bugs au cours du cycle de développement peut réduire ces coûts.
Les recherches montrent que la détection précoce des bugs peut réduire les coûts jusqu'à six fois. Toutefois, compte tenu de la complexité de notre écosystème, du nombre moyen de bases de code gérées par un fournisseur et de la complexité croissante des logiciels, les économies pourraient être plus importantes.
Sécurité de la mémoire
Android 12 et versions ultérieures incluent des modifications systémiques visant à réduire la densité des bugs de sécurité au niveau de la mémoire dans les bases de code Android. Nous étendons les outils de sécurité de la mémoire Android et introduisons de nouvelles exigences qui encouragent notre écosystème à résoudre cette catégorie de bugs. À terme, cela devrait se traduire par une qualité et une sécurité accrues pour nos utilisateurs ainsi que par des coûts réduits pour nos fournisseurs.
La sécurité de la mémoire devrait devenir un facteur de différenciation en termes de qualité et de sécurité dans les années à venir, et Android prévoit d'ouvrir la voie.
Exigences en faveur de la sécurité de la mémoire
Le document de définition de compatibilité Android (CDD) recommande fortement l'utilisation d'outils de sécurité de la mémoire lors du développement.
Nous collaborons étroitement avec notre écosystème pour accroître l'utilisation des outils de sécurité de la mémoire et les intégrer aux processus d'intégration et de test continus.
À terme, nous souhaiterions nous assurer que chaque appareil réussit une exécution complète de la Compatibility Test Suite (CTS) à l'aide d'outils de sécurité de la mémoire, ce qui démontre qu'aucun bug de ce type n'a été détecté. Par exemple, les plates-formes Arm v9 devront fournir une exécution CTS avec le balisage de la mémoire activé, tandis que les plates-formes Arm v8 devront fournir une exécution CTS à l'aide de HWASAN et de KASAN.
Rust comme nouveau langage de programmation pour le code de la plate-forme
Android 12 a introduit Rust comme langage de plate-forme. Rust protège la mémoire et les threads avec des niveaux de performances similaires à ceux de C/C++. Nous nous attendons à ce que Rust soit le choix privilégié pour la plupart des nouveaux projets natifs. Toutefois, il n'est pas possible de réécrire en Rust tout le code non sécurisé au niveau de la mémoire, qui représente actuellement plus de 70% de du code de la plate-forme Android. À l'avenir, Rust sera complémentaire des outils de sécurité de la mémoire.
Outils de sécurité de la mémoire
Android est compatible avec une grande variété d'outils permettant de détecter les bugs de sécurité au niveau de la mémoire. La figure ci-dessous présente une taxonomie des outils de sécurité de la mémoire Android disponibles.
Figure 3. Panorama des outils de sécurité de la mémoire Android
Nos outils couvrent un large éventail de scénarios et de cibles de déploiement. La documentation de cette section décrit chaque outil et fournit une référence pour les utiliser dans vos produits.