So implementieren Sie eine Schwachstellenanalyse, die durch die Verwendung nach der Veröffentlichung eines C++-Programms verursacht wird

1. Verwendung nach der Freigabe

Wenn dynamisch zugewiesener Speicher freigegeben wird, ist der Inhalt dieses Speichers undefiniert und bleibt möglicherweise intakt und zugänglich, da er durch die Speicherverwaltung bestimmt wird, wenn ein freigegebener Speicherblock neu zugewiesen oder recycelt wird Programm, aber es ist möglich, dass der Inhalt dieses Speichers geändert wurde, was zu unerwartetem Programmverhalten führt. Daher ist bei Freigabe des Speichers gewährleistet, dass nicht mehr darauf geschrieben oder gelesen wird.

2. Gefahren der Verwendung nach dem Freigeben

Probleme, die durch unsachgemäße Speicherverwaltung verursacht werden, sind häufige Schwachstellen in C/C++-Programmen. Die Verwendung nach dem kostenlosen Gebrauch kann zu potenziell ausnutzbaren Risiken führen, einschließlich abnormaler Programmbeendigung, Ausführung willkürlichen Codes und Denial-of-Service-Angriffen. Von Januar bis November 2018 gab es in CVE insgesamt 134 diesbezügliche Schwachstelleninformationen. Einige der Schwachstellen sind wie folgt:

CVE	Schwachstellenübersicht
CVE-2018-1000051	Es gibt eine im. fz_keep_key _Speicherbare Version von Artifex Mupdf. Nach kostenloser Verwendung Sicherheitslücke, die zu einem Denial-of-Service oder Code-Implementierungsproblemen führen kann. Die Sicherheitslücke könnte ausgenutzt werden, indem ein Opfer dazu verleitet wird, eine speziell gestaltete PDF-Datei zu öffnen.
CVE-2018-17474	Es gibt eine Use-after-free-Schwachstelle im HTMLImportsController der Blink-Engine des Google Chrome-Browsers 70.0.3538.67 und früher, die es einem Remote-Angreifer wahrscheinlich ermöglicht, die Heap-Beschädigung auszunutzen Ausgabe über eine speziell erstellte HTML-Seite.
CVE-2018-15924	Eine Use-After-Free-Schwachstelle besteht in Adobe Acrobat und Reader 2018.011.20063 und früheren Versionen, 2017.011.30102 und früheren Versionen, 2015.006.30452 und früheren Versionen. Ein Remote-Angreifer könnte diese Schwachstelle ausnutzen, um beliebigen Code auszuführen.

3. Beispielcode

Das Beispiel stammt von Samate Juliet TestSuite für C/C++ v1.3 (https://samate.nist.gov/SARD/testsuite.php), Quelldateiname: CWE416_Use_After_Free__malloc_free_char_01 . C.

3.1 Fehlercode

Verwenden Sie 360 ​​​​Code Guard, um den obigen Beispielcode zu erkennen, und der Anzeigepegel ist hoch. Wie in Abbildung 1 gezeigt: Abbildung 1: Beispiel für die Verwendung nach der Release-Erkennung () reserviert Speicher und verwendet free() in Zeile 36, um ihn freizugeben. Nach der Freigabe werden keine weiteren Vorgänge für den Speicher ausgeführt.

Verwenden Sie 360 ​​​​Code Guard, um den reparierten Code zu erkennen, und Sie können sehen, dass kein Fehler „Verwendung nach Veröffentlichung“ vorliegt. Wie in Abbildung 2 dargestellt:

Abbildung 2: Erkennungsergebnisse nach der Reparatur

4. So vermeiden Sie die Verwendung nach der Freigabe

Um die Verwendung nach der Freigabe zu vermeiden, müssen Sie auf die folgenden Punkte achten:

(1) Stellen Sie beim Freigeben von Speicher sicher, dass Sie den Nullzeiger setzen. Obwohl diese Methode bei der Verwendung mehrerer oder komplexer Datenstrukturen nur begrenzt wirksam ist, können einige Probleme bis zu einem gewissen Grad vermieden werden.

(2) Beim Zuweisen oder Freigeben von Speicher in einer Schleifenanweisung müssen Sie sorgfältig prüfen, ob ein Problem vorliegt.

(3) Verwenden Sie Tools zur statischen Analyse des Quellcodes zur automatischen Erkennung, mit denen sich Nutzungsprobleme im Quellcode nach der Veröffentlichung effektiv erkennen lassen.

Das obige ist der detaillierte Inhalt vonSo implementieren Sie eine Schwachstellenanalyse, die durch die Verwendung nach der Veröffentlichung eines C++-Programms verursacht wird. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!