來源：嵌入式ARM

C中大多數(shù)緩沖區(qū)溢出問題可以直接追溯到標準 C 庫。最有害的罪魁禍首是不進行自變量檢查的、有問題的字符串操作strcpy、strcat、sprintf 和 gets。

大部分程序員仍然會使用這些函數(shù)，因為從來沒有人教開發(fā)人員避免使用它們。某些人從各處獲得某個提示，但即使是優(yōu)秀的開發(fā)人員也會被這弄糟，下面就來分析一下。

第一位公共的“敵人”是 gets（）。建議不要使用 gets（）。該函數(shù)從標準輸入讀入用戶輸入的一行文本，它在遇到 EOF字符或換行字符之前，不會停止讀入文本。也就是：gets（） 根本不執(zhí)行邊界檢查。因此，使用 gets（）總是有可能使任何緩沖區(qū)溢出。作為一個替代方法，可以使用 fgets（）。它可以做與 gets（）所做的同樣的事情，但它接受用來限制讀入字符數(shù)目的大小參數(shù)，因此，提供了一種防止緩沖區(qū)溢出的方法。例如，不要使用以下代碼：

void main（）{ char buf［1024］; gets（buf）;}

而使用以下代碼：

#define BUFSIZE 1024void main（）{ char buf［BUFSIZE］; fgets（buf， BUFSIZE， stdin）;}

C 編程中的主要陷阱C語言中一些標準函數(shù)很有可能使你陷入困境。但不是所有函數(shù)使用都不好。通常，利用這些函數(shù)之一需要任意輸入傳遞給該函數(shù)。這個列表包括：

strcpy（）

strcat（）

sprintf（）

scanf（）

sscanf（）

fscanf（）

vfscanf（）

vsprintf

vscanf（）

vsscanf（）

streadd（）

strecpy（）

strtrns（）

我們推薦使用，如果有可能，應盡量避免使用這些函數(shù)。這些函數(shù)在大多數(shù)情況下，都有合理的替代方法。我們將仔細檢查它們中的每一個，所以可以看到什么構成了它們的誤用，以及如何避免它。

strcpy（）函數(shù)將源字符串復制到緩沖區(qū)。沒有指定要復制字符的具體數(shù)目。復制字符的數(shù)目直接取決于源字符串中的數(shù)目。如果源字符串碰巧來自用戶輸入，且沒有專門限制其大小，則有可能會陷入大的麻煩中！

如果知道目的地緩沖區(qū)的大小，則可以添加明確的檢查：

if（strlen（src） 》= dst_size）{ /* Do something appropriate， such as throw an error. */}else{ strcpy（dst， src）;}

完成同樣目的的更容易方式是使用 strncpy（） 庫例程：

strncpy（dst， src， dst_size-1）;dst［dst_size-1］ = ‘\0’; /* Always do this to be safe！ */

如果 src 比 dst 大，則該函數(shù)不會拋出一個錯誤；當達到最大尺寸時，它只是停止復制字符。注意上面調用 strncpy（）中的 -1。如果 src 比 dst 長，則那給我們留有空間，將一個空字符放在 dst 數(shù)組的末尾。

當然，可能使用strcpy（）不會帶來任何潛在的安全性問題，正如在以下示例中所見：

strcpy（buf， “Hello！”）;

即使這個操作造成 buf 的溢出，但它只是對幾個字符這樣而已。由于我們靜態(tài)地知道那些字符是什么，并且很明顯，由于沒有危害，所以這里無須擔心 ― 當然，除非可以用其它方式覆蓋字符串Hello所在的靜態(tài)存儲器。

確保strcpy（）不會溢出的另一種方式是，在需要它時就分配空間，確保通過在源字符串上調用 strlen（） 來分配足夠的空間。例如：

dst = （char *）malloc（strlen（src））;strcpy（dst， src）;

