Windows 服務安全性兩大隱憂：互動式服務風險與 _alloca 堆疊溢位

議題二：_alloca 堆疊溢位拒絕服務攻擊

危險範例

void func(char* szData) {
    PVOID p = _alloca(lstrlen(szData)); // 攻擊者傳入超大字串 → 堆疊耗盡 → 例外 → 程式終止
    // use p
}

若在服務程式中，將導致服務掛掉，造成嚴重拒絕服務。

正確防護模式：結構化例外處理 (SEH) + _resetstkoflw

void func(char* szData) {
    __try {
        PVOID p = _alloca(lstrlen(szData));
        // use p
    }
    __except ((EXCEPTION_STACK_OVERFLOW == GetExceptionCode()) ?
              EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) {
        _resetstkoflw(); // 重置堆疊狀態，避免後續 Guard Page 失效
    }
}

延伸風險：ATL 字串轉換巨集

A2W、W2A、CW2CT 等巨集內部使用 _alloca。服務端程式碼嚴禁直接用於不可信輸入長度的字串。必須先驗證長度上限，或改用堆積配置 (new/malloc) 的安全轉換函式。

附錄：緩衝區重複使用導致明文洩漏 (經典競態條件)

加密流程若「同一緩衝區先存明文、再加密、再發送」，多執行緒下可能發生指令重排：

正常：載入明文 → 加密 → 發送密文
競態：載入明文 → 發送(明文!) → 加密

此錯誤曾存在於 IIS 4.0 SSL 實作，極罕見負載下洩漏一封明文封包。修正：嚴格分離明文緩衝區與密文緩衝區，發送前確認密文緩衝區已填充。

思考題：下列程式碼有何缺陷？

void ShuffleAndUpdate(char* szName, char* szPwd, DWORD index, DWORD d) {
    DWORD dwArray[32]; ZeroMemory(dwArray, sizeof(dwArray));
    BOOL fAllowAccess = FALSE;
    if (IsValidUser(szName, szPwd)) {
        fAllowAccess = TRUE;
        ShuffleArray(dwArray, szName);
    }
    dwArray[index] = d;               // 潛在索引越界 (index >= 32)
    if (fAllowAccess) { /* 敏感操作 */ }
}

答案： 1) index 未驗證邊界，導致緩衝區溢位。2) ShuffleArray 若修改 dwArray 大小/邏輯，後續 dwArray[index] 更不可預期。3) 敏感操作應在驗證通過且所有輸入經過完整性檢查後才執行。