Meltdown, Spectre and Rowhammer -- 2018 sera une année chaude pour la sécurité informatique (et pour Intel)

Introduction

Si les abstractions sont utiles en général, et en informatique en particulier, l'informatique peut difficilement être considérée dans un modèle en couche: les interactions entre couches sont nombreuses, et un seul bit corrompu par un effet de bord d'une couche supérieure peut avoir des résultats catastrophiques au travers de toutes les abstractions.

Trois vulnérabilités actuelles exposées ci-dessous montrent ce problème et peut-être la nécessité de design de processeurs soumis à la revue de tiers ou à la communauté open source.

En effet, ces vulnérabilités mettent à mal l'isolation offerte par le matériel, que cela soit

• le confinement offert par les logiciels (Sandbox Javascript, JVM Java)
• le confinement offert par le MMU entre user-space et kernel-space
• la virtualisation, quelque soit le degré d'isolation (container -> virtualisation de CPU)

P.ex. sur plateforme Android, les applications sont confinées au sein d'une JVM (sauf le code natif), puis par le kernel. Potentiellement ces vulnérabilités permettent d'aller lire, voire modifier, n'importe quelle valeur de n'importe quel processus ou du kernel. De même dans le cloud, vos données peuvent être lues, voire modifiées, par un autre client de ce cloud qui par hasard s'exécute également sur la même machine physique. Enfin tout ordinateur desktop ou mobile peut être attaqué par une violation du confinement de la Sandbox Javascript.

Bien sûr, des work-arounds sont entrain d'être installés, toutefois certains de ces problèmes sont suffisamment graves pour nécessiter des changement de design des processeurs à l'avenir, et certains (Rowhammer, Spectre) ne semblent pas corrigeables actuellement.

On connaissait déjà des vulnérabilités de bit-flipping (Rowhammer) et de devinage de clés AES par abus de cache en Javascript, mais ce qui vient d'être découvert est du lourd!

Bases théoriques

MMU	unité du processeur permettant de gérer la mémoire virtuelle; elle est notamment utilisée pour séparer complètement l'adressage d'un processus à l'autre, ou rendre en lecture seule certaines parties
adressage virtuel	les adresses mémoire accessibles par un processus donné sont limités à son adressage virtuel, qui est associé par MMU à de la RAM physique
speculative execution	l'idée qu'en cas de branchement (par exemple une instruction similaire à un if), le processeur peut lancer l'exécution d'une branche à l'avance, en ne conservant les résultats que si cette branche est vraiment valide: cela augmente, par parallélisation (pipeline), la performance des processeurs modernes
cache	une unité qui permet d'accélérer l'accès à la mémoire en stockant des parties de celles-ci dans le processeur (CPU), au besoin; se basant sur le principe de la localité d'exécution

Les vulnérabilités