strcat（）函數(shù)非常類似于strcpy（），除了它可以將一個字符串合并到緩沖區(qū)末尾。它也有一個類似的、更安全的替代方法strncat（）。如果可能，使用strncat（）而不要使用strcat（）。

函數(shù)sprintf（）和vsprintf（）是用來格式化文本和將其存入緩沖區(qū)的通用函數(shù)。它們可以用直接的方式模仿strcpy（）行為。換句話說，使用sprintf（）和vsprintf（）與使用strcpy（）一樣，都很容易對程序造成緩沖區(qū)溢出。例如，考慮以下代碼：

void main（int argc， char **argv）{ char usage［1024］; sprintf（usage， “USAGE： %s -f flag ［arg1］\n”， argv［0］）;}

我們經(jīng)常會看到類似上面的代碼。它看起來沒有什么危害。它創(chuàng)建一個知道如何調用該程序字符串。那樣，可以更改二進制的名稱，該程序的輸出將自動反映這個更改。雖然如此， 該代碼有嚴重的問題。文件系統(tǒng)傾向于將任何文件的名稱限制于特定數(shù)目的字符。那么，您應該認為如果您的緩沖區(qū)足夠大，可以處理可能的最長名稱，您的程序會安全，對嗎？只要將1024改為對我們的操作系統(tǒng)適合的任何數(shù)目，就好了嗎？但是，不是這樣的。通過編寫我們自己的小程序來推翻上面所說的，可能容易地推翻這個限制：

void main（）{ execl（“/path/to/above/program”， 《《insert really long string here》》， NULL）;}

函數(shù)execl（）啟動第一個參數(shù)中命名的程序。第二個參數(shù)作為argv［0］傳遞給被調用的程序。我們可以使那個字符串要多長有多長！

那么如何解決sprintf（）帶來得問題呢？遺憾的是，沒有完全可移植的方法。某些體系結構提供了snprintf（）方法，即允許程序員指定將多少字符從每個源復制到緩沖區(qū)中。例如，如果我們的系統(tǒng)上有snprintf，則可以修正一個示例成為：

void main（int argc， char **argv）{ char usage［1024］; char format_string = “USAGE： %s -f flag ［arg1］\n”; snprintf（usage， format_string， argv［0］，1024-strlen（format_string） + 1）;}

注意，在第四個變量之前，snprintf（）與sprintf（）是一樣的。第四個變量指定了從第三個變量中應被復制到緩沖區(qū)的字符最大數(shù)目。注意，1024 是錯誤的數(shù)目！我們必須確保要復制到緩沖區(qū)使用的字符串總長不超過緩沖區(qū)的大小。所以，必須考慮一個空字符，加上所有格式字符串中的這些字符，再減去格式說明符 %s。該數(shù)字結果為1000，但上面的代碼是更具有可維護性，因為如果格式字符串偶然發(fā)生變化，它不會出錯。

sprintf（）的許多（但不是全部）版本帶有使用這兩個函數(shù)的更安全的方法。可以指定格式字符串本身每個自變量的精度。例如，另一種修正上面有問題的sprintf（）的方法是：

void main（int argc， char **argv）{ char usage［1024］; sprintf（usage， “USAGE： %.1000s -f flag ［arg1］\n”， argv［0］）;}

注意，百分號后與 s 前的 .1000。該語法表明，從相關變量（本例中是 argv［0］）復制的字符不超過 1000 個。

如果任一解決方案在您的程序必須運行的系統(tǒng)上行不通，則最佳的解決方案是將snprintf（）的工作版本與您的代碼放置在一個包中。可以找到以sh歸檔格式的、自由使用的版本；請參閱 參考資料。

繼續(xù)，scanf系列的函數(shù)也設計得很差。在這種情況下，目的地緩沖區(qū)會發(fā)生溢出。考慮以下代碼：

void main（int argc， char **argv）{ char buf［256］; sscanf（argv［0］， “%s”， &buf）;}

如果輸入的字大于 buf 的大小，則有溢出的情況。幸運的是，有一種簡便的方法可以解決這個問題。考慮以下代碼，它沒有安全性方面的薄弱環(huán)節(jié)：

