首頁  >  文章  >  運維  >  C語言記憶體分配函數被污染的範例分析

C語言記憶體分配函數被污染的範例分析

WBOY
WBOY轉載
2023-05-15 11:13:051012瀏覽

1、被污染的記憶體分配

C 語言的記憶體分配函數包括malloc()kmalloc smalloc()xmalloc()realloc()calloc()GlobalAlloc() HeapAlloc()等等,以malloc()為例, malloc() 函數的原型為:

extern void*malloc (unsignedintnum_bytes);

malloc() 函數分配了num_bytes 位元組的內存,並傳回了指向這塊記憶體的指標。當記憶體分配長度的整數來自於可能被污染的不可信來源時,如果沒有對外部輸入的資料進行有效判斷,會導致超大的記憶體分配。其中可能被污染的不可信來源包括:命令列參數、設定檔、網路通訊、資料庫、環境變數、登錄值以及其他來自應用程式以外的輸入等。

2、 被污染的記憶體分配的危害

直接將被污染的資料作為記憶體分配函數長度參數,如傳入了一個極大的整數值,程式就會相應的分配一塊極大的內存,從而導致系統極大的內存開銷,甚至導致拒絕服務攻擊。

CVE中也有一些與之相關的漏洞訊息,從2018年1月至2019年3月,CVE中就有4個相關漏洞訊息。漏洞資訊如下:

#CVE 概述
CVE-2018-6869 ZZIPlib 0.13.68 版本中的zzip/zip.c 檔案的'__zzip_parse_root_directory'函數存在安全漏洞。遠端攻擊者可藉助特製的zip檔案利用該漏洞造成拒絕服務(不可控的記憶體分配和崩潰)。
CVE-2018-5783 PoDoFo 0.9.5 版本中的base/PdfVecObjects.h檔案的'PoDoFo::PdfVecObjects::Reserve'函數存在安全漏洞。遠端攻擊者可藉助特製的pdf檔利用漏洞造成拒絕服務(不受控制的記憶體分配)。
CVE-2018-5296 PoDoFo 0.9.5 版本中的base/PdfParser.cpp 檔案的'PdfParser::ReadXRefSubsection'函數存在安全漏洞,該漏洞.cpp 檔案的'PdfParser::ReadXRefSubsection'函數存在安全漏洞,該漏洞.cpp 檔案的'PdfParser::ReadXRefSubsection'函數存在安全漏洞,該漏洞。源自於程式沒有控制記憶體的分配。遠端攻擊者可藉助特製的pdf檔利用漏洞造成拒絕服務。


3、範例程式碼

本節所用範例參考CWE-789: Uncontrolled Memory Allocation (http://cwe.mitre.org/data/definitions/789 .html) 提供的程式碼範例,並對範例中的 GetUntrustedInt() 函數進行了定義。

3.1缺陷程式碼

C語言記憶體分配函數被污染的範例分析

#在上述範例程式碼中,在第9行使用malloc()函數進行長度為totBytes 位元組的記憶體分配,透過追蹤路徑可以看出,totBytes 在第6行透過size*sizeof(char); 計算結果進行賦值,而size 的值是第7行使用scanf() 函數取得的使用者鍵盤輸入,為被污染的資料來源,進而導致記憶體分配長度 totBytes 被污染,有「被污染的記憶體分配」問題。

使用360程式碼衛兵對上述範例程式碼進行偵測,可以檢出「被污染的記憶體分配」缺陷,顯示等級為高。如圖1所示:


C語言記憶體分配函數被污染的範例分析

#圖1:被污染的記憶體分配的偵測範例

3.2 修正程式碼

C語言記憶體分配函數被污染的範例分析

在上述修復程式碼中,雖然totBytes 的來源為被污染的數據,但在第10行對totBytes的長度進行了有效限制,從而避免了被污染的記憶體分配。

使用360碼衛士對修復後的程式碼進行偵測,可以看到已不存在「被污染的記憶體分配」缺陷。如圖2:


C語言記憶體分配函數被污染的範例分析

圖2:修正後偵測結果

4、如何避免被污染的記憶體分配

(1)避免使用被污染的資料直接作為記憶體分配函數的長度參數,如無法避免,則應對被污染的資料進行有效限制。

(2)使用原始碼靜態分析工具,可以有效發現這類問題。

以上是C語言記憶體分配函數被污染的範例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文轉載於:yisu.com。如有侵權,請聯絡admin@php.cn刪除