許多漏洞發(fā)生的根本原因是對整數(shù)的漏洞處理。標(biāo)準(zhǔn) int 類型可以從 0x7FFFFFFF 一直到 -0x80000000（注意負(fù)數(shù)），并帶有整數(shù)溢出?；蛘?，它可以被截斷并將數(shù)字從正數(shù)更改為負(fù)數(shù)。整數(shù)在C語言中可能是一個噩夢，并且多年來造成了許多內(nèi)存攻擊漏洞。

　　整數(shù)溢出漏洞（integer overflow）：在計(jì)算機(jī)中，整數(shù)分為無符號整數(shù)以及有符號整數(shù)兩種。其中有符號整數(shù)會在最高位用0表示正數(shù)，用1表示負(fù)數(shù)，而無符號整數(shù)則沒有這種限制。另外，我們常見的整數(shù)類型有8位（單字節(jié)字符、布爾類型）、16位（短整型）、32位（長整型）等。關(guān)于整數(shù)溢出，其實(shí)它與其它類型的溢出一樣，都是將數(shù)據(jù)放入了比它本身小的存儲空間中，從而出現(xiàn)了溢出。由此引發(fā)的一切程序漏洞都可以成為整數(shù)溢出漏洞。

　　最近有一些發(fā)現(xiàn)引起了我的注意，它們屬于整數(shù)漏洞處理引起的漏洞。整數(shù)溢出也是一種常見的軟件漏洞，由此引發(fā)的漏洞可能比格式化字符串缺陷和緩沖區(qū)溢出缺陷更難于發(fā)現(xiàn)。溢出類型及表現(xiàn)：

　　1、溢出。只有符號的數(shù)才會發(fā)生溢出，對于signed整型的溢出，C的規(guī)范定義是“undefined behavior”，也就是說，編譯器愛怎么實(shí)現(xiàn)就怎么實(shí)現(xiàn)。對于大多數(shù)編譯器來說，仍然是回繞。

　　2、回繞。無符號數(shù)會回繞（常繞過一些判斷語句）。

　　3、截斷。將一個較大寬度的數(shù)存入一個寬度小的操作數(shù)中，高位發(fā)生截斷。

　　簡單了解整數(shù)溢出的危害：

　　1、整數(shù)回繞之后，會導(dǎo)致索引越界，取到不確定的數(shù)據(jù)。

　　2、 或者判斷失效，形成死循環(huán)。

　　3、回繞之后，導(dǎo)致分配超大內(nèi)存。

　　需要指出的是 Qualys 發(fā)現(xiàn)的 Linux 內(nèi)核中的整數(shù)截斷漏洞、GHSL 的 BSD 管理程序中的符號轉(zhuǎn)換漏洞以及 Checkpoint 發(fā)現(xiàn)的 Kindle 中緩沖區(qū)分配大小的整數(shù)溢出。然后，我的伙伴 seiraib 發(fā)現(xiàn)了一個整數(shù)溢出漏洞模糊測試，但我們無法找到溢出實(shí)際發(fā)生的位置。我想知道，這漏洞會在編譯時被發(fā)現(xiàn)嗎？還是會在運(yùn)行時立即崩潰？“

　　GCC 和 Clang 有編譯標(biāo)志，可以在編譯時查找?guī)讉€漏洞類。此外，還有一些運(yùn)行時保護(hù)可能會導(dǎo)致崩潰，從而使 root 操作更容易。本文是關(guān)于通過編譯器警告和動態(tài)檢測發(fā)現(xiàn)漏洞的。所有帶有額外示例的源代碼片段都可以在 mdulin2/integer_compile_flags 中找到。

　　漏洞類

　　目標(biāo)是以一種程序預(yù)期不會導(dǎo)致內(nèi)存損壞的方式更改數(shù)字。C 語言中將重點(diǎn)關(guān)注三個數(shù)量（但主要是整數(shù)）漏洞類：

　　溢出/下溢：如果超過c中該類型的最大值或最小值，整數(shù)將簡單地環(huán)繞。例如，有符號整數(shù)的溢出將從0x7FFFFFFF一直到-0x80000000。下溢以相反的方向進(jìn)行，是在減去數(shù)值時發(fā)生的。

　　截斷：縮小數(shù)字的存儲容量。例如，從 uint64_t 到 uint32_t 會將數(shù)字的存儲容量減少一半。這有可能徹底改變數(shù)字的值和符號。

