sandsifter

s a n d s i f t e r

: le fuzzer de processeur x86

Aperçu

Le sandsifter audite les processeurs x86 pour détecter des instructions cachées et des 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 pour détecter des anomalies. Sandsifter a découvert des instructions secrètes de processeur de tous les grands fabricants ; des bugs logiciels omniprésents dans les désassembleurs, assembleurs et émulateurs ; des failles dans les hyperviseurs d'entreprise ; et à la fois des bugs matériels 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 pour des instructions cachées et des 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 scanné à 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 rapporte les anomalies qu'il trouve.

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

./summarize.py data/log

En règle générale, plusieurs millions d'instructions non documentées seront trouvées sur votre processeur, mais elles se répartissent généralement en un petit nombre de groupes différents. Après avoir regroupé les anomalies, l'outil de résumé 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 CPU), 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 du scan système :

Les résultats d'un scan 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 (depuis /proc/cpuinfo) n'est incluse dans ce journal.

Résultats

Le scan avec le sandsifter a révélé des fonctionnalités de 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 grands outils de désassemblage et d'émulation, et 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 peuvent être trouvés dans le livre blanc du projet.

(TODO: detailed results enumeration here)

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

et est ensuite exécuté avec

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

Drapeaux

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

Exemple :

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

Drapeaux 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 quand 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 actuelle 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 recherche sur le disque au fur et à mesure qu'ils sont trouvés

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

Drapeaux de l'injecteur :

-b
	mode : force brute

-r
	mode : fuzzing aléatoire

-t
	mode : fuzzing tunnelisé

-d
	mode : fuzzing dirigé externe

-R
	mode de sortie brute

-T
	mode de sortie texte

-x
	écrit la progression périodique sur stderr

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

-D
	autoriser les préfixes en double

-N
	pas de support du bit NX

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

-B brute_depth
	dans la recherche par force brute, profondeur maximale de recherche

-P max_prefix
	nombre maximum de préfixes à rechercher

-i instruction
	instruction à laquelle commencer la recherche (inclus)

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

-c core
	cœur sur lequel effectuer la recherche

-X blacklist
	mettre 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-gamme

Touches

m : Mode - changer le mode de recherche (force brute, aléatoire ou tunnelisé) pour le sifter

q : Quitter - sortir du sifter

p : Pause - mettre en pause ou reprendre la recherche

Algorithmes

Le scan supporte quatre algorithmes de recherche différents, qui peuvent être définis en ligne de commande ou parcourus via des touches de raccourci.

• 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émentielle, 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 de plus en plus complexes via des algorithmes génétiques ; bien que prometteuse, cette approche n'a jamais été pleinement réalisée et est laissée comme une ébauche pour des recherches futures.
• Le tunnelisé est l'approche décrite dans la présentation et le livre blanc, et dans presque tous les cas offre 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 permissions root. Cette page empêche de nombreuses instructions de faire un segfault lors des accès mémoire, ce qui permet une analyse des défauts plus précise.

• Préfixes

  La principale limitation pour 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 le drapeau -P.

• Couleurs

  L'interface du sifter est conçue pour un terminal 256 couleurs. Bien que les détails varient grandement selon votre terminal, cela peut être approximativement accompli 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'augmenter la taille du terminal ; cela peut souvent être accompli 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 l'injecteur directement :

  root@kitploit:~

  sudo ./injector -P1 -t -0
  

  Pour filtrer les résultats d'un appel direct 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 étaient en désaccord sur la longueur de l'instruction (grep '.r'), mais 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 a des défauts 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 drapeaux -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 sur les techniques et les résultats peut être trouvée dans la présentation de 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 effort de recherche de Christopher Domas (@xoreaxeaxeax).