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) la mémoire arbitraire, y compris la mémoire qui n'appartient pas à ce processus. Ces failles ont été nommées Spectre et Meltdown. Que fait Chrome pour sécuriser le 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 mettre à jour votre système d'exploitation et votre navigateur. Les utilisateurs de Chrome peuvent également envisager d'activer l'isolation de sites.

Si vous êtes un développeur Web, l'équipe Chrome vous fournit les conseils suivants:

  • Dans la mesure du possible, empêchez les cookies d'entrer dans la mémoire du processus du moteur de rendu en utilisant les attributs de cookie SameSite et HTTPOnly, et en évitant de lire des données depuis 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 dont le contenu est sensible ou spécifique à l'utilisateur. Vous pourrez ainsi tirer le meilleur parti du blocage de lecture d'origines multiples pour les utilisateurs qui ont activé l'isolation de sites.
  • Activez l'isolation de sites et signalez l'équipe Chrome si elle cause des problèmes à votre site.

Si vous vous demandez en quoi ces étapes sont utiles, poursuivez votre lecture.

Le risque

Ces failles ont été expliquées par de nombreuses explications. Je ne vais donc pas en ajouter une autre. Si vous souhaitez savoir comment exploiter ces failles, je vous recommande de consulter cet article de blog rédigé par mes collègues de l'équipe Google Cloud.

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

Stratégies d'atténuation

L'équipe d'ingénieurs Chrome et V8 déploie de nombreuses actions pour atténuer cette menace.

Isolation de sites

Il est possible de réduire considérablement l'impact de l'exploitation de Spectre en empêchant les données sensibles de partager un processus avec du code contrôlé par un pirate informatique. Pour y parvenir, l'équipe Chrome travaille sur 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 maintenant, activez chrome://flags#enable-site-per-process. Si vous trouvez un site qui ne fonctionne pas, veuillez nous aider en signalant un bug et en indiquant que l'isolation de sites est activée.

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 des sous-ressources intersites, telles que des images et du JavaScript. Pour éviter les fuites d'informations sensibles, l'isolation de sites inclut une fonctionnalité de blocage de documents intersites qui limite les réponses réseau envoyées au processus du moteur de rendu.

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

La règle de blocage des 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.
  2. Ils disposent soit d'un en-tête de réponse HTTP X-Content-Type-Options: nosniff, soit d'une analyse rapide du contenu ("reniflage") qui 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 se déroule toujours en arrière-plan.

Par exemple, imaginez qu'un pirate informatique crée une balise <img> incluant un fichier JSON contenant des données sensibles, comme <img src="https://yourbank.com/balance.json">. Sans isolation de sites, le contenu du fichier JSON est envoyé 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 désormais un moyen de lire ce fragment de mémoire. Le blocage de documents intersites empêche 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 diffusés avec les types MIME text/html ou text/plain. Pour éviter de bloquer les ressources marquées accidentellement comme documents, Chrome tente de renifler la réponse afin de s'assurer que le type MIME est correct. Ce reniflage n'étant pas parfait, si vous êtes certain de définir les en-têtes Content-Type corrects 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 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, seuls Chrome et Firefox 58 (ou 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 du 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 la définition de HTTPOnly n'est pas possible, vous pouvez limiter l'exposition du chargement des données de cookie dans le processus affiché 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 cinq microsecondes. Pour remédier à ce problème, tous les principaux navigateurs ont diminué la résolution de performance.now() afin de rendre l'installation des attaques plus difficile.

Une autre façon d'obtenir un minuteur haute résolution consiste à utiliser un 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 les démonstrations de faisabilité connues concernant les attaques, et travaille sur des modifications apportées à TurboFan, son compilateur d'optimisation, afin de sécuriser le code généré même lorsque ces attaques sont déclenchées. Toutefois, ces modifications de génération de code peuvent avoir une incidence sur les performances.

Protéger le Web

La découverte de Spectre et Meltdown et de leurs implications a généré de nombreuses incertitudes. J'espère que cet article vous éclaire sur les actions mises en place par les équipes Chrome et V8 pour sécuriser la plate-forme Web, et sur la façon dont les développeurs Web peuvent aider en utilisant les fonctionnalités de sécurité existantes. Si vous avez des questions, n'hésitez pas à me contacter sur Twitter.