　　有符號類型（signedness）轉(zhuǎn)換：數(shù)字要么是有符號的，要么是無符號的（例如 unsigned int 和 int）。當(dāng)從負(fù)有符號數(shù)轉(zhuǎn)換為無符號數(shù)或從非常大的無符號數(shù)轉(zhuǎn)換為有符號數(shù)時，在這些之間進(jìn)行轉(zhuǎn)換可能會產(chǎn)生可怕的后果。例如，將 0xFFFFFFFF 的無符號整數(shù)轉(zhuǎn)換為有符號整數(shù)將是 -1 而不是非常大的數(shù)字。

　　靜態(tài)分析

　　其中兩個漏洞類可以在編譯時通過特定的編譯標(biāo)志來確定，盡管可能會出現(xiàn)大量不可利用的漏洞，但還是有一些很好的線索可以用來發(fā)現(xiàn)漏洞。

　　截斷

　　截斷代碼

　　有符號類型轉(zhuǎn)換代碼

　　在編譯期間使用Wconversion標(biāo)志將輸出警告”可能改變值的隱式轉(zhuǎn)換“。這直接引用了截斷和轉(zhuǎn)換漏洞！

　　例如，截斷情況的代碼可以在圖 1 中看到。該代碼有一種正在轉(zhuǎn)換為 int 的 long long 類型。由于這會將存儲容量從 64 位更改為 32 位，因此可能會導(dǎo)致?lián)p壞。當(dāng)使用Wconversion標(biāo)志編譯此代碼時，將出現(xiàn)一條警告消息，指出截斷問題！這個警告可以在下圖中看到。當(dāng)執(zhí)行從size_t （unsigned long long）到int的轉(zhuǎn)換時，可以使用這個確切的漏洞消息來查找上面提到的Linux Kernel內(nèi)核漏洞。

　　截斷警告消息

　　另一個需要考慮的有趣事項(xiàng)是float和double的情況。因?yàn)閐ouble是float大小的2倍，所以相同類型的截斷可以通過相同的編譯標(biāo)志檢測到，此處顯示了代碼中的一個示例。

　　有符號類型

　　Wconversion標(biāo)志也可以用于檢測符號轉(zhuǎn)換漏洞。當(dāng)從有符號轉(zhuǎn)換為無符號或從無符號整數(shù)轉(zhuǎn)換為有符號整數(shù)時，就會發(fā)生這種情況，這兩個問題都顯示在上圖中。下圖顯示了編譯時漏洞消息的一個示例。

　　有符號類型轉(zhuǎn)換警告消息

　　靜態(tài)分析總結(jié)

　　這些標(biāo)志只檢查隱式轉(zhuǎn)換。有時，需要將一個值從無符號整數(shù)轉(zhuǎn)換為有符號整數(shù)，以便進(jìn)行一些數(shù)學(xué)計(jì)算，這是有效的和預(yù)期的C語言。當(dāng)一個數(shù)字被顯式轉(zhuǎn)換時，這些漏洞消息將不會顯示，因此。為了找到顯式的強(qiáng)制類型轉(zhuǎn)換，可以使用類似于CodeQL的東西、手動檢查或動態(tài)測試。

　　盡管到目前為止我們只使用 Wconversion 進(jìn)行靜態(tài)分析，但實(shí)際上構(gòu)成了這個單一標(biāo)志的標(biāo)志過多。例如，Wsign-conversion 標(biāo)志警告可能會更改整數(shù)值符號的隱式轉(zhuǎn)換。有關(guān)這些的更多信息，請?jiān)L問 GCC 文檔。

　　動態(tài)儀表

　　靜態(tài)分析很可能會得到大量誤報，不過其中還是有一些真正的漏洞。然而，如果可以觸發(fā)代碼路徑，動態(tài)分析總是能找到真正的漏洞。下面，我們將展示在與整數(shù)相關(guān)的漏洞上崩潰/通知的檢測選項(xiàng)。我們將討論GCC和Clang中的一些特定標(biāo)志，而不是討論漏洞類。

　　ftrapv

　　此選項(xiàng)為加法、減法和乘法運(yùn)算的有符號溢出生成漏洞。同樣，由于這是動態(tài)測試，因此每當(dāng)發(fā)生這種情況時都會導(dǎo)致程序崩潰！可以在下面看到此代碼的示例：

