Welche Gefahren birgt die Zweitveröffentlichung von C-Sprachquellcode?

1. Sekundäre Freigabe

Ein einfaches Verständnis der sekundären Freigabe besteht darin, dass der Speicher, auf den derselbe Zeiger zeigt, zweimal freigegeben wird. Bei C-Sprachquellcode werden free()-Operationen zweimal für denselben Zeiger ausgeführt In zwei Versionen beschreibt der fehlerhafte Code in Kapitel 3.1 dieses Artikels eine solche Situation. In der C++-Sprache ist ein unsachgemäßer flacher Kopiervorgang eine der häufigsten Ursachen für die sekundäre Veröffentlichung. Beispiel: Wenn Sie den Zuweisungsoperator oder den Kopierkonstruktor einmal aufrufen, verweisen die Datenelemente der beiden Objekte auf denselben dynamischen Speicher. Zu diesem Zeitpunkt wird der Referenzzählmechanismus sehr wichtig. Wenn die Referenzzählung falsch ist und ein Objekt den Gültigkeitsbereich verlässt, gibt der Destruktor den von den beiden Objekten gemeinsam genutzten Speicher frei. Das entsprechende Datenelement in einem anderen Objekt zeigt auf die freigegebene Speicheradresse. Wenn dieses Objekt ebenfalls den Gültigkeitsbereich verlässt, versucht sein Destruktor, den Speicher erneut freizugeben, was zu einem sekundären Freigabeproblem führt. Weitere Informationen finden Sie unter CWE ID 415: Double Free.

2. Der Schaden einer sekundären Freigabe

Die zweite Freigabe von Speicher kann zu Anwendungsabstürzen, Denial-of-Service-Angriffen und anderen Problemen führen. Dies ist eine der häufigsten Schwachstellen in C/C++. Von Januar bis November 2018 gab es in CVE insgesamt 38 diesbezügliche Schwachstelleninformationen. Einige der Schwachstellen sind wie folgt:

CVE-Nummer	Übersicht
CVE-2018-18751	'def der Datei read-catalog.c in der GNU gettext.-Version 0,19. 8 aultaddmessage'-Funktion Es besteht eine sekundäre Release-Schwachstelle.
CVE-2018-17097	Olli Parviainen SoundTouch Version 2.0 enthält eine Sicherheitslücke in der WavFileBase-Klasse der Datei WavFile.cpp, die es einem Remote-Angreifer ermöglichen könnte, einen Denial-of-Service zu verursachen (sekundäre Version).
CVE-2018-16425	OpenSC-Versionen vor 0.19.0-rc1 weisen eine sekundäre freie Schwachstelle in der Funktion „scpkcs15emuschsminit“ der Datei libopensc/pkcs15-sc-hsm.c auf. Ein Angreifer könnte diese Sicherheitslücke ausnutzen, um mithilfe einer speziell gestalteten Smartcard einen Denial-of-Service (Anwendungsabsturz) auszulösen.
CVE-2018-16402	elfutils Version 0.173 enthält ein Sicherheitsproblem in der Datei libelf/elf_end.c, das es einem Remote-Angreifer ermöglichen könnte, einen Denial-of-Service (sekundäre Veröffentlichung und Anwendungsabsturz) zu verursachen.

3. Beispielcode

Das Beispiel stammt aus der Samate Juliet Test Suite für C/C++ v1.3 (https://samate.nist.gov/SARD/testsuite.php), Name der Quelldatei: CWE415_Double_Free__malloc_free_char_17 .c.

3.1 fehlerhafter Code

Im obigen Beispielcode verwenden Sie malloc() für die Speicherzuweisung in Zeile 32 und In Verwenden Sie in Zeile 36 free(), um den zugewiesenen Speicher freizugeben. In Zeile 38 for-Schleifenanweisung wird der freigegebene Speicher Daten noch einmal freigegeben, was ein sekundäres Freigabeproblem verursacht. malloc() 进行内存分配，并在第36行使用 free() 对分配的内存进行了释放，在第38行 for 循环语句中，又对已经释放的内存 data 进行了一次释放，导致二次释放问题。

使用360代码卫士对上述示例代码进行检测，可以检出“二次释放”缺陷，显示等级为中。如图1所示：

图1：二次释放检测示例

3.2 修复代码

在上述修复代码中，Samate 给出的修复方式为： 在第32行使用 malloc() 进行内存分配，并在第36行处使用 free() 进行释放，释放后不在对该内存进行释放操作。

使用360代码卫士对修复后的代码进行检测，可以看到已不存在“二次释放”缺陷。如图2：

图2：修复后检测结果

4 、如何避免二次释放

要避免二次释放，需要注意以下几点：

（1）野指针是导致二次释放和释放后使用的重要原因之一，消除野指针的有效方式是在释放指针之后立即把它设置为 NULL

Verwenden Sie 360 ​​​​Code Guard, um den obigen Beispielcode zu erkennen. Sie können den Fehler „Sekundärversion“ erkennen und die Anzeigeebene ist mittel. Wie in Abbildung 1 dargestellt:

Abbildung 1: Beispiel für die Erkennung sekundärer Veröffentlichungen

🎜🎜3.2 Reparaturcode🎜🎜🎜🎜🎜🎜Im obigen Reparaturcode lautet die von Samate angegebene Reparaturmethode: Verwenden Sie malloc(), um Speicher zu reservieren, und verwenden Sie free(), um ihn in Zeile 36 freizugeben. Nach der Veröffentlichung , wird der Speicher nicht mehr freigegeben. 🎜🎜Verwenden Sie 360 ​​​​Code Guard, um den reparierten Code zu erkennen, und Sie können sehen, dass kein „sekundärer Release“-Defekt vorliegt. Wie in Abbildung 2 dargestellt: 🎜🎜🎜🎜🎜Abbildung 2: Erkennungsergebnisse nach der Reparatur🎜🎜🎜4. So vermeiden Sie eine sekundäre Veröffentlichung🎜🎜🎜Um eine sekundäre Veröffentlichung zu vermeiden, müssen Sie auf die folgenden Punkte achten:🎜

🎜(1 ) Wilde Zeiger führen zu sekundären Veröffentlichungen. Einer der wichtigen Gründe für die Veröffentlichung und Verwendung nach der Veröffentlichung ist, sie auf NULL zu setzen Setzen Sie es sofort nach der Freigabe auf einen Zeiger. Ein weiteres zulässiges Objekt. 🎜🎜(2) Für das sekundäre Release-Problem, das durch flache C++-Kopie verursacht wird, ist die ständige Durchführung einer tiefen Kopie eine gute Lösung. 🎜🎜(3) Mithilfe statischer Quellcode-Analysetools können Sie mögliche sekundäre Release-Probleme im Programm automatisch erkennen. 🎜🎜

Das obige ist der detaillierte Inhalt vonWelche Gefahren birgt die Zweitveröffentlichung von C-Sprachquellcode?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!