Développeurs du projet Chromium 912 vulnérabilités critiques et à haut risque identifiées dans les versions stables de Chrome depuis 2015, et ont conclu que 70 % d'entre elles étaient causées par une insécurité de la mémoire (erreurs lors de l'utilisation de pointeurs dans du code C/C++). La moitié de ces problèmes (36.1%) sont causés par des accès au buffer après avoir libéré la mémoire qui lui est associée (use-after-free).
Lors de la conception de Chromium, il s'agissait initialement , qu'il est possible que des erreurs apparaissent dans le code, l'accent a donc été mis sur l'utilisation de l'isolation sandbox pour limiter les conséquences des vulnérabilités. Actuellement, les possibilités d'utilisation de cette technologie ont atteint la limite de leurs capacités et une fragmentation supplémentaire en processus n'est pas pratique du point de vue de la consommation des ressources.
Pour maintenir la sécurité de la base de code, Google applique également "», selon lequel tout code ajouté ne doit remplir que deux des trois conditions : travailler avec des données d'entrée non validées, utiliser un langage de programmation non sécurisé (C/C++) et s'exécuter avec des privilèges élevés. Cette règle implique que le code de traitement des données externes doit être soit réduit à des privilèges minimaux (isolé), soit écrit dans un langage de programmation sécurisé.
Pour renforcer encore la sécurité de la base de code, un projet a été lancé pour éviter que des erreurs de mémoire n'apparaissent dans la base de code. Il existe trois approches principales : créer des bibliothèques C++ avec des fonctions permettant un fonctionnement sûr de la mémoire et étendre la portée du garbage collector, en utilisant des mécanismes de protection matérielle. (Memory Tagging Extension) et écriture de composants dans des langages garantissant un travail sécurisé avec la mémoire (Java, Kotlin, JavaScript, Rust, Swift).
Il est prévu que les travaux se concentreront sur deux domaines :
- Modification importante du processus de développement C++, qui n'exclut pas un impact négatif sur les performances (vérifications de limites supplémentaires et garbage collection). Au lieu de pointeurs bruts, il est proposé d'utiliser le type , qui vous permet de réduire les erreurs d'utilisation après libération exploitables aux plantages qui ne constituent pas une menace pour la sécurité, sans impact négatif notable sur les performances, la consommation de mémoire et la stabilité.
- L'utilisation de langages conçus pour effectuer des contrôles de sécurité de la mémoire au moment de la compilation (éliminera l'impact négatif sur les performances inhérent à de tels contrôles lors de l'exécution du code, mais entraînera des coûts supplémentaires pour organiser l'interaction du code dans un nouveau langage avec le code dans C++).
L'utilisation de bibliothèques sécurisées en mémoire est le moyen le plus simple, mais aussi le moins efficace. La réécriture de code dans Rust est considérée comme le moyen le plus efficace, mais aussi très coûteux.
Source: opennet.ru