Aller au contenu principal

7 articles tagués avec « sécurité »

Voir tous les tags

Le Bac à Sable de V8

· 16 minutes de lecture
Samuel Groß

Après presque trois ans depuis le document de conception initial et des centaines de CL entretemps, le bac à sable V8 — un bac à sable léger et intégré pour V8 — a atteint un point où il n'est plus considéré comme une fonctionnalité de sécurité expérimentale. Dès aujourd'hui, le bac à sable de V8 est inclus dans le Programme de Récompenses pour les Vulnérabilités de Chrome (VRP). Bien qu'il reste un certain nombre de problèmes à résoudre avant qu'il ne devienne une limite de sécurité robuste, son inclusion dans le VRP constitue une étape importante dans cette direction. Chrome 123 pourrait donc être considéré comme une sorte de version "beta" pour le bac à sable. Cet article de blog est une opportunité de discuter des motivations derrière le bac à sable, de montrer comment il empêche la corruption de mémoire dans V8 de se propager dans le processus hôte, et finalement de démontrer pourquoi il est une étape nécessaire vers la sécurité mémoire.

V8 est plus rapide et plus sûr que jamais !

· 9 minutes de lecture
[Victor Gomes](https://twitter.com/VictorBFG), l'expert du Glühwein

Bienvenue dans le monde passionnant de V8, où la vitesse n'est pas seulement une caractéristique mais un mode de vie. Alors que nous disons adieu à 2023, il est temps de célébrer les réalisations impressionnantes que V8 a accomplies cette année.

Grâce à des optimisations innovantes en termes de performances, V8 continue de repousser les limites de ce qui est possible dans le paysage toujours en évolution du Web. Nous avons introduit un nouveau compilateur de niveau intermédiaire et mis en œuvre plusieurs améliorations dans l'infrastructure du compilateur de haut niveau, le runtime et le ramasse-miettes, ce qui a entraîné des gains de vitesse significatifs dans tous les domaines.

Intégrité du flux de contrôle dans V8

· 10 minutes de lecture
Stephen Röttger

L'intégrité du flux de contrôle (CFI) est une fonctionnalité de sécurité visant à empêcher les attaques exploitant les détournements de flux de contrôle. L'idée est que même si un attaquant parvient à corrompre la mémoire d'un processus, des vérifications d'intégrité supplémentaires peuvent les empêcher d'exécuter du code arbitraire. Dans cet article de blog, nous souhaitons discuter de notre travail pour activer le CFI dans V8.

Réadaptation de la sécurité mémoire temporelle sur C++

· 13 minutes de lecture
Anton Bikineev, Michael Lippautz ([@mlippautz](https://twitter.com/mlippautz)), Hannes Payer ([@PayerHannes](https://twitter.com/PayerHannes))
remarque

Remarque : Cet article a été initialement publié sur le blog de sécurité de Google.

La sécurité mémoire dans Chrome est un effort perpétuel pour protéger nos utilisateurs. Nous expérimentons constamment différentes technologies pour devancer les acteurs malveillants. Dans cet esprit, cet article évoque notre démarche d'utilisation des technologies d'analyse du tas afin d'améliorer la sécurité mémoire de C++.

Une année avec Spectre : une perspective V8

· 11 minutes de lecture
Ben L. Titzer et Jaroslav Sevcik

Le 3 janvier 2018, Google Project Zero et d'autres ont révélé les trois premières failles d'une nouvelle classe de vulnérabilités affectant les CPU utilisant l'exécution spéculative, nommées Spectre et Meltdown. En exploitant les mécanismes d'exécution spéculative des CPU, un attaquant pouvait temporairement contourner les vérifications implicites et explicites de sécurité dans le code empêchant les programmes de lire des données non autorisées en mémoire. Bien que la spéculation des processeurs ait été conçue comme un détail microarchitectural, invisible au niveau architectural, des programmes soigneusement conçus pouvaient lire des informations non autorisées lors de la spéculation et les divulguer via des canaux auxiliaires comme le temps d'exécution d'un fragment de programme.

Désactivation temporaire de l'analyse d'évasion

· 2 minutes de lecture
Mathias Bynens ([@mathias](https://twitter.com/mathias)), analyste d'évasion de sandbox

En JavaScript, un objet alloué s'échappe s'il est accessible depuis l'extérieur de la fonction actuelle. Normalement, V8 alloue de nouveaux objets sur le tas JavaScript, mais en utilisant l'analyse d'évasion, un compilateur optimisant peut déterminer quand un objet peut être traité de manière spéciale parce que sa durée de vie est prouvée comme étant liée à l'activation de la fonction. Lorsque la référence à un objet nouvellement alloué n'échappe pas à la fonction qui le crée, les moteurs JavaScript n'ont pas besoin d'allouer explicitement cet objet sur le tas. Ils peuvent plutôt traiter efficacement les valeurs de l'objet comme des variables locales à la fonction. Cela permet à son tour toutes sortes d'optimisations comme stocker ces valeurs sur la pile ou dans des registres, ou dans certains cas, optimiser complètement les valeurs. Les objets qui s'échappent (plus précisément, les objets dont on ne peut pas prouver qu'ils ne s'échappent pas) doivent être alloués sur le tas.

À propos de cette vulnérabilité de hash flooding dans Node.js…

· 7 minutes de lecture
Yang Guo ([@hashseed](https://twitter.com/hashseed))

Début juillet de cette année, Node.js a publié une mise à jour de sécurité pour toutes les branches actuellement maintenues afin de résoudre une vulnérabilité liée au hash flooding. Ce correctif intermédiaire se fait au prix d'une régression significative des performances au démarrage. Entre-temps, V8 a mis en œuvre une solution qui évite cette pénalisation des performances.