1. 概述

   在前面的安全編碼實踐的文章裡，我們討論了GS編譯選項，資料執行保護DEP功能，以及靜態程式碼分析工具Prefast。這裡，我們討論在C/C++程式碼中禁用危險的API，其主要目的是為了減少程式碼中引入安全漏洞的可能性。

2. 那些是危險的API

2.1歷史

   在微軟產品的安全漏洞中，有很大一部分是由於不正確的使用C動態庫（C Runtime Library）的函式，特別是有關字串處理的函式導致的。表一給出了微軟若干由於不當使用C動態庫函式而導致的安全漏洞【1，p242】。 

表1：不當使用C動態庫函式而導致的安全漏洞

   不當使用C動態庫函式容易引入安全漏洞，這一點並不奇怪。C動態庫函式的設計大約是30年前的事情了。當時，安全方面的考慮並不是設計上需要太多注意的地方。

2.2

   在這裡我們列出其中的一部分，以便大家對那些API被禁用有所體會。 

表2：禁用API的列表（部分）

   其它被禁用的API還有scanf, strtok, gets, itoa等等。 ”n”系列的字串處理函式，例如strncpy等，也在被禁用之列。

3. 如何替代被禁用的危險API

   從上面的介紹可以看出絕大多數C動態庫中的字串處理函式都被禁用。那麼，如何在程式碼中替代這些危險的API呢？在表2裡，我們看到有兩種替代方案：

• • StrSafe
  • Safe CRT

   後面我們會討論這兩種方案的不同之處。這裡我們先說它們的共同點：提供更安全的字串處理功能。特別在以下幾個方面：

• • 目標快取區的大小被顯式指明。
  • 動態校驗。
  • 返回程式碼。

   以StringCchCopy舉例。它的定義如下：

HRESULT StringCchCopy(         

    LPTSTR pszDest,

    size_t cchDest,

    LPCTSTR pszSrc

);

   cchDest指明目標快取區pszDest最多能容納字元的數目，其值必須在1和STRSAFE_MAX_CCH之間。StringCchCopy總是確保pszDest被拷貝的字串是以NULL結尾。並且提供以下的返回程式碼： S_OK，STRSAFE_E_INVALID_PARAMETER，和STRSAFE_E_INSUFFICIENT_BUFFER。這樣，採用StringCchCopy來替代被禁用的strcpy的話，就可以有效降低由於誤用字串拷貝而導致快取溢位的可能。

3.1使用StrSafe

   使用StrSafe非常簡單。在C/C++程式碼中加入以下的標頭檔案即可。

#include "strsafe.h"

   StrSafe.h包含在Windows Platform SDK中。使用者可以通過在微軟的網站直接下載。 

   下面給出一個使用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);

}

   在以上程式碼裡存在著幾個問題：首先，沒有錯誤程式碼的校驗。更嚴重的是，在strncat中，cchPath是目標快取區可以存放字元的最大數目，而正確傳遞的引數應該是目標快取區剩餘的字元數目。 

   使用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;

}

3.2使用Safe CRT

   SafeCRT自Visual Studio 2005起開始支援。當代碼中使用了禁用的危險的CRT函式，Visual Studio 2005編譯時會報告相應警告資訊，以提醒開發人員考慮將其替代為Safe CRT中更為安全的函式。 

   下面給出一個使用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"...");

}

3.3 StrSafe 和Safe CRT的對比

   我們看到，StrSafe和Safe CRT存在功能重疊的地方。那麼什麼時候使用StrSafe，什麼時候使用SafeCRT呢？

   下面的表格【1，p246】裡列出了兩者之間的差異。採用何種方式應該根據具體情況而定。有時候也許只能採取其中一種方式：例如如果你的開發系統是Visual Studio 2003的話，就只能使用StrSafe。或者你的程式碼中有許多itoa的話，就考慮使用Safe CRT，因為StrSafe中沒有提供簡單的替代方式。有時候也許兩者都可以。這種情況下，我個人是更喜歡採用StrSafe這種方式，因為它不依賴具體的動態庫支援。如果是編寫Win32上的程式的話，StrSafe的HRESULT的返回程式碼，也和Win32 API的程式碼類似，這樣程式碼的整體風格可能會更加一致。

