Firefox 95 est disponible et signe le déploiement de RLBox sur toutes les plateformes,
la technologie de sandboxing renforce le navigateur contre les vulnérabilités de sécurité potentielles dans les bibliothèques tierces

Mozilla a annoncé la disponibilité de Firefox 95. RLBox, une nouvelle technologie qui renforce Firefox contre les vulnérabilités de sécurité potentielles dans les bibliothèques tierces, est désormais activé sur toutes les plateformes (desktop comme mobiles). RLBox permet de convertir rapidement des composants du navigateur pour qu'ils fonctionnent de manière isolée dans une sandbox WebAssembly (wasm). En outre, le processeur est moins sollicité avec Firefox et WindowServer sur Mac pendant le traitement des événements.

L'équipe indique avoir réduit l'utilisation du processeur sur macOS dans Firefox et WindowServer pendant le traitement des événements. Si le nom du processus WindowServeur ferait penser à Windows Serveur, il n'en est rien.

Il s'agit du processus de macOS qui dessine les éléments à l'écran, qu'il s'agisse des fenêtres d'applications, d'icônes ou de sites web. Le nombre de cycles processeur requis par WindowServer augmente en même temps que le nombre de fenêtre ouvertes sur votre Mac. La plupart des éléments graphiques sont régulièrement actualisés ; c'est pourquoi WindowServer utilise les cycles processeur. Il doit ainsi redessiner votre écran à chaque fois que vous déplacez une fenêtre ou que vous modifiez une image dans Photoshop, ou encore lorsque vous changez d'onglet dans Safari.

Et quand on sait qu'il y a un grand nombre d'effets sur les fenêtres macOS, comme des transparences et des ombres portées, il n'y a rien d'étonnant à ce que le fait de les dessiner consomme beaucoup de ressources.

L'équipe indique avoir également réduit la consommation d'énergie de la vidéo décodée par logiciel sur macOS, en particulier en plein écran. Cela inclut les sites de streaming tels que Netflix et Amazon Prime Video. Mozilla ajoute que le lancement de Firefox sur Mac est désormais plus rapide.

Vous pouvez maintenant déplacer le bouton bascule Picture-in-Picture vers le côté opposé de la vidéo. Recherchez simplement la nouvelle option de menu contextuel Déplacer l'incrustation d'image vers le côté gauche (droit). L’incrustation vidéo (Picture-in-Picture, PiP) vous permet de détacher une vidéo d’une page web pour la transférer dans une fenêtre flottante, toujours au premier plan, pour que vous puissiez regarder la vidéo tout en continuant à travailler dans d’autres onglets. Vous pouvez ouvrir plusieurs fenêtres d’incrustation vidéo et les déplacer ou les redimensionner à votre convenance.

Pour mieux protéger les utilisateurs de Firefox contre les attaques par canaux secondaires telles que Spectre, l'isolation de site est désormais activée pour tous les utilisateurs de Firefox 95.

Nom : firefox.png Affichages : 8533 Taille : 133,9 Ko

Une nouvelle technologie de sandboxing

Firefox 95 inclut RLBox, que Mozilla présente comme une nouvelle technologie renforçant le navigateur contre les failles de sécurité potentielles dans les bibliothèques tierces. Ce système de sandboxing vient isoler les sous-composants pour rendre le navigateur plus sûr.

Bobby Holley, ingénieur chez Mozilla, explique :

« Dans Firefox 95, nous proposons une nouvelle technologie de sandboxing appelée RLBox, développée en collaboration avec des chercheurs de l'Université de Californie à San Diego et de l'Université du Texas, qui permet d'isoler facilement et efficacement les sous-composants pour sécuriser le navigateur. Cette technologie ouvre de nouvelles opportunités au-delà de ce qui était possible avec le sandboxing traditionnel basé sur les processus, et nous sommes impatients d'étendre son utilisation et (espérons-le) de la voir adoptée dans d'autres navigateurs et projets logiciels.

« Cette technique, qui utilise WebAssembly pour isoler le code potentiellement bogué, s'appuie sur le prototype que nous avons livré l'année dernière aux utilisateurs Mac et Linux. Maintenant, nous apportons cette technologie à toutes les plateformes Firefox prises en charge (ordinateurs de bureau et mobiles) et isolons cinq modules différents : Graphite, Hunspell, Ogg, Expat et Woff2.

