Comment implémenter l'analyse de vulnérabilité causée par l'utilisation après la publication du programme C++

1. Utilisation après la libération

Lorsque la mémoire allouée dynamiquement est libérée, le contenu de cette mémoire n'est pas défini et peut rester intact et accessible, car lorsqu'un bloc de mémoire libéré est réaffecté ou recyclé, la gestion de la mémoire est déterminée par le programme, cependant, il est possible que le contenu de cette mémoire ait été modifié, provoquant un comportement inattendu du programme. Par conséquent, lorsque la mémoire est libérée, il est garanti qu’elle ne sera plus écrite ni lue.

2. Risques d'utilisation après libération

Les problèmes causés par une mauvaise gestion de la mémoire sont des vulnérabilités courantes dans les programmes C/C++. L'utilisation après la libération peut entraîner des risques potentiels exploitables, notamment l'arrêt anormal du programme, l'exécution de code arbitraire et les attaques par déni de service. De janvier à novembre 2018, il y avait un total de 134 informations de vulnérabilité associées dans CVE. Certaines des vulnérabilités sont les suivantes :

CVE	Aperçu des vulnérabilités
CVE-2018-1000051	Il y en a une dans fz_keep_key _version stockable d'Artifex Mupdf à utiliser après-libre vulnérabilité pouvant entraîner un déni de service ou des problèmes d’implémentation de code. La vulnérabilité pourrait être exploitée en incitant une victime à ouvrir un fichier PDF spécialement conçu.
CVE-2018-17474	Il existe une vulnérabilité d'utilisation après libération dans le HTMLImportsController du moteur Blink du navigateur Google Chrome 70.0.3538.67 et versions antérieures, qui est susceptible de permettre à un attaquant distant d'exploiter la corruption du tas. problème via une page HTML spécialement construite.
CVE-2018-15924	Une vulnérabilité d'utilisation après libération existe dans Adobe Acrobat et Reader 2018.011.20063 et versions antérieures, 2017.011.30102 et versions antérieures, 2015.006.30452 et versions antérieures. Un attaquant distant pourrait exploiter cette vulnérabilité pour exécuter du code arbitraire.

3. Exemple de code

L'exemple provient de Samate Juliet TestSuite pour C/C++ v1.3 (https://samate.nist.gov/SARD/testsuite.php), nom du fichier source : CWE416_Use_After_Free__malloc_free_char_01. .

3.1 Code de défaut

Utilisez 360 ​​Code Guard pour détecter l'exemple de code ci-dessus. Vous pouvez détecter le défaut "utilisation après libération" et le niveau d'affichage est élevé. Comme le montre la figure 1 :

Figure 1 : Exemple d'utilisation après détection de version

3.2 Code de réparation

Dans le code de réparation ci-dessus, la méthode de réparation donnée par Samate est la suivante : utiliser à la ligne 30 malloc () alloue de la mémoire et utilise free() à la ligne 36 pour la libérer. Après la libération, aucune autre opération n'est effectuée sur la mémoire.

Utilisez 360 ​​Code Guard pour détecter le code réparé, et vous pourrez voir qu'il n'y a pas de défaut "utilisation après publication". Comme le montre la figure 2 :

Figure 2 : Résultats de détection après réparation

4. Comment éviter une utilisation après la libération

Pour éviter une utilisation après la libération, vous devez faire attention aux points suivants :

(1) Lors de la libération de mémoire, assurez-vous de définir le pointeur nul Bien que cette méthode ait une efficacité limitée pour l'utilisation de structures de données multiples ou complexes, elle peut éviter certains problèmes dans une certaine mesure.

(2) Lors de l'allocation ou de la libération de mémoire dans une instruction de boucle, vous devez vérifier soigneusement s'il y a un problème.

(3) Utilisez des outils d'analyse statique du code source pour une détection automatisée, qui peuvent découvrir efficacement les problèmes d'utilisation post-publication dans le code source.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!