sandsifter

s a n d s i f t e r

: le fuzzer de processeurs x86

Aperçu

Le sandsifter audite les processeurs x86 à la recherche d'instructions cachées et de bugs matériels, en générant systématiquement du code machine pour parcourir le jeu d'instructions d'un processeur, et en surveillant l'exécution à la recherche d'anomalies. Sandsifter a révélé des instructions processeur secrètes chez tous les grands fabricants ; des bugs logiciels omniprésents dans les désassembleurs, assembleurs et émulateurs ; des failles dans les hyperviseurs d'entreprise ; ainsi que des bugs matériels à la fois bénins et critiques pour la sécurité dans les puces x86.

Avec la multitude de processeurs x86 existants, l'objectif de l'outil est de permettre aux utilisateurs de vérifier leurs propres systèmes à la recherche d'instructions cachées et de bugs.

Pour exécuter un audit de base sur votre processeur :

sudo ./sifter.py --unk --dis --len --sync --tick -- -P1 -t

L'ordinateur est systématiquement analysé à la recherche d'instructions anormales. Dans la moitié supérieure, vous pouvez voir les instructions que le sandsifter teste actuellement sur le processeur. Dans la moitié inférieure, le sandsifter signale les anomalies qu'il trouve.

La recherche prendra de quelques heures à quelques jours, selon la vitesse et la complexité de votre processeur. Lorsqu'elle est terminée, résumez les résultats :

./summarize.py data/log

En général, plusieurs millions d'instructions non documentées seront trouvées sur votre processeur, mais celles-ci se répartissent généralement en un petit nombre de groupes différents. Après avoir regroupé les anomalies, l'outil summarize tente d'attribuer chaque instruction à une catégorie de problème :

