微軟不是修改源代碼來修複 bug 的？

當像微軟這樣的公司需要修複其中一個產品的安全漏洞時，這個過程通常很簡單：確定 bug 的位置，更改程序的源代碼來修複bug，然後重新編譯程序。但看起來該公司必須走出這一典型的過程來修複 bug。與修複源代碼不同，該公司的開發人員似乎對bug程序的可執行文件進行了一係列仔細的修改。

漏洞CVE-2017-11882是Office自帶的老舊公式編輯器中的緩衝區溢出。 公式編輯器分配固定大小的內存來保存字體名稱，然後將公式文件中的字體名稱複製到這段內存中。 但是，它不檢查確保字體名稱是否適合這段內存。 如果提供的字體名稱太長，公式編輯器會溢出緩衝區，破壞自己的內存，攻擊者可以使用它來執行任意的惡意代碼。

正常情況下，解決這個問題是先確定字體名稱的長度，並創建一個足夠大的緩衝區容納它。源代碼中，這是一個很簡單的更改。如果這是不可能的 - 偶爾會出現緩衝區不容易變大的情況 - 那麼下一個最好的解決辦法是限製複製到它的數據量，如果字體名太長而不適合，則截斷字體名。同樣，這也是在源代碼中進行的簡單更改。

但是微軟似乎不是這樣做的。

對微軟補丁的分析表明公司根本沒有修改源代碼。相反，它似乎是通過非常仔細地修改公式編輯器可執行程序本身來修複的。通常當一個程序被修改並重新編譯時，這個編譯會產生連鎖反應。編譯後的代碼的底層內容會稍微改變; 重新編譯的代碼將使用稍微不同的寄存器，函數將被放置在內存中的不同位置，等等。但這些都不是證據。對固定程序和原始版本的並行比較表明，除了幾個函數中的幾個字節之外，它幾乎完全沒有改變。唯一可能發生的情況是直接在程序二進製文件上執行 bug 修複，而不是修改源代碼。

這是很難完成的。固定版本包括一個額外的測試，以確保字體名稱不太長，如果長的話，將它截斷。做這個額外的測試意味著增加額外的指令給這個buggy函數，但是微軟需要在不讓函數更新更長的時間來保證其他的，相鄰的函數沒有被幹擾的情況下進行修複。為了為新的長度檢查留出空間，程序中複製字體名稱的部分被稍微地進行了優化，用稍微慢一點的程序替換了一個較快的例程，並且在這個過程中釋放了幾個字節。

檢查甚至表明，這不是微軟第一次做出這樣的修複; 有幾條指令被發現在原來的版本中被奇怪地複製了。如果先前的修改使程序的代碼稍微短一些，這種事情就會發生。

看公式編輯器的嵌入式版本信息也可以得出為什麼微軟在一開始就采用這種方法。它是一個第三方工具，由一家名為Design Science的公司在1990年至2000年開發。該公司仍然存在，仍然在用生產方程式編輯軟件，但是如果我們猜測，微軟要麼根本沒有源代碼，要麼就沒有權限來修複它。。

Word現在有自己的內置公式編輯功能，但公式編輯器仍然支持向後兼容性，以確保嵌入方程的舊文檔繼續可用。不過，我們對微軟修複它而不是完全刪除它感到有點驚訝。這確實是另一個時代的遺跡，比微軟在安全編碼實踐和利用緩解技術方麵的投入要早得多。公式編輯器缺少微軟近期對代碼的所有保護，使得它的缺陷比Word或Windows更容易被利用。這使它成為一種安全責任，如果這個字體錯誤是最後一個被發現的，我們會很難以置信。