整型溢出有點老生常談了，但似乎沒有引起多少人的重視。
整型溢出會有可能導致緩沖區(qū)溢出，緩沖區(qū)溢出會導致各種黑客攻擊，比如最近OpenSSL的heartbleed事件，就是一個buffer overread的事件。在這里寫下這篇文章，希望大家都了解一下整型溢出，編譯器的行為，以及如何防范，以寫出更安全的代碼。
什么是整型溢出
C語言的整型問題相信大家并不陌生了。對于整型溢出，分為無符號整型溢出和有符號整型溢出。
對于unsigned整型溢出，C的規(guī)范是有定義的——“溢出后的數(shù)會以2^(8*sizeof(type))作模運算”，也就是說，如果一個unsigned char（1字符，8bits）溢出了，會把溢出的值與256求模。例如：
unsigned?char?x = 0xff;
printf("%d\n", ++x);
上面的代碼會輸出：0 （因為0xff + 1是256，與2^8求模后就是0）
對于signed整型的溢出，C的規(guī)范定義是“undefined behavior”，也就是說，編譯器愛怎么實現(xiàn)就怎么實現(xiàn)。對于大多數(shù)編譯器來說，算得啥就是啥。比如：
signed?char?x =0x7f; //注：0xff就是-1了，因為最高位是1也就是負數(shù)了
printf("%d\n", ++x);
上面的代碼會輸出：-128，因為0x7f + 0x01得到0x80，也就是二進制的1000 0000，符號位為1，負數(shù)，后面為全0，就是負的最小數(shù)，即-128。
另外，千萬別以為signed整型溢出就是負數(shù)，這個是不定的。比如：
signed?char?x = 0x7f;
signed?char?y = 0x05;
signed?char?r = x * y;
printf("%d\n", r);
上面的代碼會輸出：123
相信對于這些大家不會陌生了。
整型溢出的危害
下面說一下，整型溢出的危害。
示例一：整形溢出導致死循環(huán)
short?len = 0;
while(len< MAX_LEN) {
len += readFromInput(fd, buf);
buf += len;
}
上面這段代碼可能是很多程序員都喜歡寫的代碼（我在很多代碼里看到過多次），其中的MAX_LEN 可能會是個比較大的整型，比如32767，我們知道short是16bits，取值范圍是-32768 到 32767 之間。但是，上面的while循環(huán)代碼有可能會造成整型溢出，而len又是個有符號的整型，所以可能會成負數(shù)，導致不斷地死循環(huán)。
示例二：整形轉(zhuǎn)型時的溢出
int?copy_something(char?*buf,?int?len)
{
#define MAX_LEN 256
char?mybuf[MAX_LEN];
if(len > MAX_LEN){ // <---- [1]
return?-1;
}
return?memcpy(mybuf, buf, len);
}
上面這個例子中，還是[1]處的if語句，看上去沒有會問題，但是len是個signed int，而memcpy則需一個size_t的len，也就是一個unsigned 類型。于是，len會被提升為unsigned，此時，如果我們給len傳一個負數(shù)，會通過了if的檢查，但在memcpy里會被提升為一個正數(shù)，于是我們的mybuf就是overflow了。這個會導致mybuf緩沖區(qū)后面的數(shù)據(jù)被重寫。
示例三：分配內(nèi)存
關(guān)于整數(shù)溢出導致堆溢出的很典型的例子是，OpenSSH Challenge-Response SKEY/BSD_AUTH 遠程緩沖區(qū)溢出漏洞。下面這段有問題的代碼摘自O(shè)penSSH的代碼中的auth2-chall.c中的input_userauth_info_response() 函數(shù):
nresp = packet_get_int();
if?(nresp > 0) {
response = xmalloc(nresp*sizeof(char*));
for?(i = 0; i < nresp; i++)
response[i] = packet_get_string(NULL);
}
上面這個代碼中，nresp是size_t類型（size_t一般就是unsigned int/long int），這個示例是一個解數(shù)據(jù)包的示例，一般來說，數(shù)據(jù)包中都會有一個len，然后后面是data。如果我們精心準備一個len，比如：1073741825（在32位系統(tǒng)上，指針占4個字節(jié)，unsigned int的最大值是0xffffffff，我們只要提供0xffffffff/4 的值——0x40000000，這里我們設(shè)置了0x4000000 + 1）， nresp就會讀到這個值，然后nresp*sizeof(char*)就成了 1073741825 * 4，于是溢出，結(jié)果成為了 0x100000004，然后求模，得到4。于是，malloc(4)，于是后面的for循環(huán)1073741825 次，就可以干環(huán)事了（經(jīng)過0x40000001的循環(huán),用戶的數(shù)據(jù)早已覆蓋了xmalloc原先分配的4字節(jié)的空間以及后面的數(shù)據(jù)，包括程序代碼，函數(shù)指針，于是就可以改寫程序邏輯。關(guān)于更多的東西，你可以看一下這篇文章《Survey of Protections from Buffer-Overflow Attacks》）。
示例四：緩沖區(qū)溢出導致安全問題
int?func(char?*buf1, unsigned?int?len1,
char?*buf2, unsigned?int?len2 )
{
char?mybuf[256];
if((len1 + len2) > 256){ //<--- [1]
return?-1;
}
memcpy(mybuf, buf1, len1);
memcpy(mybuf + len1, buf2, len2);
do_some_stuff(mybuf);
return?0;
}
上面這個例子本來是想把buf1和buf2的內(nèi)容copy到mybuf里，其中怕len1 + len2超過256 還做了判斷，但是，如果len1+len2溢出了，根據(jù)unsigned的特性，其會與2^32求模，所以，基本上來說，上面代碼中的[1]處有可能為假的。（注：通常來說，在這種情況下，如果你開啟-O代碼優(yōu)化選項，那個if語句塊就全部被和諧掉了——被編譯器給刪除了）比如，你可以測試一下 len1=0x104， len2 = 0xfffffffc 的情況。
示例五：size_t 的溢出
for?(int?i=?strlen(s)-1; i>=0; i--) { ... }
for?(int?i=v.size()-1; i>=0; i--) { ... }
上面這兩個示例是我們經(jīng)常用的從尾部遍歷一個數(shù)組的for循環(huán)。第一個是字符串，第二個是C++中的vector容器。strlen()和vector::size()返回的都是 size_t，size_t在32位系統(tǒng)下就是一個unsigned int。你想想，如果strlen(s)和v.size() 都是0呢？這個循環(huán)會成為個什么情況？于是strlen(s) – 1 和 v.size() – 1 都不會成為 -1，而是成為了 (unsigned int)(-1)，一個正的最大數(shù)。導致你的程序越界訪問。
這樣的例子有很多很多，這些整型溢出的問題如果在關(guān)鍵的地方，尤其是在搭配有用戶輸入的地方，如果被黑客利用了，就會導致很嚴重的安全問題。
C語言中的一個大惡魔—— Undefined! 這里都是“野獸出沒”的地方，你一定要小心小心再小心。
其它
對于C++來說，你應該使用STL中的numeric_limits::max() 來檢查溢出。
可見，寫一個安全的代碼并不容易，尤其對于C/C++來說。對于黑客來說，他們只需要搜一下開源軟件中代碼有memcpy/strcpy之類的地方，然后看一看其周邊的代碼，是否可以通過用戶的輸入來影響，如果有的話，你就慘了。
最后， 不好意思，這篇文章可能羅嗦了一些，大家見諒。C/C++深度學習 私信我 “代碼” 獲取資料。