void main（int argc， char **argv）{ char buf［256］; sscanf（argv［0］， “%255s”， &buf）;}

百分號和 s 之間的 255 指定了實際存儲在變量 buf 中來自 argv［0］ 的字符不會超過 255 個。其余匹配的字符將不會被復制。

接下來，我們討論streadd（）和strecpy（）。由于，不是每臺機器開始就有這些調用，那些有這些函數(shù)的程序員，在使用它們時，應該小心。這些函數(shù)可以將那些含有不可讀字符的字符串轉換成可打印的表示。例如，考慮以下程序：

#include 《libgen.h》void main（int argc， char **argv）{ char buf［20］; streadd（buf， “\t\n”， “”）; printf（%s\n“， buf）;}

該程序打印：

\t\n

而不是打印所有空白。如果程序員沒有預料到需要多大的輸出緩沖區(qū)來處理輸入緩沖區(qū)（不發(fā)生緩沖區(qū)溢出），則streadd（） 和 strecpy（）函數(shù)可能有問題。如果輸入緩沖區(qū)包含單一字符 ― 假設是 ASCII 001（control-A）―則它將打印成四個字符\001。這是字符串增長的最壞情況。如果沒有分配足夠的空間，以至于輸出緩沖區(qū)的大小總是輸入緩沖區(qū)大小的四倍，則可能發(fā)生緩沖區(qū)溢出。

另一個較少使用的函數(shù)是strtrns（），因為許多機器上沒有該函數(shù)。函數(shù)strtrns（）取三個字符串和結果字符串應該放在其內(nèi)的一個緩沖區(qū)，作為其自變量。第一個字符串必須復制到該緩沖區(qū)。一個字符被從第一個字符串中復制到緩沖區(qū)，除非那個字符出現(xiàn)在第二個字符串中。如果出現(xiàn)的話，那么會替換掉第三個字符串中同一索引中的字符。這聽上去有點令人迷惑。讓我們看一下，將所有小寫字符轉換成大寫字符的示例：

#include 《libgen.h》void main（int argc， char **argv）{ char lower［］ = ”abcdefghijklmnopqrstuvwxyz“; char upper［］ = ”ABCDEFGHIJKLMNOPQRSTUVWXYZ“; char *buf; if（argc 《 2） { printf（”USAGE： %s arg\n“， argv［0］）; exit（0）; } buf = （char *）malloc（strlen（argv［1］））; strtrns（argv［1］， lower， upper， buf）; printf（”%s\n“， buf）;}

以上代碼實際上不包含緩沖區(qū)溢出。但如果我們使用了固定大小的靜態(tài)緩沖區(qū)，而不是用malloc（）分配足夠空間來復制argv［1］，則可能會引起緩沖區(qū)溢出情況。

避免內(nèi)部緩沖區(qū)溢出realpath（）函數(shù)接受可能包含相對路徑的字符串，并將它轉換成指同一文件的字符串，但是通過絕對路徑。在做這件事時，它展開了所有符號鏈接。

該函數(shù)取兩個自變量，第一個作為要規(guī)范化的字符串，第二個作為將存儲結果的緩沖區(qū)。當然，需要確保結果緩沖區(qū)足夠大，以處理任何大小的路徑。分配的MAXPATHLEN緩沖區(qū)應該足夠大。然而，使用realpath（）有另一個問題。如果傳遞給它的、要規(guī)范化的路徑大小大于MAXPATHLEN，則realpath（）實現(xiàn)內(nèi)部的靜態(tài)緩沖區(qū)會溢出！雖然實際上沒有訪問溢出的緩沖區(qū)，但無論如何它會傷害您的。結果是，應該明確不使用realpath（），除非確保檢查您試圖規(guī)范化的路徑長度不超過MAXPATHLEN。