« À l'avenir, nous pouvons traiter ces modules comme du code non fiable et, en supposant que nous l'ayons bien fait, même une vulnérabilité zero-day dans l'un d'entre eux ne devrait constituer aucune menace pour Firefox. En conséquence, nous avons mis à jour notre programme de primes aux bogues pour payer les chercheurs qui contournent le bac à sable même sans vulnérabilité dans la bibliothèque isolée ».

Les limites du processus de Sandboxing

Tous les principaux navigateurs exécutent le contenu Web dans leur propre processus de sandboxing, l'empêchant en théorie d'exploiter une vulnérabilité du navigateur pour compromettre votre ordinateur. Sur les systèmes d'exploitation de bureau, Firefox isole également chaque site dans son propre processus afin de protéger les sites les uns des autres.

Malheureusement, les acteurs malveillant attaquent régulièrement les utilisateurs en exploitant deux vulnérabilités*: l'une pour compromettre le processus en bac à sable contenant le site malveillant et l'autre pour échapper au bac à sable. Pour protéger les utilisateurs contre les adversaires les mieux financés, il est nécessaire pour un navigateur de disposer de plusieurs couches de protection.

Du côté de Firefox, ayant déjà isolé les éléments le long des limites de confiance, la prochaine étape logique consistait à faire un isolement au-delà des limites fonctionnelles. Historiquement, cela signifiait hisser un sous-composant dans son propre processus. Par exemple, Firefox exécute des codecs audio et vidéo dans un processus dédié et verrouillé avec une interface limitée avec le reste du système. Cependant, il existe de sérieuses limites à cette approche. Premièrement, cela nécessite de découpler le code et de le rendre asynchrone, ce qui prend généralement du temps et peut imposer un coût de performance. Deuxièmement, les processus ont une surcharge mémoire fixe, et en ajouter davantage augmente l'empreinte mémoire de l'application.

Pour toutes ces raisons, personne n'envisagerait sérieusement d'intégrer quelque chose comme l'analyseur XML dans son propre processus. Pour isoler à ce niveau de granularité, il est donc crucial d'avoir une approche différente.

Isoler avec RLBox

C'est là qu'intervient RLBox. Plutôt que de hisser le code dans un processus séparé, Firefox le compile dans WebAssembly, puis compile ce WebAssembly dans le code natif. Cela ne l'oblige pas à envoyer des fichiers .wasm dans Firefox, car l'étape WebAssembly n'est qu'une représentation intermédiaire dans son processus de construction.

Cependant, la transformation impose deux restrictions clés au code cible*: il ne peut pas accéder à des parties inattendues du reste du programme et il ne peut pas accéder à la mémoire en dehors d'une région spécifiée. Ensemble, ces restrictions permettent de partager en toute sécurité un espace d'adressage (y compris la pile) entre le code de confiance et le code non fiable, ce qui permet de les exécuter dans le même processus en grande partie comme Firefox le faisait auparavant. Ceci, à son tour, facilite l'application sans refactorisation majeure : le développeur n'a qu'à nettoyer toutes les valeurs provenant du bac à sable (car elles pourraient être conçues de manière malveillante), une tâche que RLBox rend facile avec une couche de contamination.

La première étape de cette transformation est simple : les ingénieurs utilise Clang pour compiler Firefox, et Clang sait comment émettre WebAssembly, ils doivent donc simplement basculer le format de sortie pour le module donné du code natif à wasm. Pour la deuxième étape, leur implémentation de prototype a utilisé Cranelift. Cranelift est excellent, mais un deuxième générateur de code natif a ajouté de la complexité - et les ingénieurs ont réalisé qu'il serait plus simple de simplement mapper le WebAssembly dans quelque chose que leur système de build existant pourrait ingérer.

Ils y sont parvenus avec wasm2c, qui effectue une traduction directe de WebAssembly en code C équivalent, qu'ils peuvent ensuite renvoyer dans Clang avec le reste du code source de Firefox. « Cette approche est très simple et active automatiquement un certain nombre de fonctionnalités importantes que nous prenons en charge pour le code Firefox standard*: optimisation guidée par profil, intégration au-delà des limites du bac à sable, rapports de plantage, prise en charge du débogueur, indexation du code source et probablement d'autres choses que nous avons encore à apprécier ».

Source : note de version

Voir aussi :

L'utilisation de Firefox est en baisse de 85 % malgré une augmentation de 400 % de la rémunération du PDG de Mozilla. Cal Paterson analyse les échecs de Mozilla