IMChecker
1.0.0
Jeu, groupe Imchecker, contactez-nous à [email protected]
Les bibliothèques offrent des fonctionnalités réutilisables via des interfaces de programmation d'applications (API) avec des contraintes d'utilisation, telles que les conditions d'appel ou les ordres. Les violations des contraintes, c'est-à-dire les abus d'API, entraînent généralement des bogues et des problèmes de sécurité. Bien que les chercheurs aient développé divers détecteurs API-MISSUSE au cours des dernières décennies, des études récentes montrent que la mauvaise utilisation des API est répandue dans les projets du monde réel. Les approches existantes souffrent soit du problème d'utilisation clairsemée (c'est-à-dire des bogues qui se produisent rarement) ou signalent de fausses alarmes en raison d'une sémantique inexacte. Pour surmonter ces limitations, nous introduisons Imchecker pour détecter efficacement les bogues API-Misusus. L'informatique clé derrière Imchecker est une technique d'analyse statique dirigée par des contraintes propulsée par un langage spécifique au domaine (DSL) pour spécifier les contraintes d'utilisation de l'API. En étudiant les bugs API-Misuson du monde réel, nous proposons IMSpec DSL, qui couvre la majorité des types de contraintes d'utilisation de l'API et permet une spécification simple mais précise. En outre, nous concevons et mettons en œuvre IMCHECKER pour analyser automatiquement IMSPEC en vérifiant les cibles et utiliser un moteur d'analyse statique pour identifier les abus d'API potentiels et tailler les faux positifs avec une sémantique riche. Nous avons instancié Imchecker pour les programmes C et l'évaluez sur des repères largement utilisés et des programmes réels à grande échelle.
Actuellement, 75 bogues précédemment inconnus ont été trouvés et 61 ont été confirmés et corrigées dans le noyau Linux, OpenSSL et packages dans Ubuntu 16.04. Nous faisons de notre mieux pour appliquer Imchecker à plus de programmes. Nous téléchargeons les détails dans Evaluation_Data / New_Bugs
Notre manuscrit de recherche et notre manuscrit d'outils sont en cours d'examen du processus ICSE'19. Nous les téléchargerons dès que le processus d'examen se terminerons. (Eh bien, vous pouvez nous envoyer un e-mail pour y accéder uniquement par objectif académique.)
Notre vidéo de démonstration d'outils est disponible sur la version anglaise: https://youtu.be/ygdxeyoevim Version chinoise: https://www.youtube.com/watch?v=3zanegtwuto https://pan.baidu.com/s/1digq0r6wk5shmlotk9kbg
Utilisation de nos outils chez Tools / Readme.md
Imchecker est toujours en cours de développement et contient beaucoup de bogues et de listes de tâches. Toutes les bogues ou les demandes de fonctionnalités, n'hésitez pas à nous envoyer un e-mail à [email protected] ou à des problèmes ouverts.
Pour mieux comprendre quel type de bogues API-MISUSUS se produit dans des projets C Real et comment les développeurs les réparent dans la pratique, nous avons étudié manuellement deux ans d'histoires de version de trois projets open-source et une demi-année de nage de linux en 2017, comme le montre le tableau suivant. Ces histoires sont choisies en raison du développement en cours et parce qu'elles sont fréquemment mentionnées dans divers travaux de détection de bogues. Au total, nous avons étudié environ 13,57 millions de LOC et 51,1k commits.
| Projet | Localiser | Période étudiée | Total commits | Correctifs de bugs | API AUSUSE |
|---|---|---|---|---|---|
| Boucle | 112.8k | 20160101-20171231 | 2613 | 135 | 38 |
| Gnutls | 35,8k | 20160101-20171231 | 2769 | 86 | 30 |
| OpenSSL | 454.2k | 20160101-20171231 | 6487 | 344 | 115 |
| Linux | 12.96M | 20170701-20171231 | 39295 | 995 | 362 |
| Total | 15,57m | Deux ans | 51.1k | 1560 | 509 |
Pour aider les lecteurs à extraire le message Commits, à des fichiers modifiés et à des fichiers de correctifs, nous ouvrons notre outil Gitgrabber . Nous téléchargeons également tous les engagements liés aux bogues API-Misuse dans les sujets étudiés pour une utilisation ultérieure.
Les lecteurs peuvent les trouver dans le dossier empirical_study. Tout problème sur Gitgrabber, n'hésitez pas à nous contacter!
Nous sélectionnons une référence largement utilisée, IE, Juliet Test Suite v1.3, et deux programmes du monde réel dans leurs dernières versions: Linux Kernel-4.18-RC4 publié le 2018-7-9 et OpenSSL-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-PRE8 publié le 2018-20-20 pour évaluer notre approche. Nous évaluons notre approche sous deux perspectives.
Nous testons également ces cas sur l'outil de détection d'utilisation de l'API APISAN A APIS par un outil de vérification croisée sémantique et un outil d'analyse statique open-source.
Nous téléchargeons les résultats API-Misuse-Benchmark et les résultats originaux sur Evaluation_Data.
La principale motivation d'Imchecker est de détecter les bogues API-Misus dans les programmes du monde réel, à savoir déterminer si Imchecker peut trouver des bugs auparavant inconnus. Par conséquent, nous appliquons Imchecker aux dernières versions de deux programmes open source bien connus: Linux Kernel-4.18-RC4 et OpenSSL-1-1-1-PRE8, et les packages dans Ubuntu 16.04. Les API cibles sont sélectionnées parmi les mal utilisées dans l'étude empirique.
Jusqu'à présent, 56 bogues précédemment inconnus ont été trouvés et 36 ont été confirmés par les développeurs.
| Projet | Bogues (réponse en attente / confirmée / fixe) |
|---|---|
| OpenSSL | 17 (0/5/12) |
| Linux | 30 (5/20/5) |
| DMA | 1 (0/0/1) |
| eximer | 2 (0/0/2) |
| hexchat | 2 (1/1/0) |
| httping | 1 (0/1/0) |
| ipmitool | 1 (0/1/0) |
| outils à aire ouverte | 2 (0/0/2) |
| IRSSI | 2 (1/1/0) |
| keepalive | 2 (0/0/2) |
| THC-IPV6 | 2 (0/0/2) |
| Freeradius-Server | 2 (0/0/2) |
| serveur de trafic | 3 (3/0/0) |
| Tinc | 2 (0/0/2) |
| sslplit | 2 (0/0/2) |
| rdesktop | 2 (2/0/0) |
| proxytunnel | 2 (2/0/0) |
| Total | 75 (16/29/32) |
Nous téléchargeons les détails dans Evaluation_Data / New_Bugs
Les spécifications comportementales décrivant les contraintes d'utilisation de l'API se sont révélées utiles pour que les développeurs utilisent efficacement les API ainsi que pour faire face au problème d'utilisation clairsemée en garantissant la validation des usages des API cibles. Par exemple, Bodden présente Crysl pour combler l'écart cognitif entre les experts en cryptographie et les développeurs. Cependant, les langages de spécification actuels sont conçus soit pour les propriétés complètes du programme, telles que BLAST, JML ou sont trop spécifiques pour être appliquées à la détection générique de l'utilisateur API, telles que SLIC. Nous introduisons un langage spécifique au domaine léger pour les contraintes d'utilisation de l'API nommés IMSpec. L'IMSCEC garantit simultanément que les API cibles sont validées, même avec peu d'utilisation, et guide la détection d'utilisation abusive. Une instance d'IMSpec est un motif rempli d'un ensemble de contraintes pour utiliser correctement l'API, et toute violation entraînera un bogue API-Misuse.
Nous téléchargeons les instances IMSPEC dans le dossier ImpSec, nous mettrons à jour progressivement ce dossier pour plus d'API. En outre, IMSPEC peut être utilisé à d'autres fins, comme générer des cas de test, la vérification, etc. De plus, nous fournissons un écrivain GUI IMSpec chez Tools.
Actuellement, IMSpec est créé par écriture manuelle. Cependant, nous nous assurons qu'il peut être généré automatiquement à partir des techniques d'extraction de spécifications. Nous essayons de notre mieux pour mener des expériences et implémenter des analyseurs pour traduire les résultats des outils miniers dans IMSpec, comme Apex. Mais, ces outils ne peuvent pas résoudre toutes les contraintes d'utilisation. Nous souhaitons également inviter les développeurs à nous aider à affiner les instances IMSPEC générées en fonction du manuel d'utilisation, comme OpenSSL.
Un usage API correct doit satisfaire un ensemble de contraintes d'utilisation, c'est-à-dire que les violations des contraintes peuvent entraîner des bogues API-Misus. IMChecker détecte automatiquement ces bogues dans le code source en utilisant les spécifications d'IMSpec. Pour traiter les programmes complexes et réels, les mécanismes sous-jacents d'Imchecker doivent être évolutifs tout en sacrifiant la quantité minimale de précision. Nous élaborons les détails de conception d'Ichecker, y compris l'exécution symbolique sous-limitée avec des techniques d'analyse statique pour créer un contexte d'analyse, des méthodologies pour détecter les bogues API-Misus dans le contexte d'analyse et une méthode pour filtrer les faux positifs à l'aide d'informations sémantiques et de statistiques d'utilisation.
Nous utilisons un exemple motivant pour illustrer le flux de travail d'Imchecker. Il s'agit d'un bogue API-Misuse dans OpenSSL rapporté dans CVE-2015-0288. La vérification du code d'erreur manquant de X509_get_pubkey() a abouti à un bug de déréférence du pointeur nul à la ligne-4.
1 // Location: crypto/x509/x509_req.c: 70 2 X509_REQ *X509_to_X509_REQ(...){
3 ...
4 pktmp = X509 get pubkey ( x );
5 // missing error code check of pktmp
6 + if ( pktmp == NULL )
7 + goto err ;
8 i = X509_REQ_set_pubkey ( ret , pktmp ); 9 EVP_PKEY_free ( pktmp );
10 ...
11 }
12
13 // Location: /crypto/x509/x509_cmp.c: 390
14 int X509_chain_check_suiteb (...){
15 ...
16 // check error value in usage
17 pk = X509 get pubkey ( x );
18 rv = check_suite_b ( pk , -1 , & tflags );
19 ...
20 }
21 // Location: /crypto/x509/x509_cmp.c: 359
22 static int check_suite_b ( EVP_PKEY * pkey ,...){ 23 ...
24 // ensure pkey not NULL
25 if ( pkey && pkey -> type == EVP PKEY EC )
26 ... // usage of pkey
27 }Voici le workflow d'Imchecker:
ImChecker prend le code source et les contraintes d'utilisation de l'API en entrée et génère des rapports de bogues avec des emplacements et des raisons concrets en tant que sortie. Premièrement, les contraintes d'utilisation de l'API sont écrites dans un langage spécifique au domaine léger nommé IMSpec; Par exemple, «la valeur de retour de x509_get_pubkey () doit être vérifiée avec null» . En utilisant ces spécifications, Imchecker valide directement les usages de l'API cible, qui soulage le problème d'utilisation clairsemée et guide le processus de détection des bogues. Ensuite, nous détectons les bogues API-Misus en trois phases. (1) Dans la phase 1, le contexte d'analyse est construit en construisant le graphique de flux de contrôle et en créant des traces de chemin de programme pour chaque API cible définie dans les spécifications en utilisant une exécution symbolique sous-limitée avec une analyse point à la plage et la plage et le chemin. Dans cet exemple, deux traces, T1 et T2, sont générées, comme indiqué dans la case ci-dessus des traces de chemin de programme. De cette façon, Imchecker peut capturer avec succès le contexte d'utilisation de X509_get_pubkey() , EVP_PKEY_free() et ceux entre les deux. (2) Dans la phase-2, Imchecker utilise les traces pour détecter les violations des contraintes comme bogues potentiels. Forexample, les instances TwoAPI-MISUSUS de X509_get_pubkey() sont trouvées pour les vérifications de code d'erreur manquantes étiquetées comme des bogues potentiels. (3) Dans la phase 3, Imchecker améliore la précision de détection en tirant parti de plusieurs instances d'utilisation et des informations sémantiques. Ensuite, la deuxième utilisation abusive est filtrée pour le chèque effectué dans le X509_to_X509_REQ() à la ligne-25.
L'utilisation de notre outil peut être trouvée ici: Tools / Readme.md
Lors de l'enquête sur les rapports de bogues générés par Imchecker, nous trouvons plusieurs bogues intéressants et acquièrez une expérience utile dans le processus de rapport de bogues avec des développeurs open source. Nous partageons notre expérience suivante.
Les auteurs tiennent à remercier les développeurs de Linux Kernel et OpenSSL pour nous aider à affiner l'IMSpec et à confirmer les rapports de bogues.