表3：StrSafe和Safe CRT對比

4. 爭論

    在開發過程中，程式碼中全面禁用危險的API的編碼實踐，存在著一定的爭議性。其中最具有代表性的觀點可以參見Danny Kalev的Visual C++ 8.0 Hijacks the C++ Standard一文【4】。爭論主要集中在以下幾點。

4.1對於程式效能的影響

    以StrSafe舉例，由於增加了更多的動態校驗，其速度較C動態庫的函式相比，是有所下降的。在【2】一文中，給出了對StrSafe速度方面的測試資料如下： 

    測試例子：1千萬次字串合併呼叫。結果：

    C動態庫：7.3秒

    StrSafe：8.3秒 

    我們看到，如果開發的系統不是完全以字串處理為工作核心的話，使用StrSafe對系統性能的影響是可以控制的。

4.2開發人員可以決定在合適的地方使用危險API

    首先，同意如果程式碼中正確使用危險API的話，也是可以避免安全漏洞的引入。但是，在具體的開發實踐中，存在著以下問題：

• • 開發人員的素質和培訓
  • 有時候即使執行嚴格的程式碼複查，仍然可能由於使用危險的API而引入安全漏洞。

    第二點尤其關鍵。大家看到這裡可能會有疑問，使用危險的API有這麼容易出問題嗎？即便程式碼複查（code review）也沒能看出來？【5】中給出了一個微軟安全漏洞的具體例項。 

    微軟 05-047 Plug-n-Play RPC：即插即用中的漏洞，允許遠端執行程式碼和特權提升。經過身份驗證的攻擊者可以通過建立特製的網路訊息並將該訊息傳送到受影響的系統來嘗試利用此漏洞。導致這個嚴重的安全漏洞的程式碼如下：

#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);}

    複查這段程式碼時，我們看到，雖然使用了危險的API：wsprintf，但應該是不會發生快取溢位的問題。這是因為根據MSDN，

圖1：登錄檔字元數目的限制

    於是：

• • pszDevice 應該少於255 characters
  • pszDevice 是一個有效的 key 在HKLM/System/CurrentControlSet/Enum
  • szInstance 是一個有效的subkey在pszDevice下
  • RegStr is 360 characters
  • 攻擊者並不能控制登錄檔內容

    但實際上，wspringf還是導致了快取溢位的安全漏洞。到底是怎麼回事？我們來看一下攻擊程式碼：

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;

}

    攻擊程式碼之所以有效，是因為：

• • pszFilter(除去末位的0) 作為pszDevice 傳遞給GetInstanceList
  • RegOpenKeyEx 接收了這個長字串，忽略那些“/”，返回 ERROR_SUCCESS。

    通過這個例子我們看出，在開發複雜的系統中，即便是有經驗的開發人員，加上嚴格的程式碼複查過程，還是有可能由於使用危險的API而導致安全漏洞的引入。這也是微軟在Windows Vista的開發過程中全面禁用危險API的原因。

4.3程式可移植性的影響

   這一點的考慮是非常值得重視的。不管是StrSafe，還是Safe CRT，都不是工業界標準。因此，如果開發的系統需要移植到其它平臺的話，採用Safe CRT是肯定不合適的。StrSafe的Inline方式，因為不依賴特定庫，對可移植性的影響相對較小。

5. 總結

   在C/C++程式中禁用危險的API，可以有效降低在程式碼中引入安全漏洞的可能。在考慮了效能和可移植性的因素下，強烈建議在開發過程中，使用StrSafe或Safe CRT中對應的安全函式來替代被禁用的危險的API呼叫。

6. 參考文獻

1. The Security Development Lifecycle: SDL, Michael Howard; Steve Lipner, Microsoft
2. 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
3. School of hard knocks: things you can learn from working with MSRC, PhNeutral 0x7d7, Damian Hasse, Microsoft