Globalement, ces vulnérabilités ne sont exploitables que si du code de tiers tourne sur votre machine (ou, d'autres machines virtuelles de tiers côte-à-côte aux vôtres sur une même infrastructure, aka le cloud).

Sur une machine personnelle, si le code que vous tournez est signé et que vous faites confiance à l'éditeur du logiciel, vous avez probablement pas trop de souci à avoir: les paranoïaques désactiveront le Javascript dans leur navigateur.

Sur un smartphone ou sur le cloud, c'est plus ennuyeux.

Dans tous les cas, si un buffer overflow est possible, menant à du code exécutable, on a un plus gros problèmes qu'avec ces vulnérabilités: il reste important de mettre à jour, et les développeurs doivent utiliser les techniques anti buffer overflow (non executable stack, randomized user and kernel addresses, etc).

Meltdown

En utilisant une propriété des processeurs modernes, l'exécution spéculative, il est facile, sur processeur Intel datant de moins de dix ans, d'accéder en lecture à des données de l'ensemble de l'adressage virtuel d'un processus, même lorsque des règles du MMU interdisent l'accès.

Comme pour des raisons de performance, les données du kernel (le système d'exploitation de base, privilégié) sont intégrées à l'adressage virtuel de chaque processus (p.ex. en Linux 32 bits: 3 GB propre à chaque processus, plus 1 GB pour le kernel), toutefois inaccessibles par des règles de MMU (techniquement: page mappée mais non accessible), cela signifie que tout processus utilisateur peut maintenant aller lire des données privées du kernel, ce qui est une attaque de priviledge escalation.

C'est un bug de processeur, qui ne peut pas être corrigé par microcode par Intel (sauf sur quelques modèles récents). Le principe est que l'exécution spéculative va précharger des caches en violant les règles d'accès du MMU, et on pourra ensuite accéder aux données des caches.

L'impact est principalement pour les fournisseurs de service cloud (Javascript Sandbox, JVM, container ou virtualisation lourde): Google, Amazon, Microsoft (Azure) ainsi que les plus petits comme Hetzner, Exoscale, etc.

Si vous tournez du code auquel vous faisez confiance sur votre propre infrastructure, il n'est pas nécessaire d'installer le work-around. Par contre, avec du code C ou C++ ou tout code produisant du code machine (JIT compiler Java p.ex.) on peut imaginer une attaque permettant de lire l'ensemble des données du processus, de la machine virtuelle ainsi que d'autres machines virtuelles du même serveur du cloud, d'où la panique!

Le work-around logiciel (mise à jour du kernel) est d'isoler complètement l'address-space du kernel et de chaque processus. Avec une pénalité [1] évaluée de 5 à 30 pourcent sur la performance CPU. Ce work-around a été publié aujourd'hui sur GNU/Linux, et sera probablement disponible la semaine prochaine sous Microsoft. Apple est également concerné (desktop Intel), mais aussi sur les mobiles iOS (processeur ARM-compatible, également touché). Les AMD ne sont pas touchés par ce bug, et voir en particulier pour les apu2.

[1] chaque appel système (du processus au kernel) doit maintenant reconfigurer le MMU, et les caches CPU doivent être effacés. Une application faisant beaucoup d'appels kernel va être plus touchée qu'une application de calcul mathématique entièrement en user-space, n'utilisant que des bibliothèques user-space comme la libm ou la libc. Toutefois, c'est plus performant si votre CPU supporte les PCIDs, qui permettent d'associer une partie de cette configuration à un identifiant modifiable uniquement par le kernel. Cela veut dire aussi que les PCIDs sont maintenant une partie essentielle de la sécurité d'un OS ...

• Installation patch Meltdown ce vendredi soir 12 janvier 2018, on semble voir une augmentation de la charge CPU système (et de la charge totale), assez faible car ce système a les PCID:
  

Spectre

Cette vulnérabilité a l'inconvénient de toucher quasi tous les types de processeur (contrairement à Meltdown), et en plus d'être difficilement patchable. Son principe est de mesurer le temps que prennent certaines instructions, et en particulier de dériver le temps qu'a pris l'exécution de branches spéculatives.

En bref, on construit une suite d'instruction ainsi qu'un branchement (saut, ou if) qu'on sait ne sera finalement pas exécuté en raison d'une condition non connue initialement du processeur. Le processeur va spéculer que la branche sera prise et va commencer l'exécution de celle-ci. Ensuite, après avoir remarqué que cette branche n'est pas nécessaire, il annulera ses effets. On a construit la branche pour contenir elle-même un branchement, lui-même dépendant d'une valeur que l'on n'est pas censé accéder, en s'assurant que les caches sont vides (p.ex. en accédant plein de données avant l'attaque). Le temps d'exécution de cette branche spéculative nous indiquera la valeur de la donnée après essais-erreurs (est-ce un zéro? est-ce un 1, etc).

La preuve de concept a été effectuée en Javascript à l'intérieur d'une Sandbox (container d'un navigateur) et a permis de lire l'ensemble de l'adress-space d'un processus.

Potentiellement, associé à Meltdown, cela permet avec du code Javascript dans une sandbox dans un processus navigateur dans une machine virtuelle de lire l'ensemble des données de la machine réelle et de toutes les machines virtuelles associées. Sans Meltdown, cela permet de sortir d'une Sandbox.

Work-around: Firefox a modifié la gestion des timers (compteurs de temps) de sa Sandbox Javascript pour la rendre moins précise, ce qui devrait rendre cette attaque beaucoup moins facile dans Firefox 57.0.4. En effet, le Javascript est un des rares cas où du code d'origine douteuse est téléchargé puis exécuté sur une machine (à part l'installation de logiciels, que l'on suppose signés et fournis par des développeurs auxquels on fait confiance). En Firefox LSR (Long Support Release), le bug n'est pas présent, ou pas entièrement.

Rowhammer

Cette vulnérabilité déjà ancienne, que l'on croyait être limitée à la potentialité de créer des corruptions de bits sur des DRAM (mémoire physique la plus classique) permet en fait l'accès écriture à n'importe quelle adresse de l'espace virtuel, ce qui combiné à une des vulnérabilités ci-dessous la rend très ennuyeuse, en particulier vu qu'il s'agit d'un problème difficile à corriger sans coût.

En effet, les DRAM perdraient leurs données si elles n'étaient pas rafraîchies régulièrement: plus on les rafraîchit (par lecture automatique), plus on perd des cycles pour l'accès mémoire utile du CPU. Le bug est qu'avec des accès particuliers dans un ordre dépendant de l'agencement matériel, on peut faire changer des bits non logiquement reliés (pas même adresse) en utilisant des propriétés connues d'un rafraîchissement économiquement supportable.

Est-ce que l'ECC suffit pour éviter le problème? non, mais de nouveaux design d'ECC peuvent aider.

Même sans Meltdown ou Spectre, elle permet de modifier n'importe quelle valeur d'une machine: donc par exemple de s'attribuer des privilèges.

MDS

De nombreux work-arounds ont été publiés à la fois dans les microcode de processeur (package non-free intel-microcode dans Debian), dans les kernels, dans les hyperviseurs (KVM p.ex.) ainsi que pour certains des modifications de la bibliothèque C standard ou des compilateurs, nécessitant pour certaines applications des recompilations.

Toutefois, certains de ces problèmes ne sont pas forcément corrigeables: certains permettent des attaques à long terme permettant p.ex. de voler des données dans d'autres processus, dans d'autres machines virtuelles, dans le host, voire même depuis un navigateur avec le Javascript activé -- d'où certains work-arounds dans les navigateurs pour baisser la précision de certains timers.

Un changement d'architecture est peut-être nécessaire, voire obliger l'ouverture des spécifications de processeur. [3]

Pour la dernière vague de type d'attaques publiées lundi 13 mai 2019, si vous tournez un serveur qui lance du code de tiers (machines virtuelles, code Javascript, ...), soit vous mettez à jour au dernier microcode, au dernier kernel, aux derniers patches KVM quand ils seront là, etc, ou, une solution un peu basique existe: désactiver l'hyperthreading en attendant. Evidemment cela aura un impact sur la charge de vos serveurs [4]. Dans tous les cas, les work-around coûtent [5].

Voici un script sans garantie, à lancer à chaque démarrage, p.ex. dans /etc/rc.local:

#! /bin/bash
# ASSUMPTION
#    - threads_sibling always in the same order, which is what
#      I observed
#    - CPU 0 cannot be disabled, thus always disabling the second
#      sibling
#    - more than two siblings may need to run this script more than once
# BUGS

for i in $(cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list | sort -u | awk -F , '/,/ {print $2;}')
do
   echo 0 > /sys/devices/system/cpu/cpu$i/online
done

[1] https://wiki.alphanet.ch/Sandbox/MeltdownSpectreRowhammer
[2] https://wiki.alphanet.ch/Sandbox/MeltdownSpectreRowhammer#Rowhammer
[3] https://blog.alphanet.ch/entry/110
[4] https://cpu.fail/
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html
[5] impact de performance
https://www.phoronix.com/scan.php?page=article&item=intel-mds-xeon&num=1
https://www.phoronix.com/scan.php?page=article&item=mds-zombieload-mit&num=1

Plateformes embarquées

Quelques informations pour apu2 (amd64) de la part du fournisseur. Comme nous l'exploitons sous OS standard (Debian GNU/Linux stable), les mêmes protections de l'OS sont disponibles.

Vulnérabilités suivantes concernant toujours la faible isolation

• https://mdsattacks.com/
• https://www.digitec.ch/fr/page/une-nouvelle-faille-dans-les-processeurs-amd-met-en-danger-des-millions-dordinateurs-28912
  • https://lock.cmpxchg8b.com/zenbleed.html
  • https://downfall.page/

Références

• https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
  • https://en.wikipedia.org/wiki/Kernel_page-table_isolation
• https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
• https://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

clarification entre Spectre, Meltdown, et les variantes montrées par Google Project Zero

• https://googleprojectzero.blogspot.ch/2018/01/reading-privileged-memory-with-side.html
  • Spectre
    • Variant 1: bounds check bypass (CVE-2017-5753)
    • Variant 2: branch target injection (CVE-2017-5715)
  • Meltdown: Variant 3: rogue data cache load (CVE-2017-5754)

màj de microcode Intel

• https://www.heise.de/newsticker/meldung/Meltdown-und-Spectre-Intel-patcht-ab-2013-produzierte-Prozessoren-bestaetigt-Performance-Auswirkung-3936956.html
• https://www.bleepingcomputer.com/news/security/intel-releases-linux-cpu-microcodes-to-fix-meltdown-and-spectre-bugs/

analogie avec une bibliothèque de l'attaque Meltdown

• https://news.ycombinator.com/item?id=16065845

• outils pour développeurs Debian pour renforcer la protection: https://wiki.debian.org/Hardening

• http://kroah.com/log/blog/2018/01/19/meltdown-status-2/

infos des distributions

• https://wiki.debian.org/LTS/Wheezy/SpectreMeltdown (Debian LTS)
• https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown (Ubuntu)

-- MarcSCHAEFER - 05 Jan 2018