其它廣泛可用的調用也有類似的問題。經(jīng)常使用的syslog（）調用也有類似的問題，直到不久前，才注意到這個問題并修正了它。大多數(shù)機器上已經(jīng)糾正了這個問題，但您不應該依賴正確的行為。最好總是假定代碼正運行在可能最不友好的環(huán)境中，只是萬一在哪天它真的這樣。getopt（）系列調用的各種實現(xiàn)，以及getpass（）函數(shù)，都可能產(chǎn)生內(nèi)部靜態(tài)緩沖區(qū)溢出問題。如果您不得不使用這些函數(shù)，最佳解決方案是設置傳遞給這些函數(shù)的輸入長度的閾值。

自己模擬gets（）的安全性問題以及所有問題是非常容易的。例如，下面這段代碼：

char buf［1024］;int i = 0;char ch;while（（ch = getchar（）） ！= ‘\n’）{ if（ch == -1） break; buf［i++］ = ch;}

哎呀！可以用來讀入字符的任何函數(shù)都存在這個問題，包括getchar（）、fgetc（）、getc（） 和 read（）。

緩沖區(qū)溢出問題的準則是：總是確保做邊界檢查。

C 和 C++ 不能夠自動地做邊界檢查，這實在不好，但確實有很好的原因，來解釋不這樣做的理由。邊界檢查的代價是效率。一般來講，C 在大多數(shù)情況下注重效率。然而，獲得效率的代價是，C 程序員必須十分警覺，并且有極強的安全意識，才能防止他們的程序出現(xiàn)問題，而且即使這些，使代碼不出問題也不容易。

在現(xiàn)在，變量檢查不會嚴重影響程序的效率。大多數(shù)應用程序不會注意到這點差異。所以，應該總是進行邊界檢查。在將數(shù)據(jù)復制到您自己的緩沖區(qū)之前，檢查數(shù)據(jù)長度。同樣，檢查以確保不要將過大的數(shù)據(jù)傳遞給另一個庫，因為您也不能相信其他人的代碼！（回憶一下前面所討論的內(nèi)部緩沖區(qū)溢出。）

其它危險是什么？遺憾的是，即使是系統(tǒng)調用的“安全”版本 ― 譬如，相對于strcpy（）的strncpy（）也不完全安全。也有可能把事情搞糟。即使安全的調用有時會留下未終止的字符串，或者會發(fā)生微妙的相差一位錯誤。當然，如果您偶然使用比源緩沖區(qū)小的結果緩沖區(qū)，則您可能發(fā)現(xiàn)自己處于非常困難的境地。

與我們目前所討論的相比，往往很難犯這些錯誤，但您應該仍然意識到它們。當使用這類調用時，要仔細考慮。如果不仔細留意緩沖區(qū)大小，包括bcopy（）、fgets（）、memcpy（）、snprintf（）、strccpy（）、strcadd（）、strncpy（） 和 vsnprintf（），許多函數(shù)會行為失常。

另一個要避免的系統(tǒng)調用是 getenv（）。使用getenv（） 的最大問題是您從來不能假定特殊環(huán)境變量是任何特定長度的。我們將在后續(xù)的專欄文章中討論環(huán)境變量帶來的種種問題。

到目前為止，我們已經(jīng)給出了一大堆常見 C 函數(shù)，這些函數(shù)容易引起緩沖區(qū)溢出問題。當然，還有許多函數(shù)有相同的問題。特別是，注意第三方 COTS 軟件。不要設想關于其他人軟件行為的任何事情。還要意識到我們沒有仔細檢查每個平臺上的每個常見庫（我們不想做那一工作），并且還可能存在其它有問題的調用。

即使我們檢查了每個常見庫的各個地方，如果我們試圖聲稱已經(jīng)列出了將在任何時候遇到的所有問題，則您應該持非常非常懷疑的態(tài)度。我們只是想給您起一個頭。其余全靠您了。

