SUTURE

SUTURE

La suture est un outil d'analyse de souillure de points à haut niveau statique (pour C) basé sur LLVM IR et construit sur le Dr Checker (merci beaucoup à ses créateurs!), Deux faits saillants sont:

• Haute précision : multiples améliorations de précision pratiques et / ou innovantes emballées, la suture est interproceuse, flux, contex, champ, index et opportuniste sensible aux chemins, avec une construction SSA à la mémoire à la volée, une combinaison multi-surseage multi-sources, une gestion arithmétique de pointes et des crieurs de linux.
• Ordre élevé : SUTURE est capable de construire des flux de souche de haut niveau et de découvrir des vulnérabilités de souillure de haut niveau (par exemple, l'entrée de l'utilisateur passe à une variable globale dans l'invocation du 1er système, puis la variable globale s'écoule vers une instruction sensible dans l'invocation du 2e système, faisant une vulnérabilité de tentative du 2e système).

Nous le nommons suture dans l'espoir qu'il peut être précis sur le plan chirurgicalement, tout en étant en mesure de coudre plusieurs systèmes / fonctions d'entrée pour construire des flux de données d'ordre élevé. Pour plus de détails, veuillez vous référer à notre article: Découvrant statiquement les vulnérabilités de style de souillure de haut niveau dans les noyaux OS dans ACM CCS'21 .

0x0 Configuration

Premier cloner le repo:
~$ git clone https://github.com/seclab-ucr/SUTURE.git suture

Puis configurez l'environnement LLVM pour la suture:
~$ cd suture
~/suture$ python setup_suture.py -o ../suture_deps
Options (pour setup_suture.py ):

• -b Spécifie le nom de branche de LLVM à configurer pour SUture, il est par défaut "release_90" (c'est-à-dire LLVM 9.0) dans ce repos miroir llvm.
• -o Spécifie le dossier pour héberger toutes les choses requises par Suture (par exemple, LLVM), utilisez n'importe quel dossier que vous préférez.

Selon votre matériel, la configuration LLVM peut prendre un certain temps. Une fois la fin, un fichier SRCIPT nommé env.sh sera généré sous le dossier racine de suture, il contient des commandes pour définir les variables d'environnement utilisées par suture.
IMPORTANT : Assurez-vous d'activer ce env.sh à chaque fois avant de construire / utiliser une suture (vous pouvez également ajouter ses commandes contenues à .Bashrc pour l'activation automatique lors de la connexion de la coquille)!
~/suture$ source env.sh

Ensuite, nous allons construire une suture:
~/suture$ cd llvm_analysis
~/suture/llvm_analysis$ ./build.sh
Sur une construction réussie, la suture est prête à l'emploi.

0x1 Découverte de vulnérabilité avec exemple

La suture peut être utilisée pour découvrir les vulnérabilités de souillure de haut niveau, dans cette section, nous parcourons ce processus avec exemple (par exemple, l'exemple de motivation comme indiqué dans la section 2.1 dans notre article).

0x10 Préparez l'entrée

Pour découvrir que la suture des vulnérabilités nécessite deux types d'entrée: (1) un module de programme compilé sur LLVM Bitcode (par exemple, un fichier .bc ), et (2) un fichier de configuration pour le module qui manifeste ses fonctions d'entrée et ses arguments contrôlés par l'utilisateur.

Préplions d'abord le Bitcode LLVM pour notre exemple de motivation:
~/suture$ cd benchmark
~/suture/benchmark$ ./gen.sh motivating_example
Remarque : Pour plus de commodité, nous fournissons gen.sh pour compiler A .C à .BC et .LL (Bitcode Bitcode LLVM lisible par l'homme), avec le niveau d'optimisation -O1 .
Maintenant, nous devrions avoir le motivation_example.bc dans le même dossier de référence , c'est le module de programme d'entrée pour suture.

Ensuite, il arrive dans le fichier de configuration, nous en avons déjà préparé un pour l'exemple de motivation:

 ~/suture/benchmark$ cat conf_motivating_example  
entry0 MY_IOCTL 1  
entry1 NULL_ARG  
entry2 NULL_ARG  

Explication : Chaque ligne du fichier de configuration décrit les informations d'une fonction d'entrée (par exemple, la fonction de niveau supérieur sans appelants et sert généralement d'interface externe) dans le module de programme, il contient jusqu'à 3 jetons séparés dans l'espace:

• [func_name] Le nom de la fonction d'entrée (par exemple, "Entry0" est une fonction d'entrée dans motiving_example.c )
• [Func_Type] Le type de fonction de saisie, nous utilisons souvent deux types: (1) null_arg signifie aucun paramètre de fonction n'est contrôlable par l'utilisateur, et (2) My_ioctl signifie par défaut que le dernier paramètre est controllable par l'utilisateur (par exemple, pour correspondre aux sémantiques habituelles des fonctions IOCTL () de dispositifs Linux). Cependant, les paramètres User_Controllables de MY_IOCTL peuvent également être spécifiés arbitrairement par des arguments supplémentaires (voir ci-dessous).
• [Additional_args] Pour l'instant, seul my_ioctl accepte un argument supplémentaire, dans la forme de d + (_ d +) *, spécifiant quels paramètres de fonction sont contrôlables par l'utilisateur. Une fois fourni, cet argument remplacera le comportement par défaut de MY_IOCTL (c'est-à-dire, le dernier paramètre est contrôlé par l'utilisateur). Par exemple, si Entry_X () a 4 paramètres (de gauche à droite: paramètre 0, 1, 2 et 3) et les paramètres 0 et 2 sont fournis par l'utilisateur, nous pouvons le spécifier dans la configuration comme entry_x MY_IOCTL 0_2 .

Donc, comme indiqué ci-dessus, conf_motivating_example spécifie qu'il existe trois fonctions d'entrée dans motiving_example.c : entrée (Paramètre 1 est contrôlée par l'utilisateur), Entry1 et Entry2 (aucun paramètre contrôlé par l'utilisateur). Cela correspond au code de l'exemple de motivation.

0x11 Exécutez l'analyse

Une fois que le Bitcode du programme et le fichier de configuration d'entrée sont prêts, nous pouvons exécuter la suture pour découvrir les vulnérabilités de souillure:
~/suture$ ./run_nohup.sh benchmark/motivating_example.bc benchmark/conf_motivating_example
Explication : run_nohup.sh est un script simple invoquant les passes d'analyse LLVM compilées de suture:

 ~/suture$ ./run_nohup.sh [path/to/program.bc] [path/to/entry_func_config]

Une fois commencé, selon le matériel réel et la complexité du programme cible, le temps requis pour la suture pour terminer l'analyse et la découverte de vulnérabilité varie beaucoup. Un programme simple comme notre exemple de motivation se termine généralement instantanément, cependant.
Décidez si l'analyse se termine : lors de l'exécution, SUTURE continue de se connecter à un fichier sous le même répertoire du fichier de configuration de la saisie , supposons que le chemin du fichier de configuration soit / path / vers / conf_program , le fichier journal sera /path/to/conf_program.log . Nous pouvons décider si l'analyse se termine en surveillant le journal:
~/suture$ grep "Bug Detection Phase finished" benchmark/conf_motivating_example.log

0x12 Inspectez la sortie

Le fichier journal susmentionné est également la sortie de Suture, Suture intégrera ses vulnérabilités potentielles découvertes dans le fichier journal, qui peut être extraite et organisée dans un rapport d'avertissement final une fois l'analyse terminée:
~/suture$ ./ext_warns.sh benchmark/conf_motivating_example.log
Explication : EXT_WARNS.SH extrait tous les avertissements (en JSON) intégrés dans le fichier journal donné, les réorganiser et les imprimer dans les rapports d'avertissement finaux. Les rapports d'avertissement seront placés dans un dossier sous le même chemin du fichier journal, supposons que le fichier journal soit /path/to/conf_program.log , le dossier du rapport d'avertissement sera / path / to / warns-conf_program-yyyy-mm-dd .

 ~/suture$ ls benchmark/warns-conf_motivating_example-2021-11-10/
all  int_overflow  taint_data_use  taint_loopbound  taint_ptr_def

Dans le dossier, il y a 5 rapports d'avertissement, tous contient tous les types d'avertissements regroupés en fonction de leur relation de flux de données, tandis que d'autres rapports ne contiennent que des types d'avertissements spécifiques (par exemple, le débordement entier, la déréférence du pointeur contaminé, etc.), plus de détails sur la façon dont nous regroupons des avertissements dans notre article (section 4). Nous n'utilisons généralement que le rapport unifié .

 ~/suture$ cat -n benchmark/warns-conf_motivating_example-2021-11-10/all
     1  =========================GROUP 0 (2 - 2)=========================
     2  #####Warned Insts#####
     3  (u'motivating_example.c', 30, [u'IntegerOverflowDetector'])
     4  ######################
     5
     6  ++++++++++++++++WARN 0 (2 - 2)++++++++++++++++
     7  IntegerOverflowDetector says: motivating_example.c@30 (bar :   %add = add i8 %0, -16, !dbg !31)
     8  ********Trace 0(2)********
     9  #####CTX##### entry0
    10  entry0 (motivating_example.c@18)
    11  #####INSTS#####
    12  >>>>>>>>>>>>>>>>>>tag: 0x55b206570420 tf: 0x55b20695b1b0 (2)>>>>>>>>>>>>>>>>>>
    13  motivating_example.c@18 (  %cond = icmp eq i32 %cmd, 0, !dbg !31)
    14  motivating_example.c@21 (  store i8 %user_input, i8* getelementptr inbounds (%struct.data, %struct.data* @d, i64 0, i32 1, i64 0), align 4, !dbg !32, !tbaa !34)
    15  #####CTX##### entry1 -> bar
    16  entry1 (motivating_example.c@35)
    17  ----> (motivating_example.c@35 :   %call = tail call i32 @bar(i8* bitcast (%struct.data* @d to i8*)), !dbg !27)
    18  bar (motivating_example.c@30)
    19  #####INSTS#####
    20  >>>>>>>>>>>>>>>>>>tag: 0x55b2065e7050 tf: 0x55b2068174f0 (1)>>>>>>>>>>>>>>>>>>
    21  motivating_example.c@30 (  %0 = load i8, i8* %add.ptr, align 1, !dbg !31, !tbaa !32)
    22  motivating_example.c@30 (  %add = add i8 %0, -16, !dbg !31)
    23

Explication : À un niveau élevé, le rapport d'avertissement contient certains groupes d'avertissement, chaque groupe contient plusieurs avertissements et chaque avertissement contient plusieurs traces de souillure provenant d'une entrée et d'un puits d'utilisateur à une même déclaration de programme sensible. En d'autres termes, un avertissement est soulevé pour une certaine déclaration de programme et d'un type spécifique (par exemple, un débordement entier), tandis qu'un groupe contient plusieurs avertissements étroitement liés du point de vue du flux de données (voir la section 4 de notre article), donc un groupe peut avoir plusieurs déclarations de programme averties et inclure différents types d'avertissement.

Prenez le rapport d'avertissement ci-dessus comme exemple:

• Ligne 1: La ligne d'en-tête d'un groupe d'avertissement, le format est ===GROUP No. (min_order - max_order)=== , où min_order est l'ordre minimal (par exemple, mettre simplement, l'ordre est le temps des invocations de la fonction d'entrée requises dans la propagation de la souillure, voir la section 3.2 dans notre article pour une définition plus formelle.) Du taint trace dans ce groupe et max_order le max.
• Ligne 2-4: Résumé des déclarations du programme averties et des types d'avertissement de ce groupe.
• Ligne 6: La ligne d'en-tête d'un avertissement, suivant le même format que la ligne d'en-tête de groupe, mais notez que le WARN No. est local à son groupe.
• Ligne 7: L'énoncé du programme averti et le type de cet avertissement (par exemple, ligne 30 dans motiving_example.c ).
• Ligne 8: La ligne d'en-tête d'une trace de souillure de l'avertissement, suivant le format ***Trace No. (order)*** , une trace de souillure a toujours un ordre unique qui peut être calculé (par exemple, pas une plage).
• Ligne 9-22: La déclaration détaillée / séquence d'instructions de cette trace de souillure. La séquence est organisée dans certains segments de contexte consécutifs, par exemple, supposons que nous avons 10 instructions dans la séquence et les 6 premiers d'entre eux se trouvent dans A () , et les 4 restants en b () , qui est une callee de a () . Dans cette situation, nous aurons deux segments de contexte: le premier contient les 6 instructions principales dans le contexte d'appel A () , et le second contient les 4 restants dans le contexte d'appel a () -> b () . Coming back to our motivating example warning report, Line 9-14 is the 1st segment in the trace, where we need to invoke entry0() (Line 10) and walk through two instructions (Line 13-14) in entry0() (so that user_input of entry0() is propagated to the global variable db[0] in motivating_example.c ), then Line 15-22 is the second segment, where we need to invoke entry1() first (Line 16), qui appelle ensuite BAR () (ligne 17), et dans BAR () (ligne 18), nous devons passer par deux instructions de programme (ligne 21-22) pour terminer la propagation de souillure et déclencher la vulnérabilité ( db [0] se propage au site de débordement (1) dans motiving_example.c ). Étant donné que nous avons besoin de deux invocations de la fonction d'entrée (par exemple, première entrée0 () puis entrée1 () ), cette trace de souillure est le 2e ordre.
• Ligne 12, 20: Ces lignes spéciales sont utilisées en interne par nous à des fins de débogage.

Le rapport d'avertissement indique une vulnérabilité de débordement entier valide dans l'exemple de motivation, tout en évitant les fausses alarmes potentielles qu'un outil d'analyse statique moins précis peut générer, des détails peuvent être trouvés dans la section 2.1 de notre article.

0x2 Autres services publics utiles

Ce dépôt contient également d'autres outils / scripts que vous pouvez trouver utiles.

Identificateur 0x20 Point de saisie (pour les pilotes de périphérique Linux)

~/suture$ python llvm_analysis/AnalysisHelpers/EntryPointIdentifier/entry_point_identifier.py /path/to/prog_module.bc
~/suture$ cat /path/to/prog_module.bc.all_entries
Explication : Ce script peut identifier certaines fonctions d'entrée courantes dans un module de pilote de périphérique Linux (par exemple, ioctl () , read () , write () , etc.), qui aide la construction du fichier de configuration d'entrée comme entrée à suture. Cet utilitaire est principalement mis en œuvre par le Dr Checker d'origine sur la base de certaines connaissances du domaine du noyau (par exemple, des structures de données spécifiques comme File_Operations utilisées pour définir les points d'entrée du pilote), nous avons ensuite apporté quelques améliorations (par exemple, rendre l'heuristique plus robuste).

0x21 Falle d'alarme Filtre

~/suture$ python flt_warns.py /path/to/warn_report [Regex] > /path/to/filtered_warn_report
Explication : D'après notre expérience, de nombreuses fausses alarmes dans le rapport d'avertissement partagent souvent une même sous-forme problématique (voir la section 6.3 dans notre article). Tant que le réviseur d'avertissement inspecte une fausse alarme et reconnaît le sous-trace induisant FP, naturellement, elle peut essayer d'exclure automatiquement toutes les autres fausses alarmes similaires contenant le même sous-trace, réduisant le taux de fausses alarmes perçu par le critique. À cette fin, nous fournissons ce simple FLT_WARNS.PY qui prend le rapport d'avertissement d'origine et une expression régulière Python en entrées, il correspondra ensuite à chaque trace de souillure du rapport, une fois apparié, la trace de souillure sera traitée comme une fausse alarme. Le script générera un nouveau rapport d'avertissement filtré à l'exclusion de toutes les traces de souillure correspondantes.

0x3 Questions et réponses possibles

0x30 Utiliser la suture comme analyse statique à usage général?

Vous pourriez être intéressé à utiliser la suture comme analyse statique à usage général (par exemple, obtenir l'ensemble de points à souillure d'une variable à un certain emplacement du programme), cela est certainement faisable, mais contrairement à la découverte de vulnérabilité, vous devez vous salir et plonger dans le code de Suture pour être familiarisé avec les principales structures de données qu'il utilise et certaines fonctions importantes. J'espère que les conseils suivants pourront aider:

• [Lire le Dr Dr. Paper d'origine] La suture est basée sur le Dr Checker et hérite de son architecture de haut niveau, des principes de conception et de nombreuses structures de code et de données importantes, pour Brivity, nous omettons des détails sur la conception et la mise en œuvre du Dr Checker dans notre article, mais ils sont très importants pour comprendre la base de code. Je recommande fortement de lire le Dr. Checker Paper en premier, qui contient ces détails importants.
• [Concentrez-vous sur les fichiers source importants] Tous les enregistrements de points à / souillés des variables LLVM de niveau supérieur se trouvent dans LLVM_ANALYSY / MAINANALYSYPASSES / SOUNDYALALANALYSY / include / moduleState.h , tandis que toutes ces informations pour les objets de mémoire par adresse sont dans llvm_analysis / mainanalysispasses / Soundalanalysysysisysishysis / inclue / ginoBject.h . Je suggère de me concentrer sur ces deux fichiers et les API définies en eux pour récupérer les enregistrements de points à / souillés. Enfin et surtout, le point de début de toutes les passes de l'analyse LLVM de SUture (par exemple, RunonModule () ) est dans LLVM_ANALYSY / MAINANALYSYPASSES / SOUNDYALALALALYSY / SRC / SOUNDEALALASAnalysis.cpp .

0x31 Adapter la suture aux versions LLVM plus récentes?

LLVM évolue très rapidement, sans garantie sur la compatiabilité vers l'arrière. Donc, très probablement, vous rencontrerez des erreurs de compilation lorsque vous essayez de construire une suture avec une version LLVM plus récente (par exemple,> 9.0). Mais heureusement, de telles erreurs de compilation sont généralement faciles à résoudre (par exemple, souvent le cas, nous avons juste besoin de remplacer les API LLVM obsolètes par les plus récentes). Donc, en gros, pour adapter la suture à une version LLVM plus récente, nous devons d'abord configurer un LLVM plus récent dans 0x0 (par exemple, devoir modifier le nom de la branche setup_suture.py pour cloner la suture contre cela, en résolvant les erreurs de compilation décrites.