　　當(dāng)行a = a + 1時，上面的代碼將導(dǎo)致整數(shù)溢出；，因?yàn)镃中整數(shù)的最大大小是0x7FFFFFFF。會發(fā)生什么呢？程序被終止，并且永遠(yuǎn)不會到達(dá)print語句。通過在發(fā)生溢出時強(qiáng)制崩潰，我們可以保證檢測到漏洞，并且更容易找到溢出的原因。這在模糊測試和嘗試找到崩潰根本原因時非常有用。

　　還應(yīng)該注意的是，該標(biāo)志也可以檢測有符號整數(shù)下溢。

　　fsanitize=integer

　　用于查找整數(shù)漏洞的 UBSAN（未初始化行為清理器）非常棒！此標(biāo)志特定于 Clang，用于與整數(shù)相關(guān)的漏洞。

　　雖然ftrapv只捕獲有符號整數(shù)溢出，但fsanitize=integer將在無符號整數(shù)和有符號整數(shù)溢出（有符號整數(shù)溢出和無符號整數(shù)溢出）時崩潰。這意味著所有整數(shù)溢出，無論符號如何，通過加法、減法或乘法都將在運(yùn)行時被捕獲。

　　除了發(fā)現(xiàn)程序中的溢出/下溢外，我們還可以找到用這個標(biāo)志提到的另外兩個漏洞類：截斷（隱式有符號整數(shù)截斷和隱式無符號整數(shù)截斷）和轉(zhuǎn)換（隱式整數(shù)符號改變）。與上面的靜態(tài)方法不同，必須發(fā)生一個糟糕的數(shù)學(xué)運(yùn)算才能觸發(fā)UBSAN使程序崩潰。

　　不過，讓我們看看它的實(shí)際效果！我們將使用原始的符號問題。當(dāng)運(yùn)行代碼時，值為LONG_MAX （0x7FFFFFFFFFFFFFFF）的long long將由于轉(zhuǎn)換為整數(shù)而被分為兩半（被截斷）。因此，這將是0xFFFFFFFF或-1作為有符號整數(shù)。由于添加了額外的檢測，程序在截斷發(fā)生時崩潰。這樣，設(shè)備就不需要改變標(biāo)志，它檢查long long中的值是否適合int。這個崩潰可以在下圖中看到。

　　截斷轉(zhuǎn)換崩潰

　　我們已經(jīng)提到了對整數(shù)溢出/下溢、整數(shù)截斷和符號轉(zhuǎn)換問題的動態(tài)和靜態(tài)檢查。但是，動態(tài)檢測缺少一件事：浮點(diǎn)數(shù)學(xué)運(yùn)算。

　　當(dāng)浮點(diǎn)數(shù)學(xué)運(yùn)算在 C 中溢出時，它會變?yōu)闊o窮大或 inf。奇怪的是，由于浮點(diǎn)數(shù)學(xué)處理精度的方式，浮點(diǎn)數(shù)從未真正發(fā)生環(huán)繞；它只是趨近于無窮大！可以在此處查看此溢出的示例。

　　另一個未捕獲的漏洞是浮動截斷。例如，在運(yùn)行時不會捕獲從 double 到 float 的轉(zhuǎn)換。有一個誤導(dǎo)性的 UBSAN 標(biāo)志 （-fsanitize=float-cast-overflow），它只能發(fā)現(xiàn)漏洞的雙精度/浮點(diǎn)數(shù)到整數(shù)的轉(zhuǎn)換，但不會發(fā)現(xiàn)浮點(diǎn)數(shù)之間的截斷漏洞。這方面的一個例子可以在這里看到。

　　了解浮點(diǎn)數(shù)變?yōu)?inf 和 NaN 可能很有用，例如 Unreal 游戲引擎中的 Jack Bakers NaN 傳播漏洞確實(shí)會發(fā)生。但是，目前沒有檢測到 C 語言中浮點(diǎn)數(shù)在運(yùn)行時的溢出、下溢、截斷或 NaN/Inf 使用。

　　總結(jié)

　　在嘗試查找漏洞時，任何來自自動化工具或儀器的幫助都非常有用。除了上面提到的整數(shù)漏洞類之外，還有許多其他有趣的標(biāo)志和工具，例如眾所周知的 ASAN（地址清理器），還有許多其他編譯標(biāo)志和檢測選項(xiàng)可以幫助查找特定的漏洞類，本文只關(guān)注查找與整數(shù)相關(guān)的漏洞類。