靜態(tài)和動態(tài)測試工具我們將在以后的專欄文章中更加詳細地介紹一些脆弱性檢測的工具，但現(xiàn)在值得一提的是兩種已被證明能有效幫助找到和去除緩沖區(qū)溢出問題的掃描工具。這兩個主要類別的分析工具是靜態(tài)工具（考慮代碼但永不運行）和動態(tài)工具（執(zhí)行代碼以確定行為）。

可以使用一些靜態(tài)工具來查找潛在的緩沖區(qū)溢出問題。很糟糕的是，沒有一個工具對一般公眾是可用的！許多工具做得一點也不比自動化 grep 命令多，可以運行它以找到源代碼中每個有問題函數(shù)的實例。由于存在更好的技術，這仍然是高效的方式將幾萬行或幾十萬行的大程序縮減到只有數(shù)百個“潛在的問題”。（在以后的專欄文章中，將演示一個基于這種方法的、草草了事的掃描工具，并告訴您有關如何構建它的想法。）

較好的靜態(tài)工具利用以某些方式表示的數(shù)據(jù)流信息來斷定哪個變量會影響到其它哪個變量。用這種方法，可以丟棄來自基于 grep 的分析的某些“假肯定”。David Wagner 在他的工作中已經(jīng)實現(xiàn)了這樣的方法（在“Learning the basics of buffer overflows”中描述；請參閱 參考資料），在 Reliable Software Technologies 的研究人員也已實現(xiàn)。當前，數(shù)據(jù)流相關方法的問題是它當前引入了假否定（即，它沒有標志可能是真正問題的某些調用）。

第二類方法涉及動態(tài)分析的使用。動態(tài)工具通常把注意力放在代碼運行時的情況，查找潛在的問題。一種已在實驗室使用的方法是故障注入。這個想法是以這樣一種方式來檢測程序：對它進行實驗，運行“假設”游戲，看它會發(fā)生什么。有一種故障注入工具 ― FIST（請參閱 參考資料）已被用來查找可能的緩沖區(qū)溢出脆弱性。

最終，動態(tài)和靜態(tài)方法的某些組合將會給您的投資帶來回報。但在確定最佳組合方面，仍然有許多工作要做。

Java 和堆棧保護可以提供幫助堆棧搗毀是最惡劣的一種緩沖區(qū)溢出攻擊，特別是，當在特權模式下?lián)v毀了堆棧。這種問題的優(yōu)秀解決方案是非可執(zhí)行堆棧。通常，利用代碼是在程序堆棧上編寫，并在那里執(zhí)行的。（我們將在下一篇專欄文章中解釋這是如何做到的。）獲取許多操作系統(tǒng)（包括 Linux 和 Solaris）的非可執(zhí)行堆棧補丁是可能的。（某些操作系統(tǒng)甚至不需要這樣的補丁；它們本身就帶有。）

非可執(zhí)行堆棧涉及到一些性能問題。（沒有免費的午餐。）此外，在既有堆棧溢出又有堆溢出的程序中，它們易出問題。可以利用堆棧溢出使程序跳轉至利用代碼，該代碼被放置在堆上。沒有實際執(zhí)行堆棧中的代碼，只有堆中的代碼。

當然，另一種選項是使用類型安全的語言，譬如 Java。較溫和的措施是獲取對 C 程序中進行數(shù)組邊界檢查的編譯器。對于 gcc 存在這樣的工具。這種技術可以防止所有緩沖區(qū)溢出，堆和堆棧。不利的一面是，對于那些大量使用指針、速度是至關重要的程序，這種技術可能會影響性能。但是在大多數(shù)情況下，該技術運行得非常好。

Stackguard 工具實現(xiàn)了比一般性邊界檢查更為有效的技術。它將一些數(shù)據(jù)放在已分配數(shù)據(jù)堆棧的末尾，并且以后會在緩沖區(qū)溢出可能發(fā)生前，查看這些數(shù)據(jù)是否仍然在那里。這種模式被稱之為“金絲雀”。（威爾士的礦工將 金絲雀放在礦井內(nèi)來顯示危險的狀況。當空氣開始變得有毒時，金絲雀會昏倒，使礦工有足夠時間注意到并逃離。）

