Développeurs du projet Chromium 912 vulnérabilités dangereuses et critiques détectées dans les versions stables de Chrome depuis 2015, et il a été conclu que 70 % d'entre elles étaient dues à une mauvaise gestion de la mémoire (erreurs de gestion des pointeurs dans le code C/C++). La moitié de ces problèmes (36,1 %) sont causés par des accès au tampon après la libération de la mémoire associée (use-after-free).
Lors de la conception de Chromium, il a été , que des erreurs pourraient apparaître dans le code, c'est pourquoi une grande importance a été accordée à l'application de l'isolation sandbox pour limiter les conséquences de l'apparition de vulnérabilités. Actuellement, les capacités d'application de cette technologie ont atteint leur limite et une fragmentation supplémentaire des processus n'est pas justifiée du point de vue de la consommation des ressources.
Pour maintenir la sécurité de la base de code, Google applique également la «», selon laquelle tout code ajouté doit répondre à au plus deux conditions sur trois : traitement de données non vérifiées, utilisation d'un langage de programmation non sécurisé (C/C++) et exécution avec des privilèges élevés. De cette règle découle que le code pour le traitement des données externes doit soit être limité aux privilèges minimaux (isolé), soit être écrit dans un langage de programmation sécurisé.
Pour renforcer davantage la sécurité de la base de code, un projet a été lancé pour prévenir l'apparition d'erreurs de gestion de la mémoire dans la base de code. Trois approches principales sont mises en avant : création de bibliothèques C++ avec des fonctions pour une gestion sécurisée de la mémoire et élargissement du champ d'application du ramasse-miettes, application de mécanismes matériels de protection (Memory Tagging Extension) et rédaction de composants dans des langages garantissant une gestion sécurisée de la mémoire (Java, Kotlin, JavaScript, Rust, Swift).
Il est attendu que le travail se concentre sur deux directions :
- Un changement significatif du processus de développement en C++, n'excluant pas un impact négatif sur la performance (vérifications supplémentaires des limites et ramasse-miettes). Au lieu de pointeurs bruts, il est proposé d'utiliser dans le code le type , permettant de réduire les erreurs d'exploitation de type use-after-free à des plantages sans menace pour la sécurité, sans impact négatif perceptible sur la performance, la consommation de mémoire et la stabilité.
- L'utilisation de langages permettant d'effectuer des vérifications de la sécurité mémoire pendant la compilation (permettant d'éliminer l'impact négatif sur la performance typique de ces vérifications en temps d'exécution, mais engendrant des coûts supplémentaires pour l'interaction entre le code dans un nouveau langage et le code en C++).
L'utilisation de bibliothèques pour une gestion mémoire sécurisée est la méthode la plus simple mais aussi la moins efficace. La réécriture du code en Rust est considérée comme la voie la plus efficace, mais aussi très coûteuse.
Source : opennet.ru
