轉(zhuǎn)自：
http://bbs.lvy8.cn/ShowPost_PR5339.html
程序員》9月文章
申明。文章僅代表個(gè)人觀點(diǎn)，與所在公司無任何聯(lián)系。
- 概述
在前面的安全編碼實(shí)踐的文章里，我們討論了GS編譯選項(xiàng)，數(shù)據(jù)執(zhí)行保護(hù)DEP功能，以及靜態(tài)代碼分析工具Prefast。這里，我們討論在C/C++代碼中禁用危險(xiǎn)的API，其主要目的是為了減少代碼中引入安全漏洞的可能性。
- 那些是危險(xiǎn)的API
在微軟產(chǎn)品的安全漏洞中，有很大一部分是由于不正確的使用C動態(tài)庫（C Runtime Library） 的函數(shù)，特別是有關(guān)字符串處理的函數(shù)導(dǎo)致的。表一給出了微軟若干由于不當(dāng)使用C動態(tài)庫函數(shù)而導(dǎo)致的安全漏洞【1，p242】。
| 微軟安全公告 |
涉及產(chǎn)品 |
涉及的函數(shù) |
| MS02-039 |
Microsoft SQL Server 2000 |
sprint |
| MS05-010 |
Microsoft License Server |
lstrcpy |
| MS04-011 |
Microsoft Windows (DCPromo) |
wvsprintf |
| MS04-011 |
Microsoft Windows (MSGina) |
lstrcpy |
| MS04-031 |
Microsoft Windows (NetDDE) |
wcscat |
| MS03-045 |
Microsoft Windows (USER) |
wcscpy |
表1：不當(dāng)使用C動態(tài)庫函數(shù)而導(dǎo)致的安全漏洞
不當(dāng)使用C動態(tài)庫函數(shù)容易引入安全漏洞，這一點(diǎn)并不奇怪。C動態(tài)庫函數(shù)的設(shè)計(jì)大約是30年前的事情了。當(dāng)時(shí)，安全方面的考慮并不是設(shè)計(jì)上需要太多注意的地方。
有關(guān)完整的危險(xiǎn)API的禁用列表，大家可以參見http://msdn.microsoft.com/en-us/library/bb288454.aspx.
在這里我們列出其中的一部分，以便大家對那些API被禁用有所體會。
<DIV align=left>
| 禁用的API |
替代的StrSafe函數(shù) |
替代的Safe CRT函數(shù) |
| 有關(guān)字符串拷貝的API |
| strcpy, wcscpy, _tcscpy, _mbscpy, StrCpy, StrCpyA, StrCpyW, lstrcpy, lstrcpyA, lstrcpyW, strcpyA, strcpyW, _tccpy, _mbccpy |
StringCchCopy, StringCbCopy,
StringCchCopyEx, StringCbCopyEx
|
strcpy_s |
| 有關(guān)字符串合并的API |
| strcat, wcscat, _tcscat, _mbscat, StrCat, StrCatA, StrCatW, lstrcat, lstrcatA, lstrcatW, StrCatBuffW, StrCatBuff, StrCatBuffA, StrCatChainW, strcatA, strcatW, _tccat, _mbccat |
StringCchCat, StringCbCat,
StringCchCatEx, StringCbCatEx
|
strcat_s |
| 有關(guān)sprintf的API |
| wnsprintf, wnsprintfA, wnsprintfW, sprintfW, sprintfA, wsprintf, wsprintfW, wsprintfA, sprintf, swprintf, _stprintf |
StringCchPrintf, StringCbPrintf,
StringCchPrintfEx, StringCbPrintfEx
|
_snprintf_s
_snwprintf_s
|
</DIV>
表2：禁用API的列表（部分）
其它被禁用的API還有scanf, strtok, gets, itoa等等。 ”n”系列的字符串處理函數(shù)，例如strncpy等，也在被禁用之列。
- 如何替代被禁用的危險(xiǎn)API
從上面的介紹可以看出絕大多數(shù)C動態(tài)庫中的字符串處理函數(shù)都被禁用。那么，如何在代碼中替代這些危險(xiǎn)的API呢？在表2里，我們看到有兩種替代方案：
后面我們會討論這兩種方案的不同之處。這里我們先說它們的共同點(diǎn)：提供更安全的字符串處理功能。特別在以下幾個(gè)方面：
- 目標(biāo)緩存區(qū)的大小被顯式指明。
- 動態(tài)校驗(yàn)。
- 返回代碼。
以StringCchCopy舉例。它的定義如下：
HRESULT StringCchCopy(
LPTSTR pszDest,
size_t cchDest,
LPCTSTR pszSrc
);
cchDest指明目標(biāo)緩存區(qū)pszDest最多能容納字符的數(shù)目，其值必須在1和STRSAFE_MAX_CCH之間。StringCchCopy總是確保pszDest被拷貝的字符串是以NULL結(jié)尾。并且提供以下的返回代碼： S_OK，STRSAFE_E_INVALID_PARAMETER，和STRSAFE_E_INSUFFICIENT_BUFFER。這樣，采用StringCchCopy來替代被禁用的strcpy的話，就可以有效降低由于誤用字符串拷貝而導(dǎo)致緩存溢出的可能。
使用StrSafe非常簡單。在C/C++代碼中加入以下的頭文件即可。
#include "strsafe.h"
StrSafe.h包含在Windows Platform SDK中。用戶可以通過在微軟的網(wǎng)站直接下載。
下面給出一個(gè)使用StrSafe的代碼示例【2】。
不安全的代碼：
void UnsafeFunc(LPTSTR szPath,DWORD cchPath) {
TCHAR szCWD[MAX_PATH];
GetCurrentDirectory(ARRAYSIZE(szCWD), szCWD);
strncpy(szPath, szCWD, cchPath);
strncat(szPath, TEXT("\\"), cchPath);
strncat(szPath, TEXT("desktop.ini"),cchPath);
}
在以上代碼里存在著幾個(gè)問題：首先，沒有錯(cuò)誤代碼的校驗(yàn)。更嚴(yán)重的是，在strncat中，cchPath是目標(biāo)緩存區(qū)可以存放字符的最大數(shù)目，而正確傳遞的參數(shù)應(yīng)該是目標(biāo)緩存區(qū)剩余的字符數(shù)目。
使用StrSafe后的代碼是
bool SaferFunc(LPTSTR szPath,DWORD cchPath) {
TCHAR szCWD[MAX_PATH];
if (GetCurrentDirectory(ARRAYSIZE(szCWD), szCWD) &&
SUCCEEDED(StringCchCopy(szPath, cchPath, szCWD)) &&
SUCCEEDED(StringCchCat(szPath, cchPath, TEXT("\\"))) &&
SUCCEEDED(StringCchCat(szPath, cchPath, TEXT("desktop.ini")))) {
return true;
}
return false;
}
SafeCRT自Visual Studio 2005起開始支持。當(dāng)代碼中使用了禁用的危險(xiǎn)的CRT函數(shù)，Visual Studio 2005編譯時(shí)會報(bào)告相應(yīng)警告信息，以提醒開發(fā)人員考慮將其替代為Safe CRT中更為安全的函數(shù)。
下面給出一個(gè)使用Safe CRT的代碼示例【3】。
不安全的代碼：
void UnsafeFunc (const wchar_t * src)
{
// Original
wchar_t dest[20];
wcscpy(dest, src); // 編譯警告
wcscat(dest, L"..."); // 編譯警告
}
以上這段代碼里存在著明顯緩存溢出的問題。
使用Safe CRT后的代碼是
errno_t SaferFunc(const wchar_t * src)
{
wchar_t dest[20];
errno_t err = wcscpy_s(dest, _countof(dest), src);
if (!err)
return err;
return wcscat_s(dest, _countof(dest), L"...");
}
我們看到，StrSafe和Safe CRT存在功能重疊的地方。那么什么時(shí)候使用StrSafe，什么時(shí)候使用SafeCRT呢？
下面的表格【1，p246】里列出了兩者之間的差異。采用何種方式應(yīng)該根據(jù)具體情況而定。有時(shí)候也許只能采取其中一種方式：例如如果你的開發(fā)系統(tǒng)是Visual Studio 2003的話，就只能使用StrSafe。或者你的代碼中有許多itoa的話，就考慮使用Safe CRT，因?yàn)?/font>StrSafe中沒有提供簡單的替代方式。有時(shí)候也許兩者都可以。這種情況下，我個(gè)人是更喜歡采用StrSafe這種方式，因?yàn)樗灰蕾嚲唧w的動態(tài)庫支持。如果是編寫Win32上的程序的話，StrSafe的HRESULT的返回代碼，也和Win32 API的代碼類似，這樣代碼的整體風(fēng)格可能會更加一致。
<DIV align=left>
| |
StrSafe |
Safe CRT |
| 發(fā)布方式 |
Web |
Microsoft Visual Studio 2005 |
| 頭文件 |
一個(gè) (StrSafe.h) |
多個(gè) (不同的 C runtime 頭文件) |
| 是否提供鏈接庫的版本 |
是 |
是 |
| 是否提供內(nèi)嵌（Inline）版本 |
是 |
否 |
| 是否是業(yè)界標(biāo)準(zhǔn) |
否 |
正在評估過程 |
| Kernel Mode支持 |
是 |
否 |
| 返回類型 |
HRESULT (user mode)
NTSTATUS (kernel mode)
|
隨函數(shù)變化，errno_t |
| 是否需要修改代碼 |
是 |
是 |
| 主要針對 |
緩存溢出 |
緩存溢出，和其它安全方面的考慮 |
</DIV>
表3：StrSafe和Safe CRT對比
- 爭論
在開發(fā)過程中，代碼中全面禁用危險(xiǎn)的API的編碼實(shí)踐，存在著一定的爭議性。其中最具有代表性的觀點(diǎn)可以參見Danny Kalev的Visual C++ 8.0 Hijacks the C++ Standard一文【4】。爭論主要集中在以下幾點(diǎn)。
以StrSafe舉例，由于增加了更多的動態(tài)校驗(yàn)，其速度較C動態(tài)庫的函數(shù)相比，是有所下降的。在【2】一文中，給出了對StrSafe速度方面的測試數(shù)據(jù)如下：
測試?yán)樱?/font>1千萬次字符串合并調(diào)用。結(jié)果：
C動態(tài)庫：7.3秒
StrSafe：8.3秒
我們看到，如果開發(fā)的系統(tǒng)不是完全以字符串處理為工作核心的話，使用StrSafe對系統(tǒng)性能的影響是可以控制的。
首先，同意如果代碼中正確使用危險(xiǎn)API的話，也是可以避免安全漏洞的引入。但是，在具體的開發(fā)實(shí)踐中，存在著以下問題：
- 開發(fā)人員的素質(zhì)和培訓(xùn)
- 有時(shí)候即使執(zhí)行嚴(yán)格的代碼復(fù)查，仍然可能由于使用危險(xiǎn)的API而引入安全漏洞。
第二點(diǎn)尤其關(guān)鍵。大家看到這里可能會有疑問，使用危險(xiǎn)的API有這么容易出問題嗎？即便代碼復(fù)查（code review）也沒能看出來？【5】中給出了一個(gè)微軟安全漏洞的具體實(shí)例。
微軟 05-047 Plug-n-Play RPC：即插即用中的漏洞，允許遠(yuǎn)程執(zhí)行代碼和特權(quán)提升。經(jīng)過身份驗(yàn)證的攻擊者可以通過創(chuàng)建特制的網(wǎng)絡(luò)消息并將該消息發(fā)送到受影響的系統(tǒng)來嘗試?yán)么寺┒础?wbr>導(dǎo)致這個(gè)嚴(yán)重的安全漏洞的代碼如下：
#define MAX_CM_PATH 360
GetInstanceList(
IN LPCWSTR pszDevice, IN OUT LPWSTR *pBuffer, IN OUT PULONG pulLength)
{
WCHAR RegStr[MAX_CM_PATH], szInstance[MAX_DEVICE_ID_LEN];
...
// Validate that passed in pszDevice is an actual registry entry
// If lookup for the key fails, reject call and cleanup.
// ghEnumKey points to HKLM\System\CurrentControlSet\Enum
if (RegOpenKeyEx(ghEnumKey, pszDevice, 0,
KEY_ENUMERATE_SUB_KEYS, &hKey) != ERROR_SUCCESS) {
Status = CR_REGISTRY_ERROR;
goto Clean0;
}
...
ulLen = MAX_DEVICE_ID_LEN; // size in chars
...
// Query szInstance from registry
RegStatus = RegEnumKeyEx(hKey, ulIndex, szInstance, &ulLen, ...);
if (RegStatus == ERROR_SUCCESS) {
// Build lookup string given a valid registry root key and valid instance ID
wsprintf(RegStr, TEXT("%s\\%s"), pszDevice, szInstance);}
復(fù)查這段代碼時(shí)，我們看到，雖然使用了危險(xiǎn)的API：wsprintf，但應(yīng)該是不會發(fā)生緩存溢出的問題。這是因?yàn)楦鶕?jù)MSDN，
圖1：注冊表字符數(shù)目的限制
于是：
- pszDevice 應(yīng)該少于255 characters
- pszDevice 是一個(gè) 有效的 key 在HKLM\System\CurrentControlSet\Enum
- szInstance 是一個(gè)有效的subkey在pszDevice下
- RegStr is 360 characters
- 攻擊者并不能控制注冊表內(nèi)容
但實(shí)際上，wspringf還是導(dǎo)致了緩存溢出的安全漏洞。到底是怎么回事？我們來看一下攻擊代碼：
errno_t SaferFunc(const wchar_t * src)
int main()
{
PWCHAR pszFilter = (PWCHAR)malloc(sizeof(WCHAR)*1000);
PWCHAR Buffer = (PWCHAR)malloc(86);
wsprintf(pszFilter,L"ISAPNP\\ReadDataPort\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\0");
CM_Get_Device_ID_List((PCWSTR)pszFilter,Buffer,86,1);
return 0;
}
攻擊代碼之所以有效，是因?yàn)椋?/font>
- pszFilter(除去末位的0) 作為pszDevice 傳遞給GetInstanceList
- RegOpenKeyEx 接收了這個(gè)長字符串，忽略那些“\”，返回 ERROR_SUCCESS。
通過這個(gè)例子我們看出，在開發(fā)復(fù)雜的系統(tǒng)中，即便是有經(jīng)驗(yàn)的開發(fā)人員，加上嚴(yán)格的代碼復(fù)查過程，還是有可能由于使用危險(xiǎn)的API而導(dǎo)致安全漏洞的引入。這也是微軟在Windows Vista的開發(fā)過程中全面禁用危險(xiǎn)API的原因。
這一點(diǎn)的考慮是非常值得重視的。不管是StrSafe，還是Safe CRT，都不是工業(yè)界標(biāo)準(zhǔn)。因此，如果開發(fā)的系統(tǒng)需要移植到其它平臺的話，采用Safe CRT是肯定不合適的。StrSafe的Inline方式，因?yàn)椴灰蕾囂囟◣欤瑢梢浦残缘挠绊懴鄬^小。
- 總結(jié)
在C/C++程序中禁用危險(xiǎn)的API，可以有效降低在代碼中引入安全漏洞的可能。在考慮了性能和可移植性的因素下，強(qiáng)烈建議在開發(fā)過程中，使用StrSafe或Safe CRT中對應(yīng)的安全函數(shù)來替代被禁用的危險(xiǎn)的API調(diào)用。
- 參考文獻(xiàn)
- The Security Development Lifecycle: SDL, Michael Howard; Steve Lipner, Microsoft
- Strsafe.h: Safer String Handling in C, http://msdn.microsoft.com/en-us/library/ms995353.aspx, Michael Howard, Microsoft
- Repel Attacks on Your Code with the Visual Studio 2005 Safe C and C++ Libraries, http://msdn.microsoft.com/en-us/magazine/cc163794.aspx, Martyn Lovell, Microsoft
- Visual C++ 8.0 Hijacks the C++ Standard, http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=259, Danny Kalev
- School of hard knocks: things you can learn from working with MSRC, PhNeutral 0x7d7, Damian Hasse, Microsoft