Stackguard 方法不如一般性邊界檢查安全，但仍然相當有用。Stackguard 的主要缺點是，與一般性邊界檢查相比，它不能防止堆溢出攻擊。一般來講，最好用這樣一個工具來保護整個操作系統(tǒng)，否則，由程序調用的不受保護庫（譬如，標準庫）可以仍然為基于堆棧的利用代碼攻擊打開了大門。

類似于 Stackguard 的工具是內(nèi)存完整性檢查軟件包，譬如，Rational 的 Purify。這類工具甚至可以保護程序防止堆溢出，但由于性能開銷，這些工具一般不在產(chǎn)品代碼中使用。

結束語下面表格總結了一些編程構造，我們建議你小心使用或避免使用它們。如果要想代碼健壯，最好有一定容錯處理最好，比如之前給大家分享過的《斷言》。

函數(shù)嚴重性解決方案

gets最危險使用 fgets（buf， size， stdin）。這幾乎總是一個大問題！

strcpy很危險改為使用 strncpy。

strcat很危險改為使用 strncat。

sprintf很危險改為使用 snprintf，或者使用精度說明符。

scanf很危險使用精度說明符，或自己進行解析。

sscanf很危險使用精度說明符，或自己進行解析。

fscanf很危險使用精度說明符，或自己進行解析。

vfscanf很危險使用精度說明符，或自己進行解析。

vsprintf很危險改為使用 vsnprintf，或者使用精度說明符。

vscanf很危險使用精度說明符，或自己進行解析。

vsscanf很危險使用精度說明符，或自己進行解析。

streadd很危險確保分配的目的地參數(shù)大小是源參數(shù)大小的四倍。

strecpy很危險確保分配的目的地參數(shù)大小是源參數(shù)大小的四倍。

strtrns危險手工檢查來查看目的地大小是否至少與源字符串相等。

realpath很危險（或稍小，取決于實現(xiàn)）分配緩沖區(qū)大小為 MAXPATHLEN。同樣，手工檢查參數(shù)以確保輸入?yún)?shù)不超過 MAXPATHLEN。

syslog很危險（或稍小，取決于實現(xiàn)）在將字符串輸入傳遞給該函數(shù)之前，將所有字符串輸入截成合理的大小。

getopt很危險（或稍小，取決于實現(xiàn)）在將字符串輸入傳遞給該函數(shù)之前，將所有字符串輸入截成合理的大小。

getopt_long很危險（或稍小，取決于實現(xiàn)）在將字符串輸入傳遞給該函數(shù)之前，將所有字符串輸入截成合理的大小。

getpass很危險（或稍小，取決于實現(xiàn)）在將字符串輸入傳遞給該函數(shù)之前，將所有字符串輸入截成合理的大小。

getchar中等危險如果在循環(huán)中使用該函數(shù)，確保檢查緩沖區(qū)邊界。

fgetc中等危險如果在循環(huán)中使用該函數(shù)，確保檢查緩沖區(qū)邊界。

read中等危險如果在循環(huán)中使用該函數(shù)，確保檢查緩沖區(qū)邊界。

bcopy中等危險如果在循環(huán)中使用該函數(shù)，確保檢查緩沖區(qū)邊界。

fgets低危險確保緩沖區(qū)大小與它所說的一樣大。

memcpy低危險確保緩沖區(qū)大小與它所說的一樣大。

snprintf低危險確保緩沖區(qū)大小與它所說的一樣大。

strccpy低危險確保緩沖區(qū)大小與它所說的一樣大。

strcadd低危險確保緩沖區(qū)大小與它所說的一樣大。

strncpy低危險確保緩沖區(qū)大小與它所說的一樣大。

getchar低危險確保緩沖區(qū)大小與它所說的一樣大。

vsnprintf低危險確保緩沖區(qū)大小與它所說的一樣大。