Firefox corrige une faille critique qui affecte aussi Chrome

0

Une mise à jour du navigateur Web Firefox de la Fondation Mozilla s’attaque à une vulnérabilité critique et à une poignée de failles de haute gravité. La mise à jour, publiée sous le nom de Firefox version 84, est également présentée par Mozilla comme améliorant les performances du navigateur et ajoutant une prise en charge native du matériel macOS fonctionnant sur ses propres processeurs Apple.

Au total, six failles de haute gravité ont été corrigées, en plus de la faille critique, identifiée comme CVE-2020-16042. La faille critique spécifique de Firefox a également été mis en évidence plus tôt ce mois-ci dans la mise à jour de sécurité du navigateur Chrome de Google, où elle a été classée comme une faille de gravité élevée.

La faille de Firefox et Chrome en question (CVE-2020-16042) n’est toujours pas entièrement détaillée par l’un ou l’autre des navigateurs et n’est répertorié que comme une faille de mémoire.

Cette faille mystérieuse de Firefox affecte aussi le navigateur Google Chrome

Dans l’avis de sécurité de Mozilla, CVE-2020-16042 est décrit comme une faille dans le composant JavaScript appelé BigInt qui «aurait pu provoquer l’exposition de la mémoire non initialisée».

BigInt est un composant JavaScript utilisé pour représenter des «entiers arbitrairement grands» dans le contexte d’un processus JavaScript dans le navigateur, selon une description de Mozilla.

firefox 73

Google décrit la même faille différemment. Il appelle cela une faille « d’utilisation non initialisée » affectant le moteur JavaScript V8 de Chrome. Le bulletin de Google ne précise pas non plus la nature exacte de la faille. Mais les chercheurs en cybersécurité ont décrit ces types de failles d’utilisation non initialisée comme «largement négligés» et souvent «considérés comme des erreurs de mémoire insignifiantes».

«[Celles-ci] sont en fait un vecteur d’attaque critique qui peut être exploité de manière fiable par les pirates pour lancer des attaques d’élévation de privilèges dans le noyau Linux», selon une étude de 2017 publiée par le Georgia Institute of Technology.

Le CVE a également été référencé la semaine dernière par Microsoft, dans le cadre de sa liste de failles Patch Tuesday du mois de Décembre affectant sa version 87.0.664.57 du navigateur Edge. Le navigateur Edge de Microsoft, sorti en janvier 2020, est basé sur Chromium, le projet de logiciel open source de Google. Le code source de Chromium est utilisé dans le navigateur Chrome de Google et le navigateur Edge 2020 de Microsoft.

Le moteur Javascript V8 et WebAssembly

Le moteur open-source JavaScript V8 a été développé par le projet Chromium pour les navigateurs Web Google Chrome et Chromium. Le moteur JavaScript V8 n’est pas pris en charge par Firefox, mais le composant WebAssembly, souvent associé à V8, l’est.

WebAssembly, ou WASM pour faire court, est un standard ouvert qui définit un format de code binaire portable pour les programmes exécutables, selon le projet WebAssembly. «WebAssembly décrit un environnement d’exécution en bac à sable sécurisé en mémoire qui peut même être implémenté dans des machines virtuelles JavaScript existantes», selon le site Web du projet.

firefox

Le navigateur Firefox de Mozilla n’est pas basé sur Chromium. WASM est pris en charge dans Mozilla Firefox et Apple Safari, même si les deux n’utilisent pas le V8 de Google. Certains indices sur la nature de la faille peuvent être dérivés du fait que la vulnérabilité affecte à la fois les navigateurs Firefox et Chrome – le dénominateur commun est WASM. De plus, une analyse de 2018 des failles WASM et V8 a mis en garde contre d’éventuels problèmes de sécurité.

En 2018, le Projet Zero de Google a publié une étude intitulée «The Problems and Promise of WebAssembly» et a identifié trois vulnérabilités, qui ont été atténuées. L’une des failles du futur de WASM, a averti Google, était liée à la fonction de ramasse-miettes (GC-Garbage Collector) de WebAssembly.

WebAssembly coupable?

GC est un processus important des moteurs JavaScript. Il permet une simplification massive dans les langages qui l’utilisent, puisque la mémoire n’a plus besoin d’être gérée explicitement par le programmeur. Il réduit (mais n’élimine pas!) une grande quantité d’erreurs et les fuites de mémoire qui affectent les applications lourdes. Pour certains programmes, il peut même améliorer les performances.

D’un autre côté, utiliser un langage qui s’appuie sur GC signifie renoncer à un contrôle considérable sur la gestion de la mémoire dans votre programme, ce qui est une préoccupation particulièrement importante pour les applications mobiles. Dans le cas de JavaScript, vous abandonnez tout contrôle sur la gestion de la mémoire: la spécification ECMAScript n’expose aucune interface au GC. Il n’y a aucun moyen pour une application Web de mesurer son utilisation de la mémoire ou de fournir des conseils au GC.

Malgré tout cela, les performances des langages de programmation qui utilisent GC ne sont pas strictement meilleures ou pires que les langages qui ne l’utilisent pas.

Google avait mis en garde en 2018:

«WebAssembly GC est une autre fonctionnalité potentielle de WebAssembly qui pourrait entraîner des problèmes de sécurité. Actuellement, certaines utilisations de WebAssembly présentent des problèmes de performances en raison de l’absence de gestion de mémoire de niveau supérieur dans WebAssembly. Par exemple, il est difficile d’implémenter une machine virtuelle Java performante dans WebAssembly. Si WebAssembly GC est implémenté, cela augmentera le nombre d’applications pour lesquelles WebAssembly peut être utilisé, mais cela augmentera également la probabilité que des vulnérabilités liées à la gestion de la mémoire se produisent à la fois dans les moteurs WebAssembly et dans les applications écrites en WebAssembly. « 

Dans les deux référentiels de bases de données de vulnérabilité, le MITRE et le NIST, les spécificités techniques du CVE n’ont pas encore été rendues publiques. Dans le bulletin de sécurité de Google du mois de Décembre, il a noté que les détails liés à CVE-2020-16042 et d’autres failles étaient retenus, « jusqu’à ce que la majorité des utilisateurs soient mis à jour avec un correctif. » Ils ont également noté que lorsque et si des failles existent dans des bibliothèques de codes tiers utilisées dans d’autres appareils ou plates-formes, les détails techniques des failles sont limités.

Le chasseur de bugs de sécurité André Bargull a initialement signalé la faille le 23 novembre, selon Google.

6 vulnérabilités de haute importance dans Firefox

Les problèmes de mémoire ont dominé la liste des failles de haute gravité corrigés par Mozilla. Deux «failles de sécurité de la mémoire» (CVE-2020-35114 et CVE-2020-35113) ont été corrigés. Les dernières versions sécurisées sont donc Firefox 84 et Firefox Extended Support Release (ESR) 78.6 pour les grandes entreprises.

«Certaines de ces failles ont démontré des preuves de corruption de la mémoire et nous supposons qu’avec suffisamment d’efforts, certaines d’entre elles auraient pu être exploitées pour exécuter du code arbitraire», a écrit Mozilla à propos des deux vulnérabilités.

Les failles identifiées comme CVE-2020-26971, CVE-2020-26972 et CVE-2020-26973 sont respectivement, un dépassement de tampon dans WebGL, une faille use-after-free dans WebGL et une faille dans l’assainissement du code CSS.

Laisser un commentaire