Google a annoncé la prise en charge de ce qu’on appelle un Bac à sable V8 dans le navigateur Web Chrome afin de résoudre les problèmes de corruption de mémoire.
Le bac à sable, selon Samuel Groß, responsable technique de la sécurité de V8, vise à empêcher « la corruption de la mémoire dans la V8 de se propager au sein du processus hôte ».
Le géant de la recherche a décrit le V8 Sandbox comme un bac à sable léger et en cours pour le moteur JavaScript et WebAssembly, conçu pour atténuer les vulnérabilités courantes de la V8.
L’idée est de limiter l’impact des vulnérabilités de la V8 en limitant le code exécuté par la V8 à un sous-ensemble de l’espace d’adressage virtuel du processus (« le bac à sable ») et en l’isolant du reste du processus.
Les lacunes affectant la V8 représentent une part importante des vulnérabilités zero-day que Google a corrigées entre 2021 et 2023, avec jusqu’à 16 failles de sécurité découvertes au cours de cette période.
“Le bac à sable suppose qu’un attaquant peut modifier arbitrairement et simultanément n’importe quelle mémoire à l’intérieur de l’espace d’adressage du bac à sable, car cette primitive peut être construite à partir de vulnérabilités typiques de la V8”, a déclaré l’équipe Chromium.
“En outre, on suppose qu’un attaquant sera capable de lire la mémoire en dehors du bac à sable, par exemple via des canaux latéraux matériels. Le bac à sable vise alors à protéger le reste du processus contre un tel attaquant. En tant que tel, toute corruption de la mémoire en dehors de l’espace d’adressage du bac à sable est considérée comme une violation du bac à sable.
Groß a souligné les défis liés à la lutte contre les vulnérabilités de la V8 en passant à un langage sécurisé comme Rust ou à des approches de sécurité de la mémoire matérielle, telles que le marquage de la mémoire, étant donné les « problèmes de logique subtils » qui peuvent être exploités pour corrompre la mémoire, contrairement aux bogues classiques de sécurité de la mémoire comme utilisation après libération, accès hors limites et autres.
“Presque toutes les vulnérabilités trouvées et exploitées dans la V8 aujourd’hui ont une chose en commun : la corruption éventuelle de la mémoire se produit nécessairement à l’intérieur du tas V8 car le compilateur et le runtime fonctionnent (presque) exclusivement sur les instances HeapObject V8”, a déclaré Groß.
Étant donné que ces problèmes ne peuvent pas être protégés par les mêmes techniques que celles utilisées pour les vulnérabilités typiques de corruption de mémoire, le bac à sable V8 est conçu pour isoler la mémoire tas de V8 de telle sorte qu’en cas de corruption de mémoire, elle ne puisse pas échapper aux limites de sécurité d’autres parties du processus. mémoire.
Ceci est accompli en remplaçant tous les types de données pouvant accéder à la mémoire hors sandbox par des alternatives « compatibles sandbox », empêchant ainsi efficacement un attaquant d’accéder à une autre mémoire. Le bac à sable peut être activé en définissant “v8_enable_sandbox” sur true dans les arguments gn.
Les résultats de référence de Speedometer et JetStream montrent que la fonctionnalité de sécurité ajoute une surcharge d’environ 1 % aux charges de travail typiques, ce qui lui permet d’être activée par défaut à partir de la version 123 de Chrome, couvrant Android, ChromeOS, Linux, macOS et Windows.
“Le V8 Sandbox nécessite un système 64 bits car il doit réserver une grande quantité d’espace d’adressage virtuel, actuellement un téraoctet”, a déclaré Groß.
« Le bac à sable est motivé par le fait que les technologies actuelles de sécurité de la mémoire sont largement inapplicables à l’optimisation des moteurs JavaScript. Bien que ces technologies ne parviennent pas à empêcher la corruption de la mémoire dans la V8 elle-même, elles peuvent en fait protéger la surface d’attaque du bac à sable V8. Le bac à sable est donc un élément nécessaire. un pas vers la sécurité de la mémoire.
Ce développement intervient alors que Google a souligné le rôle de Kernel Address Sanitizer (KASan) dans la détection des bogues de mémoire dans le code natif et contribue à renforcer la sécurité du micrologiciel Android, ajoutant qu’il utilisait l’outil basé sur un compilateur pour découvrir plus de 40 bogues.
“L’utilisation de builds compatibles KASan pendant les tests et/ou le fuzzing peut aider à détecter les vulnérabilités de corruption de mémoire et les problèmes de stabilité avant qu’ils n’atteignent les appareils des utilisateurs”, ont déclaré Eugene Rodionov et Ivan Lozano de l’équipe Android.