• Bug logiciel (par exemple, un bug dans votre hyperviseur ou désassembleur),
• Bug matériel (un bug dans votre processeur), ou
• Instruction non documentée (une instruction qui existe dans le processeur, mais qui n'est pas reconnue par le fabricant)

Appuyez sur « Q » pour quitter et obtenir un résumé textuel de l'analyse du système :

Les résultats d'une analyse peuvent parfois être difficiles à classer automatiquement par les outils, et peuvent nécessiter une analyse manuelle. Pour obtenir de l'aide pour analyser vos résultats, n'hésitez pas à envoyer le fichier ./data/log à [email protected]. Aucune information personnelle, autre que la marque, le modèle et la révision du processeur (à partir de /proc/cpuinfo), n'est incluse dans ce journal.

Résultats

L'analyse avec le sandsifter a révélé des fonctionnalités processeur non documentées dans des dizaines de catégories d'opcodes, des failles dans les hyperviseurs d'entreprise, des bugs dans presque tous les principaux outils de désassemblage et d'émulation, ainsi que des bugs matériels critiques ouvrant des vulnérabilités de sécurité dans le processeur lui-même.

Les détails des résultats se trouvent dans le livre blanc du projet.

(TODO : énumération détaillée des résultats ici)

Compilation

Sandsifter nécessite d'abord l'installation du désassembleur Capstone : http://www.capstone-engine.org/. Capstone peut généralement être installé avec :

sudo apt-get install libcapstone3 libcapstone-dev
sudo pip install capstone

Sandsifter peut être compilé avec :

make

puis est exécuté avec :

sudo ./sifter.py --unk --dis --len --sync --tick -- -P1 -t

Options

Les options sont passées au sifter avec --flag, et à l'injecteur avec -- -f.

Exemple :

sudo ./sifter.py --unk --dis --len --sync --tick -- -P1 -t

Options du sifter :

--len
	recherche les différences de longueur dans toutes les instructions (instructions qui
	se sont exécutées différemment de ce que le désassembleur attendait, ou qui
	n'existaient pas alors que le désassembleur les attendait

--dis
	recherche les différences de longueur dans les instructions valides (instructions qui
	se sont exécutées différemment de ce que le désassembleur attendait)

--unk
	recherche les instructions inconnues (instructions que le désassembleur ne
	connaît pas mais qui s'exécutent avec succès)

--ill
	l'inverse de --unk, recherche les désassemblages invalides (instructions qui ne
	s'exécutent pas avec succès mais que le désassembleur reconnaît)

--tick
	écrit périodiquement l'instruction courante sur le disque

--save
	sauvegarde la progression de la recherche à la sortie

--resume
	reprend la recherche à partir du dernier état sauvegardé

--sync
	écrit les résultats de la recherche sur le disque au fur et à mesure qu'ils sont trouvés

--low-mem
	ne stocke pas les résultats en mémoire

Options de l'injecteur :

-b
	mode : force brute

-r
	mode : fuzzing aléatoire

-t
	mode : fuzzing tunnelisé

-d
	mode : fuzzing dirigé en externe

-R
	mode de sortie brute

-T
	mode de sortie texte

-x
	écrit la progression périodique sur stderr

-0
	autorise la déréférence nulle (nécessite sudo)

-D
	autorise les préfixes en double

-N
	pas de prise en charge du bit NX

-s seed
	en recherche aléatoire, valeur de la graine

-B brute_depth
	en recherche par force brute, profondeur de recherche maximale

-P max_prefix
	nombre maximal de préfixes à rechercher

-i instruction
	instruction à partir de laquelle démarrer la recherche (incluse)

-e instruction
	instruction à laquelle terminer la recherche (exclue)

-c core
	cœur sur lequel effectuer la recherche

-X blacklist
	met sur liste noire l'instruction spécifiée

-j jobs
	nombre de tâches simultanées à exécuter

-l range_bytes
	nombre d'octets d'instruction de base dans chaque sous-plage

Touches

m: Mode - change le mode de recherche (force brute, aléatoire ou tunnel) du sifter

q: Quitter - quitte le sifter

p: Pause - met en pause ou reprend la recherche

Algorithmes

L'analyse prend en charge quatre algorithmes de recherche différents, qui peuvent être définis en ligne de commande ou parcourus via des raccourcis clavier.

• La recherche aléatoire génère des instructions aléatoires à tester ; elle produit généralement des résultats rapidement, mais est incapable de trouver des instructions cachées complexes et des bugs.
• La recherche par force brute essaie les instructions de manière incrémentale, jusqu'à une longueur spécifiée par l'utilisateur ; dans presque toutes les situations, elle est moins performante que la recherche aléatoire.
• La recherche dirigée ou par mutation est conçue pour créer de nouvelles instructions toujours plus complexes grâce à des algorithmes génétiques ; bien que prometteuse, cette approche n'a jamais été entièrement réalisée, et reste une ébauche pour de futures recherches.
• Tunneling est l'approche décrite dans la présentation et le livre blanc, et offre dans presque tous les cas le meilleur compromis entre exhaustivité et rapidité.

Conseils

• sudo

  Pour de meilleurs résultats, l'outil doit être exécuté en tant qu'utilisateur root. Cela est nécessaire pour que le processus puisse mapper en mémoire une page à l'adresse 0, ce qui nécessite des privilèges root. Cette page empêche de nombreuses instructions de provoquer des erreurs de segmentation lors des accès mémoire, ce qui permet une analyse des défauts plus précise.

• Préfixes

  La principale limitation de la profondeur d'une recherche d'instructions est le nombre d'octets de préfixe à explorer, chaque octet de préfixe supplémentaire augmentant l'espace de recherche d'un facteur d'environ 10. Limitez les octets de préfixe avec l'option -P.

• Couleurs

  L'interface du sifter est conçue pour un terminal 256 couleurs. Bien que les détails varient considérablement selon votre terminal, cela peut être grossièrement réalisé avec :

  root@kitploit:~

  export TERM='xterm-256color'
  

• Interface graphique

  L'interface suppose que le terminal a au moins une certaine taille ; si l'interface ne s'affiche pas correctement, essayez d'agrandir la taille du terminal ; cela peut souvent être réalisé en diminuant la taille de la police du terminal.

  Dans certains cas, il peut être souhaitable ou nécessaire d'exécuter l'outil sans l'interface graphique. Cela peut être fait en exécutant directement l'injecteur :

  root@kitploit:~

  sudo ./injector -P1 -t -0
  

  Pour filtrer les résultats d'une invocation directe de l'injecteur, grep peut être utilisé. Par exemple,

  root@kitploit:~

  sudo ./injector -P1 -r -0 | grep '\.r' | grep -v sigill
  

  recherche les instructions pour lesquelles le processeur et le désassembleur n'étaient pas d'accord sur la longueur de l'instruction (grep '.r'), mais où l'instruction s'est exécutée avec succès (grep -v sigill).

• Fuzzing ciblé

  Dans de nombreux cas, il est utile de diriger le fuzzer vers une cible spécifique. Par exemple, si vous soupçonnez qu'un émulateur présente des failles autour des préfixes 'lock' répétés (0xf0), vous pouvez diriger le fuzzer pour rechercher cette région de l'espace d'instructions avec les options -i et -e :

  root@kitploit:~

  sudo ./sifter.py --unk --dis --len --sync --tick -- -t -i f0f0 -e f0f1 -D -P15
  

Références

• Une discussion des techniques et des résultats est disponible dans la présentation Black Hat.
• Les détails techniques sont décrits dans le livre blanc.
• Les diapositives de la présentation Black Hat sont ici.

Auteur

sandsifter est un projet de recherche de Christopher Domas (@xoreaxeaxeax).