Meltdown/Spectre

Surma

Présentation

Le 3 janvier, Project Zero a révélé des failles dans les processeurs modernes qu'un processus peut utiliser pour lire (au pire) de la mémoire arbitraire, y compris de la mémoire qui n'appartient pas à ce processus. Ces failles ont été nommées Spectre et Meltdown. Que fait Chrome pour contribuer à la sécurité du Web et que doivent faire les développeurs Web pour leurs propres sites ?

Résumé

En tant qu'utilisateur qui navigue sur le Web, vous devez vous assurer de mettre à jour votre système d'exploitation et votre navigateur. En outre, les utilisateurs de Chrome peuvent envisager d'activer l'isolation de sites.

Si vous êtes développeur Web, l'équipe Chrome vous conseille:

  • Dans la mesure du possible, empêchez les cookies d'entrer dans la mémoire du processus de rendu en utilisant les attributs de cookie SameSite et HTTPOnly, et en évitant de lire à partir de document.cookie.
  • Assurez-vous que vos types MIME sont corrects et spécifiez un en-tête X-Content-Type-Options: nosniff pour toutes les URL contenant du contenu sensible ou spécifique à l'utilisateur afin de tirer le meilleur parti du blocage de la lecture inter-origine pour les utilisateurs ayant activé l'isolation de site.
  • Activez l'isolation des sites et informez l'équipe Chrome si elle pose problème pour votre site.

Si vous vous demandez pourquoi ces étapes sont utiles, lisez la suite.

Le risque

De nombreuses explications ont été données sur ces failles. Je ne vais donc pas en ajouter une autre. Si vous souhaitez savoir comment ces failles peuvent être exploitées, je vous recommande de consulter le post de blog de mes collègues de l'équipe Google Cloud.

Meltdown et Spectre permettent potentiellement à un processus de lire de la mémoire qu'il n'est pas censé pouvoir lire. Il arrive que plusieurs documents provenant de différents sites partagent un processus dans Chrome. Cela peut se produire lorsqu'un élément a ouvert l'autre à l'aide de window.open, <a href="..." target="_blank"> ou d'iFrames. Si un site Web contient des données spécifiques à l'utilisateur, il est possible qu'un autre site puisse utiliser ces nouvelles failles pour lire ces données utilisateur.

Stratégies d'atténuation

L'équipe technique Chrome et V8 déploie plusieurs efforts pour atténuer cette menace.

Isolation de sites

L'impact d'une exploitation réussie de Spectre peut être considérablement réduit en empêchant les données sensibles de partager un processus avec du code contrôlé par un pirate informatique. L'équipe Chrome a travaillé sur une fonctionnalité appelée isolation de sites pour y parvenir :

L'isolation de sites n'est pas encore activée par défaut, car il existe quelques problèmes connus et l'équipe Chrome souhaite effectuer autant de tests sur le terrain que possible. Si vous êtes développeur Web, vous devez activer l'isolation de site et vérifier si votre site reste fonctionnel. Si vous souhaitez l'activer maintenant, activez chrome://flags#enable-site-per-process. Si vous constatez qu'un site ne fonctionne pas, veuillez nous aider en signalant un bug et en indiquant que vous avez activé l'isolation des sites.

Blocage des documents intersites

Même lorsque toutes les pages intersites sont placées dans des processus distincts, elles peuvent toujours légitimement demander certaines sous-ressources intersites, telles que des images et du code JavaScript. Pour éviter que des informations sensibles ne fuitent, l'isolation de site inclut une fonctionnalité de blocage de documents intersites qui limite les réponses réseau envoyées au processus de rendu.

Un site Web peut demander deux types de données à un serveur : "documents" et "ressources". Ici, les documents sont des fichiers HTML, XML, JSON et texte. Un site Web peut recevoir des documents à partir de son propre domaine ou d'autres domaines avec des en-têtes CORS permissifs. Les ressources incluent des éléments tels que des images, du code JavaScript, du code CSS et des polices. Les ressources peuvent être incluses à partir de n'importe quel site.

La règle de blocage des documents intersites empêche un processus de recevoir des "documents" provenant d'autres origines si:

  1. Elles ont un type MIME HTML, XML, JSON ou text/plain, et
  2. Ils disposent d'un en-tête de réponse HTTP X-Content-Type-Options: nosniff ou d'une analyse rapide du contenu (reniflage) qui confirme que le type est correct.
  3. Le CORS n'autorise pas explicitement l'accès au document

Les documents bloqués par cette stratégie sont présentés au processus comme vides, bien que la requête se produise toujours en arrière-plan.

