Meltdown/Spectre

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) la mémoire arbitraire, y compris une mémoire qui n'appartient pas à ce processus. Ces failles ont été nommées Spectre et Meltdown. Que fait Chrome pour assurer la sécurité du Web, et que doivent faire les développeurs Web pour leurs propres sites ?

résumé

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

Si vous êtes un 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 les données 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 comportant du contenu sensible ou spécifique aux utilisateurs afin de tirer le meilleur parti du blocage de la lecture d'origines multiples pour les utilisateurs pour lesquels l'isolation de sites est activée.
  • Activez l'isolation de sites et indiquez à l'équipe Chrome si cela entraîne des problèmes pour votre site.

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

Le risque

Il existe une grande variété d'explications pour 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 l'article de blog de mes collègues de l'équipe Google Cloud.

Meltdown et Spectre permettent potentiellement à un processus de lire la mémoire qu'il n'est pas censé pouvoir lire. Parfois, plusieurs documents provenant de sites différents peuvent finir par partager le même processus dans Chrome. Cela peut se produire si l'un 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 à un utilisateur, il est possible qu'un autre site utilise ces nouvelles failles pour lire ces données.

Stratégies d'atténuation

Les ingénieurs Chrome et V8 déploient de nombreux 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 des pirates informatiques. À cet effet, l'équipe Chrome a développé une fonctionnalité appelée Isolation de sites :

L'isolation de sites n'a pas encore été 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, nous vous conseillons d'activer l'isolation de sites et de vérifier si votre site reste fonctionnel. Si vous souhaitez l'activer dès maintenant, activez chrome://flags#enable-site-per-process. Si vous trouvez un site qui ne fonctionne pas, aidez-nous en signalant un bug en indiquant que vous avez activé l'isolation de sites.

Blocage de documents intersites

Même lorsque toutes les pages intersites sont placées dans des processus distincts, les pages peuvent toujours demander légitimement certaines sous-ressources intersites, telles que des images et JavaScript. Pour empêcher la fuite d'informations sensibles, l'isolation de sites inclut une fonctionnalité de blocage de documents intersites qui limite les réponses réseau transmises au processus du moteur de rendu.

Un site Web peut demander deux types de données à un serveur : "documents" et "ressources". Ici, les documents sont au format HTML, XML, JSON et des fichiers texte. Un site Web peut recevoir des documents 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 CSS et des polices. Vous pouvez inclure des ressources à partir de n'importe quel site.

La règle de blocage de documents intersites empêche un processus de recevoir des "documents" d'autres origines dans les cas suivants:

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

Les documents bloqués par cette règle sont présentés au processus comme vides, bien que la requête soit toujours exécutée en arrière-plan.

Par exemple, imaginez qu'un pirate informatique crée un tag <img> incluant un fichier JSON contenant des données sensibles, comme <img src="https://yourbank.com/balance.json">. Sans l'isolation de sites, le contenu du fichier JSON entre dans la mémoire du processus de rendu. Le moteur de rendu remarque alors qu'il ne s'agit pas d'un format d'image valide et n'affiche pas d'image. Avec Spectre, il existe maintenant un moyen de lire potentiellement ce fragment de mémoire. Le blocage de 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 de documents intersites.

D'après les métriques utilisateur, de nombreux fichiers JavaScript et CSS sont envoyés avec les types MIME text/html ou text/plain. Pour éviter de bloquer les ressources marquées accidentellement en tant que documents, Chrome tente de renifler la réponse afin de s'assurer que le type MIME est correct. Ce reniflage n'est pas parfait. Par conséquent, si vous êtes sûr de définir les bons en-têtes Content-Type sur votre site Web, l'équipe Chrome vous recommande d'ajouter l'en-tête X-Content-Type-Options: nosniff à toutes vos réponses.

Pour essayer le blocage de documents intersites, activez l'isolation de sites 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ù son nom. Malheureusement, au moment de la rédaction de ce document, seul Chrome et Firefox 58 et versions ultérieures 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, il existe des moyens d'empêcher les données du cookie d'entrer dans le processus du moteur 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 sur les navigateurs compatibles tels que Chrome. Si vous ne pouvez pas définir HTTPOnly, vous pouvez limiter l'exposition des données des cookies de chargement au processus de rendu en ne lisant document.cookie que 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 et peut accéder à votre page vers une autre URL. Sans l'isolation de sites, le processus est le même que pour 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".

Minuteurs haute résolution

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

L'une des API proposées par la plate-forme Web est performance.now(), avec une précision de 5 microsecondes. Pour limiter le problème, tous les principaux navigateurs ont diminué la résolution de performance.now() afin de rendre le montage des attaques plus difficile.

Un autre moyen d'obtenir un minuteur haute résolution consiste à utiliser SharedArrayBuffer. Le tampon est utilisé par un nœud de calcul dédié 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 mis en œuvre des mesures d'atténuation pour des preuves de concept d'attaque connues et travaille sur des modifications de TurboFan, son compilateur d'optimisation, qui renforcent la sécurité du code généré même lorsque ces attaques sont déclenchées. Toutefois, ces modifications de génération de code peuvent nuire aux performances.

Veiller à la sécurité sur le Web

La découverte de Spectre et Meltdown et de leurs conséquences est source d'incertitudes. J'espère que cet article vous éclairera sur ce que font les équipes Chrome et V8 pour assurer la sécurité de la plate-forme Web, et sur la manière dont les développeurs Web peuvent aider les développeurs Web à l'aide des fonctionnalités de sécurité existantes. Si vous avez des questions, n'hésitez pas à me contacter sur Twitter.