Spectre / Meltdown l’analyse de nos experts

Vous reprendrez bien un peu de fondue aux fantômes ?

Ces deux vulnérabilités (Meltdown et Spectre) ont fait couler beaucoup d’encre ces derniers jours. Un alarmisme assez important les a entourées qui, de notre point de vue, n’est pas forcément justifié. En effet, ces deux familles d’attaque concernent l’exécution spéculative des processeurs modernes. Une mauvaise compréhension du contexte et de la différence entre les deux failles a occasionné une sorte d’amalgame et a accentué la réaction d’Internet.

 

De plus, il est également important de rappeler que les attaques sur les architectures de microprocesseurs ne sont pas nouvelles. À notre connaissance, Les premières datent de plus de 10 ans.

 

Dans ce cas, la nouveauté vient du fait qu’il n’est plus nécessaire d’avoir un accès physique aux machines ciblées et que l’exploitation de Meltdown et Spectre peut se faire à distance.

 

Comme mentionné précédemment, les deux familles d’attaques s’appuient sur des mécanismes des processeurs actuels, mais la comparaison s’arrête là.

Détaillons.

Spectre

Cette attaque utilise l’exécution spéculative pour lire des données du même processus. Sa principale exploitation semble être le contournement des mécanismes de « sandbox » comme dans le cas d’un navigateur Web attaqué via le JavaScript d’une page malveillante pour accéder à des données liées à un autre site (Ex. : Cookies de session, informations affichées, etc). Normalement, l’exécution du JavaScript est faite dans un environnement ne lui permettant pas d’accéder aux données d’autre site accédé par le navigateur. Cependant, à « temps perdu », les processeurs modernes tentent de deviner quel code va être exécuter prochainement (quand le code contient des branchements « IF », « CASE », etc.) et d’en faire l’exécution par avance. Si le processeur a correctement deviné quelle partie du branchement allait être exécutée, son exécution réelle sera plus rapide, car les données nécessaires sont déjà dans le cache du microprocesseur. Pour ce faire, le CPU garde une table des branchements effectués durant l’exécution et s’appuie dessus pour effectuer le « pari » statistiquement le plus probable pour les branchements futurs.

Avec l’attaque « Spectre », il devient possible de manipuler le chemin exploré par l’exécution spéculative afin de faire exécuter du code qui ne devrait pas l’être en temps normal en manipulant la table de branchements dans laquelle le processeur maintient des informations sur les branchements parcourus à des fins de prédiction statistique.

Cette attaque a un impact critique, car elle permet de récupérer des données sensibles normalement inaccessibles au sein de la mémoire du même processus tel que lors de l’exécution dans le contexte d’un site web de JavaScript par le navigateur. Sa criticité est d’autant plus importante qu’elle a vocation à pouvoir être utilisée à distance.

Toutefois, à l’heure actuelle, sa probabilité d’occurrence reste faible, car elle est particulièrement complexe à mettre en œuvre.

Meltdown

Cette attaque exploite l’exécution spéculative combiné à une élévation de privilège propre des processeurs Intel et un « side-channel » pour lire des données d’autres processus ou du noyau de l’OS dans le cas d’un système non virtualisé. Dans des cas de virtualisation, l’attaque peut être utilisée pour lire des données de l’hyperviseur ou d’autres machines virtuelles tournant sur le même hyperviseur.

Dans les grandes lignes, le mécanisme utilisé implique de provoquer la copie de données non autorisées par l’exécution spéculative dans la mémoire du processus malveillant. Bien entendu, les données copiées ne seront pas accessibles lors de l’exécution réelle, mais l’exécution spéculative force le chargement des ces données dans le cache du microprocesseur où elles seront vulnérables à une attaque de type « side-channel ».

Cette attaque à un impact critique, car elle permet la compromission complète de l’environnement où elle est exploitée, mais est également extrêmement complexe à mettre en œuvre dans un environnement réel.

En résumé

  Meltdown Spectre
Divulgation d’information du même processus. Oui Oui
Divulgation d’information d’autres processus Oui Non
Divulgation d’information de l’OS Oui Non
Divulgation d’information d’autres environnements dans le cas de la virtualisation Oui Non
Exploitation à distance Non Oui
Impact visant principalement Le Kernel Le Browser
Architecture impactée Intel Intel, AMD, ARM [1]

Mitigation et rappel des bonnes pratiques

Face à de telles vulnérabilités, quel comportement devons-nous avoir ?

Malgré le battage médiatique qui les a entourées, de notre point de vue, il n’y a pas tant de nouvelles choses sous le soleil que ça. Une stricte application des bonnes pratiques de sécurité semble suffisante pour mitiger en grande partie les risques liés à ces vulnérabilités, à commencer par l’application des correctifs de sécurités des fabricants et éditeurs. Par exemple, sous Linux, l’exploitation de Meltdown a été rendue impossible depuis la version 4.13 du noyau.

D’un autre côté bien entendu l’application des patchs doit être effectuée avec précaution ; des cas d’incompatibilité des patchs Windows pour ces vulnérabilités et de certains antivirus ont été reportés.

Il faut également gardé en tête que les patchs applicatifs doivent également être suivis et appliqués correctement. Dans le cas qui nous intéresse, les patchs des éditeurs de système opérationnel n’auront pas d’effet sur la vulnérabilité « Spectre » tant qu’une nouvelle version des applications recompilées avec des compilateurs eux aussi patchés n’auront pas été déployée. Il est donc important de recompiler les applications « maison » et d’appliquer les patchs des éditeurs de logiciels.

À ce niveau, il est également probable qu’il faille s’attendre à des patchs publiés par les fabricants afin de corriger le microcode des processeurs.

En dehors de l’application des patchs, la découverte de ces vulnérabilités remet sur le devant de la scène d’autres aspects liés aux bonnes pratiques de sécurité. C’est peut-être l’opportunité pour se reposer les bonnes questions au sujet de :

  • La ségrégation de nos données par niveau de sécurité,
  • L’architecture logique des infrastructures virtualisées,
  • La fiabilité de nos fournisseurs de services cloud (PaaS, IaaS),
  • La gestion des systèmes « Legacy » pour qui, il n’y aura certainement aucun patch.

 

En conclusion, une réflexion sur la durée de la période de renouvellement de nos systèmes physiques (serveurs et stations de travail) nous semble également importante vu que le hardware semble entrer dans le bal des « mises à jour » et que certainement les processeurs de demain seront non seulement plus performants, mais aussi plus sûrs que ceux d’aujourd’hui.

L’importance de système de monitoring et de préservation des traces est plus que jamais au goût du jour, car le fait de pouvoir réagir correctement et d’avoir rapidement une compréhension correcte de données/système qui on put être compromis semble prendre encore plus d’importance quand les attaques arrivent par des biais inattendus.

Finalement, gardons à l’esprit que les failles telles que ShellShock et HeartBleed ont été surmontées alors même que leur impact n’était pas beaucoup plus faible et que par contre leur facilité d’exploitation et leur probabilité d’occurrence étaient nettement plus importantes.

 

[1] Potentiellement tout type de processeurs modern ayant de fonctionnalité de changement de contexte pour permettre la virtualisation hardware.