Par exemple, imaginons qu'un pirate informatique crée une balise <img> qui inclut un fichier JSON contenant des données sensibles, comme <img src="https://yourbank.com/balance.json">. Sans l'isolation de site, le contenu du fichier JSON atteindrait la mémoire du processus de rendu, à quel point le moteur de rendu remarquerait qu'il ne s'agit pas d'un format d'image valide et ne renverrait pas d'image. Avec Spectre, il existe désormais un moyen de lire ce bloc de mémoire. Le blocage des documents intersites empêcherait le contenu de ce fichier d'entrer dans la mémoire du processus dans lequel le moteur de rendu s'exécute, car le type MIME est bloqué par le blocage des documents intersites.

D'après les métriques utilisateur, de nombreux fichiers JavaScript et CSS sont diffusés avec des types MIME text/html ou text/plain. Pour éviter de bloquer les ressources marquées par erreur comme documents, Chrome tente d'analyser la réponse pour s'assurer que le type MIME est correct. Cette analyse n'est pas parfaite. Par conséquent, si vous êtes sûr de définir les en-têtes Content-Type appropriés sur votre site Web, l'équipe Chrome vous recommande d'ajouter l'en-tête X-Content-Type-Options: nosniff à toutes vos réponses.

Si vous souhaitez essayer le blocage de documents intersites, activez l'isolation de site comme décrit ci-dessus.

SameSite cookies

Revenons à l'exemple ci-dessus: <img src="https://yourbank.com/balance.json">. Cela ne fonctionne que si votrebanque.com a stocké un cookie qui connecte automatiquement l'utilisateur. Les cookies sont généralement envoyés pour toutes les requêtes adressées au site Web qui définit le cookie, même si la requête est effectuée par un tiers à l'aide d'une balise <img>. Les cookies SameSite sont un nouvel attribut qui spécifie qu'un cookie ne doit être associé qu'à une requête provenant du même site, d'où leur nom. Malheureusement, au moment de la rédaction de cet article, seuls Chrome et Firefox 58 ou version ultérieure sont compatibles avec cet attribut.

HTTPOnly et document.cookie

Si les cookies de votre site ne sont utilisés que côté serveur et non par le code JavaScript client, vous pouvez empêcher les données du cookie d'entrer dans le processus de rendu. Vous pouvez définir l'attribut de cookie HTTPOnly, qui empêche explicitement l'accès au cookie via un script côté client dans les navigateurs compatibles, tels que Chrome. Si la configuration de HTTPOnly n'est pas possible, vous pouvez limiter l'exposition des données de cookie de chargement au processus de rendu en ne lisant pas document.cookie, sauf si cela est absolument nécessaire.

Lorsque vous créez un lien vers une autre page à l'aide de target="_blank", la page ouverte a accès à votre objet window, peut accéder à une autre URL depuis votre page et, sans l'isolation de site, se trouve dans le même processus que votre page. Pour mieux protéger votre page, les liens vers des pages externes qui s'ouvrent dans une nouvelle fenêtre doivent toujours spécifier rel="noopener".

Délais avant expiration haute résolution

Pour exploiter Meltdown ou Spectre, un pirate informatique doit mesurer le temps nécessaire pour lire une certaine valeur à partir de la mémoire. Pour cela, un minuteur fiable et précis est nécessaire.

La plate-forme Web propose l'API performance.now(), qui offre une précision de cinq microsecondes. Pour atténuer ce problème, tous les principaux navigateurs ont réduit la résolution de performance.now() afin de rendre les attaques plus difficiles à lancer.

Vous pouvez également obtenir un minuteur haute résolution à l'aide d'un SharedArrayBuffer. Un nœud de calcul dédié utilise le tampon pour incrémenter un compteur. Le thread principal lit ce compteur et l'utilise comme minuteur. Pour le moment, les navigateurs ont décidé de désactiver SharedArrayBuffer jusqu'à ce que d'autres mesures d'atténuation soient en place.

V8

Pour exploiter Spectre, une séquence d'instructions de processeur spécialement conçue est nécessaire. L'équipe V8 a implémenté des mesures d'atténuation pour les preuves de concept d'attaques connues et travaille sur des modifications dans TurboFan, son compilateur d'optimisation, qui rendent son code généré sécurisé même lorsque ces attaques sont déclenchées. Toutefois, ces modifications de génération de code peuvent entraîner une pénalité de performances.

Protéger le Web

La découverte de Spectre et de Meltdown, ainsi que leurs implications, ont suscité de nombreuses incertitudes. J'espère que cet article vous aura éclairé sur ce que font les équipes Chrome et V8 pour sécuriser la plate-forme Web, et sur la façon dont les développeurs Web peuvent contribuer en utilisant les fonctionnalités de sécurité existantes. Si vous avez des questions, n'hésitez pas à me contacter sur Twitter.