isec-tugraz/meltdownDémos de preuve de concept et bibliothèque libkdump illustrant l'attaque microarchitecturale Meltdown, permettant la fuite de la mémoire du noyau et de la mémoire physique sur les CPU Intel vulnérables.
Ce dépôt contient plusieurs applications démontrant la faille Meltdown. Pour des informations techniques sur la faille, consultez l'article :
Les applications de ce dépôt sont construites avec libkdump, une bibliothèque que nous avons développée pour l'article. Cette bibliothèque simplifie l'exploitation de la faille en s'adaptant automatiquement à certaines propriétés de l'environnement.
Ce dépôt contient plusieurs vidéos démontrant Meltdown
Ce dépôt contient cinq démos illustrant différents cas d'usage. Toutes les démos sont testées sur Ubuntu 16.04 avec un Intel Core i7-6700K, mais elles devraient fonctionner sur tout système Linux avec n'importe quel CPU Intel moderne depuis 2010.
Pour de meilleurs résultats, nous recommandons un CPU rapide prenant en charge Intel TSX (par exemple, tout Intel Core i7-5xxx, i7-6xxx ou i7-7xxx). De plus, chaque démo devrait être épinglée à un seul cœur CPU, par exemple avec taskset.
Comme prérequis, vous devez installer glibc-static sur votre machine.
Pour les systèmes basés sur RPM :
sudo yum install -y glibc-static
test)C'est la démo la plus basique. Elle utilise Meltdown pour lire des adresses accessibles depuis son propre espace d'adressage, sans briser aucun mécanisme d'isolation.
Si cette démo ne fonctionne pas pour vous, les démos restantes ne fonctionneront très probablement pas non plus. Les raisons sont multiples, par exemple, le CPU pourrait être trop lent, ne pas prendre en charge l'exécution dans le désordre, la minuterie haute résolution n'est pas suffisamment précise (surtout dans les VM), le système d'exploitation ne prend pas en charge les gestionnaires de signaux personnalisés, etc.
make
taskset 0x1 ./test
Si vous voyez une sortie similaire à ceci
Expect: Welcome to the wonderful world of microarchitectural attacks
Got: Welcome to the wonderful world of microarchitectural attacks
alors la démo de base fonctionne.
kaslr)À partir du noyau Linux 4.12, le KASLR (Kernel Address Space Layout Randomizaton) est actif par défaut. Cela signifie que l'emplacement du noyau (ainsi que la carte physique directe qui mappe toute la mémoire physique) change à chaque redémarrage.
Cette démo utilise Meltdown pour divulguer la randomisation (secrète) de la carte physique directe. Cette démo nécessite les privilèges root pour accélérer le processus. L'article décrit une variante qui ne nécessite pas les privilèges root.
make
sudo taskset 0x1 ./kaslr
Après quelques secondes, vous devriez voir quelque chose de similaire à ceci
[+] Direct physical map offset: 0xffff880000000000
reliability)Cette démo teste la fiabilité avec laquelle la mémoire physique peut être lue. Pour cette démo, vous avez soit besoin de l'offset de la carte physique directe (par exemple à partir de la démo #2), soit vous devez désactiver le KASLR en spécifiant nokaslr dans votre ligne de commande du noyau.
Compilez et lancez reliability. Si vous avez le KASLR activé, le premier paramètre est l'offset de la carte physique directe. Sinon, le programme ne nécessite aucun paramètre.
make
sudo taskset 0x1 ./reliability 0xffff880000000000
Après quelques secondes, vous devriez obtenir une sortie similaire à ceci :
[-] Success rate: 99.93% (read 1354 values)
physical_reader)Cette démo lit la mémoire d'un autre processus en lisant directement la mémoire physique. Pour cette démo, vous avez soit besoin de l'offset de la carte physique directe (par exemple à partir de la démo #2), soit vous devez désactiver le KASLR en spécifiant nokaslr dans votre ligne de commande du noyau.
En principe, ce programme peut lire des adresses physiques arbitraires. Cependant, comme la mémoire physique contient beaucoup de données non lisibles par l'humain, nous fournissons un outil de test (secret), qui place une chaîne lisible par l'humain en mémoire et fournit directement l'adresse physique de cette chaîne.
Pour la démo, exécutez d'abord secret (en tant que root) pour obtenir l'adresse physique d'une chaîne lisible par l'humain :
make
sudo ./secret
Il devrait afficher quelque chose comme ceci :
[+] Secret: If you can read this, this is really bad
[+] Physical address of secret: 0x390fff400
[+] Exit with Ctrl+C if you are done reading the secret
Pendant que le programme secret s'exécute, lancez physical_reader. Le premier paramètre est l'adresse physique affichée par secret. Si vous n'avez pas désactivé le KASLR, le second paramètre est l'offset de la carte physique directe.
taskset 0x1 ./physical_reader 0x390fff400 0xffff880000000000
Après quelques secondes, vous devriez obtenir une sortie similaire à ceci :
[+] Physical address : 0x390fff400
[+] Physical offset : 0xffff880000000000
[+] Reading virtual address: 0xffff880390fff400
If you can read this, this is really bad
memdump)Cette démo vide le contenu de la mémoire. Comme les démos #3 et #4, elle utilise la carte physique directe pour vider le contenu de la mémoire physique dans un format de type hexdump.
Là encore, comme la mémoire physique contient beaucoup de contenu non lisible par l'humain, nous fournissons un outil de test pour remplir de grandes quantités de mémoire physique avec des chaînes lisibles par l'humain.
Pour la démo, exécutez d'abord memory_filler pour remplir la mémoire avec des chaînes lisibles par l'humain. Le premier argument est la quantité de mémoire (en gigaoctets) à remplir.
make
./memory_filler 9
Ensuite, exécutez l'outil memdump pour vider le contenu de la mémoire. Si vous avez exécuté memory_filler auparavant, vous devriez voir quelques fragments de chaînes.
Si vous avez Firefox ou Chrome avec plusieurs onglets ouverts, vous pourriez également voir des parties des sites web qui sont ouverts ou qui ont été récemment fermés.
Le premier paramètre est l'adresse physique à laquelle le vidage doit commencer (laissez vide pour commencer au premier gigaoctet). Le second paramètre est le nombre d'octets que vous souhaitez lire ; pour tout lire, indiquez -1. Si vous n'avez pas désactivé le KASLR, le troisième paramètre est l'offset de la carte physique directe.
taskset 0x1 ./memdump 0x240000000 -1 0xffff880000000000 # start at 9 GB
Vous devriez obtenir un hexdump de parties de la mémoire (contenant potentiellement même des secrets tels que des mots de passe, voir l'exemple dans l'article), par exemple :