本週二，微軟發佈了CVE-2014-6321補丁，該補丁被炒作為下一個心血。此漏洞（實際上至少有2個漏洞）承諾在使用SChannel安全服務提供者（如Microsoft Internet Information Services（IIS））的應用程序中執行遠程程式碼。

細節很少。讓我們來解决這個問題。

在schannel.dll的bindiff中，我們看到了一些已更改的函數，一些觸及了DTLSCookieManager類和其他各種函數。DTLSCookieManager中至少解决了一個錯誤，但這一個是針對不同時間的。每個人都在擔心的似乎是在夏尼爾！解碼。

下麵是DecodeSigAndReverse（…）更改的高級視圖。

在這裡，我們可以看到一些新的邏輯（灰色塊）添加到中間的修補功能（右側）。新增分支總是一個好兆頭。如果我們放大修補過的版本，情况看起來更有希望。

我們現在可以看到，添加的邏輯控制著一個memcpy的路徑（實際上是兩個memcpy——它們不都適合螢幕截圖）。這表明我們在找對地方。

那我們怎麼到這裡？讓我們在未修補的schannel.dll版本中查看此函數的路徑

囙此，似乎我們需要點擊“ProcessHandshake”，然後創建一個“ClientVerifyMessage”，以便點擊更改的程式碼。為了實現這一點，我們可能應該查看MSDN上的TLS/SSL檔案。

給定程式碼路徑中函數的名稱，我們處理證書驗證消息（涉及證書驗證）是有意義的。如果我們仔細觀察未修補的函數，可以從CryptDecodeObject調用中的lpszStructType參數獲得一個關鍵線索。

通過快速訪問MSDN，我們可以看到這個參數告訴我們需要什麼樣的結構。在這種情況下，我們有X509_ECC_簽名和X509_DSS_簽名。根據ECC_簽名，預期的結構在MSDN上定義

似乎其中一個memcpy的size參數可能有問題，可能與對證書進行編碼有關。

在這一點上，我們知道，最快的方法是動態地（用調試器）查看這個函數。囙此，我們創建了一個帶有OpenSSL的ECDSA簽名證書，並在啟用證書身份驗證的情况下安裝了Microsoft IIS。然後，我們將遠程調試器附加到IIS框上的LSASS行程，並中斷ECC_簽名比較（cmp ebx，2F）。

令人驚訝的是，第一次嘗試使用openssl s_客戶機進行身份驗證時觸發了中斷點！

既然我們可以找到錯誤的程式碼，下一步就是讓一些很酷的事情在這裡發生。同樣，為了加快分析速度，我們决定修改OpenSSL來模糊這個程式碼路徑。

在OpenSSL中，“client verify messages”的ECDSA簽名在原始檔案s3_clnt.c中處理。來自用戶端的編碼簽名最終在schannel中命中CryptDecodeObject（…）調用！DecodeSigAndReverse（…）來自一個名為ECDSA_sign（…）的函數。如果我們在函數ssl3_send_client_verify（…）中徘徊，該函數最終調用ECDSA_sign（…），我們將到達這個塊，它實際上為我們的client verify消息處理ECDSA簽名：

為了澄清此調用，ECDSA_sign的函數原型如下：

通過閱讀該函數的檔案，我們瞭解到“……DER編碼的簽名存儲在sig中，其長度返回在sig中。”

囙此，如果我們要使用openssl s_用戶端對我們的IIS框進行身份驗證，然後單步通過schannel！DecodeSigAndReverse（…），我們將看到上面對ECDSA_sign（…）的調用中的“p”內容被傳遞給schannel中的CryptDecodeObject（…），然後將其翻譯並傳遞給壞的memcpy塊。

所以，我們真正需要做的就是編輯s3_clnt.c，在一次又一次地將證書驗證消息發送回IIS之前，將“p”中的一個位元組隨機更改為一個隨機值，並等待發生酷的事情。

如果我們等的時間够長的話，我們會在memcpy上崩潰的。

進一步的分析和利用留給讀者作為練習。