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 :
240001c9f: | 00 6d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | .m.............. |
24000262f: | 00 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | .}.............. |
24000271f: | 00 00 00 00 00 00 00 00 00 00 00 00 65 6e 20 75 | ............en u |
24000272f: | 73 65 72 20 73 70 61 63 65 20 61 6e 64 20 6b 65 | ser space and ke |
24000273f: | 72 6e 65 6c 57 65 6c 63 6f 6d 65 20 74 6f 20 74 | rnelWelcome to t |
24000298f: | 00 61 72 79 20 62 65 74 77 65 65 6e 20 75 73 65 | .ary between use |
24000299f: | 72 20 73 70 61 63 65 20 61 6e 64 20 6b 65 72 6e | r space and kern |
2400029af: | 65 6c 42 75 72 6e 20 61 66 74 65 72 20 72 65 61 | elBurn after rea |
2400029bf: | 64 69 6e 67 20 74 68 69 73 20 73 74 72 69 6e 67 | ding this string |
240002dcf: | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c8 | ................ |
2400038af: | 6a 75 73 74 20 73 70 69 65 64 20 6f 6e 20 61 00 | just spied on a. |
240003c8f: | 00 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ |
24000412f: | 00 00 00 00 00 00 00 00 00 00 00 00 65 74 73 2e | ............ets. |
24000413f: | 2e 2e 57 65 6c 63 6f 6d 65 20 74 6f 20 74 68 65 | ..Welcome to the |
2400042ff: | 00 00 00 00 00 00 00 00 00 6e 67 72 61 74 75 6c | .........ngratul |
24000430f: | 61 74 69 6f 6e 73 2c 20 79 6f 75 20 6a 75 73 74 | ations, you just |
24000431f: | 20 73 70 69 65 64 20 6f 6e 20 61 6e 20 61 70 70 | spied on an app |
Est-ce que cela fonctionne sous Windows / Ubuntu on Windows (WSL) / Mac OS ?
Non. Ce PoC ne fonctionne que sous Linux, car il utilise des propriétés spécifiques au noyau Linux, telles que la carte physique directe.
Puis-je exécuter le PoC dans une machine virtuelle ?
Oui, le PoC fonctionne également sur des machines virtuelles. Cependant, en raison de la couche supplémentaire introduite par une machine virtuelle, il pourrait ne pas fonctionner aussi bien que sur du matériel natif.
Le programme KASLR (kaslr) ne trouve pas l'offset !
L'outil kaslr ne fait que très peu de mesures pour être rapide. S'il ne trouve pas l'offset, il y a deux possibilités :
kaslr.c : config.retries = 1000;kaslr_offset pour lire directement l'offset depuis le noyau. Installez les en-têtes du noyau pour votre noyau (sudo apt-get install linux-headers-`uname -r` ) et exécutez sudo ./direct_physical_map.shVous avez dit que cela fonctionne sur de la mémoire non mise en cache, mais toutes vos démos s'assurent que la mémoire est mise en cache !
Le faire fonctionner sur de la mémoire non mise en cache est plus délicat et nécessite souvent quelques ajustements des paramètres. Ainsi, nous nous assurons que la mémoire est mise en cache dans le PoC pour faciliter la reproduction. Cependant, vous pouvez simplement supprimer le code qui met les valeurs en cache et le remplacer par un pour tester l'exploit sur de la mémoire non mise en cache (voir la Vidéo #5 pour un exemple). Bien que cela ne figure pas dans l'article de blog original de Google, cela a également été confirmé par des chercheurs indépendants (par exemple , , ).
Avertissement #1 : Nous fournissons ce code tel quel. Il est de votre responsabilité de vous protéger, ainsi que vos biens et données, et les autres, contre tout risque causé par ce code. Ce code peut provoquer un comportement inattendu et indésirable sur votre machine. Ce code peut ne pas détecter la vulnérabilité sur votre machine.
Avertissement #2 : Si vous constatez qu'un ordinateur est sensible à la faille Meltdown, vous voudrez peut-être éviter de l'utiliser comme système multi-utilisateur. Meltdown brise la protection mémoire du CPU. Sur une machine sensible à la faille Meltdown, un processus peut lire toutes les pages utilisées par d'autres processus ou par le noyau.
Avertissement #3 : Ce code est uniquement à des fins de test. Ne l'exécutez sur aucun système de production. Ne l'exécutez sur aucun système susceptible d'être utilisé par une autre personne ou entité.
clflushCela ne fonctionne tout simplement pas sur mon ordinateur, que puis-je faire ?
Il peut y avoir de nombreuses raisons différentes à cela. Nous avons rassemblé quelques choses que vous pouvez essayer :
libkdump/libkdump.c à la ligne #define MELTDOWN meltdown_nonull. Essayez par exemple meltdown au lieu de meltdown_nonull, ce qui fonctionne beaucoup mieux sur certaines machines (mais pas du tout sur d'autres).stress avec stress -i 2 (ou d'autres valeurs pour le paramètre i, selon le nombre de cœurs).