編譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

距離 Windows 大范圍藍(lán)屏事件，已經(jīng)過去了 6 天。

這 6 天來，國內(nèi)外技術(shù)網(wǎng)站仍對此事熱議不斷，“罪魁禍?zhǔn)住?nbsp;CrowdStrike 的名字被頻繁提及，與之伴隨的無一不是質(zhì)疑和譴責(zé)：

• CrowdStrike 引發(fā)的系統(tǒng)故障導(dǎo)致數(shù)千架航班停飛、醫(yī)院癱瘓、支付系統(tǒng)崩潰，被專家稱為史上最大的 IT 故障。

• 據(jù) Parametrix 保險公司稱，CrowdStrike 錯誤更新引發(fā)的全球技術(shù)中斷，使美國財富 500 強企業(yè)（不包括微軟）面臨 54 億美元的經(jīng)濟損失，全球經(jīng)濟損失總額可能達到 150 億美元左右。

基于此，本周 CrowdStrike 的股價已迅速暴跌超 20%。出于對引發(fā)此次故障的歉意，據(jù)悉昨日 CrowdStrike 還向其合作方均提供了一張價值 10 美元的 Uber Eats 禮品卡作為道歉：“為了表達我們的歉意，你的下一杯咖啡或夜宵由我們請客！”不過，有收到該禮品卡的用戶表示，他們?nèi)稉Q時，頁面提示稱該禮品卡“已被發(fā)行方取消，不再有效”。

除了以上聚焦于 CrowdStrike 本身的關(guān)注和報道，近日還有一個話題也在開發(fā)者圈內(nèi)引起了不小的討論：”如果 CrowdStrike 改用 Rust 的話，全球 850 萬 PC 是不是就不會藍(lán)屏了？“

我驚訝地發(fā)現(xiàn)，過去幾天發(fā)生的所有事情都是由 null deref 這樣簡單的錯誤引起的。數(shù)十年來，業(yè)界一直在使用 C++，所有的工具、linters、sanitizers、測試和同行評審都不足以避免這種情況的發(fā)生。因此我在想，如果改用 Rust，情況是否會大不一樣？

不僅如此，微軟 Azure 部門 CTO Mark Russinovich 也在事發(fā)后轉(zhuǎn)了一條他 發(fā)布于 2022 年的推文：“說到語言，現(xiàn)在是時候停止用 C/C++ 啟動任何新項目了，請在需要使用非 GC 語言的情況下使用 Rust。為了安全性和可靠性，業(yè)界應(yīng)該宣布這些語言已被淘汰。”

眼看著不少 Rust 狂熱愛好者開始放話“沒錯，Rust 就是唯一答案”，一位同樣喜歡 Rust 的資深軟件工程師 Julio Merino，在理智地進行了一番全盤分析后得出結(jié)論：“就算是 Rust，也救不了這次 CrowdStrike 的中斷事故。”

以下為譯文：

我非常喜歡 Rust，也很贊同不應(yīng)繼續(xù)使用 C++ 這類內(nèi)存不安全的編程語言，但我還是要說：那些聲稱用 Rust 就可以避免上周五全球大面積網(wǎng)絡(luò)中斷的說法太夸張了，對 Rust 的口碑有害無益。

如果 CrowdStrike 是用 Rust 編寫的，那確實可以降低發(fā)生故障的可能性，但它并不能解決導(dǎo)致故障發(fā)生的根本原因。所以看到許多人說 Rust 是解決這次事故的唯一答案，我就感到非常惱火——這種說法，不僅無法推動 Rust 的普及，反而會招來反感：C++ 專家們都知道本次事故的根本原因，看到這種誤導(dǎo)性說法必然不快，從而導(dǎo)致系統(tǒng)編程世界的進一步分裂。

那么，為什么說 Rust 不能解決這個問題呢？接下來我會試著回答這個問題，同時也深入探討一下造成這次故障的原因。

故障分析

以下是來自 CrowdStrike 官方的“事后分析”：

在 2024 年 7 月 19 日 04:09 UTC，作為持續(xù)運營的一部分，CrowdStrike 向 Windows 系統(tǒng)發(fā)布了傳感器配置更新。傳感器配置更新是 Falcon 平臺保護機制的持續(xù)組成部分。此配置更新觸發(fā)了邏輯錯誤，導(dǎo)致受影響的系統(tǒng)崩潰和藍(lán)屏（BSOD）

導(dǎo)致系統(tǒng)崩潰的傳感器配置更新，已于 2024 年 7 月 19 日 05:27 UTC 得到修復(fù)。

把上面這段話翻譯為“人話”，就是：

1、CrowdStrike 公司推送了一項配置更新。

2、該更新觸發(fā)了“Falcon 平臺”中的一個潛在 bug。

3、Falcon 中的這個 bug 導(dǎo)致了 Windows 崩潰。

前兩點并不奇怪：對于任何在線系統(tǒng)來說，變更配置都是“家常便飯”，而這些更新引發(fā)代碼中的 bug 也是常見現(xiàn)象。事實上，大多數(shù)宕機事件都是由人為配置變更造成的。

顯然，我們應(yīng)該問問為什么這個 bug 會存在，以及如何修復(fù)它以提高產(chǎn)品的穩(wěn)定性。但我們別忘了第三點：為什么這個 bug 能夠?qū)е抡_機器癱瘓？更重要的是，為什么這個 bug 會讓全球如此多的系統(tǒng)宕機？

內(nèi)存錯誤

讓我們從第一個問題開始：Falcon 中的 bug 是什么性質(zhì)的？

很簡單：在“Channel Files”（又稱配置文件）解析器中存在一個邏輯錯誤，當(dāng)遇到一些無效輸入時，這段代碼會試圖訪問一個無效的內(nèi)存位置。具體細(xì)節(jié)并不重要：可能是取消引用空指針，也可能是一般保護故障等等。關(guān)鍵在于：崩潰是由無效內(nèi)存訪問問題引發(fā)的。

這時，一些 Rust 狂熱粉可能會跳出來說：：“看啊，果然！如果代碼是用 Rust 寫的，這個 bug 就不會存在！”我無法否認(rèn)這個說法：如果用 Rust，這個特定的 bug 確實不會出現(xiàn)。

但那又怎樣？就算避免了這種類型的 bug，下一次遇到 Rust 也無法避免的 bug 時，該宕機還是會宕機——無視 Falcon 的本質(zhì)問題、只關(guān)注內(nèi)存錯誤的行為，好比“只見樹木，不見森林”。

那么，F(xiàn)alcon 究竟是什么呢？

內(nèi)核崩潰

在我看來，F(xiàn)alcon 是一種“惡意軟件......不過是好人的惡意軟件”，也就是一個終端安全系統(tǒng)。Falcon 通常安裝在企業(yè)機器上，以便安全團隊能夠?qū)崟r檢測并解除威脅（同時監(jiān)控員工的行為）。這確實有一定價值：大多數(shù)網(wǎng)絡(luò)攻擊都是通過社會工程學(xué)手段從入侵企業(yè)機器開始的。

這種類型的產(chǎn)品必須對機器有控制權(quán)，它必須能夠攔截所有用戶的文件和網(wǎng)絡(luò)操作以掃描其內(nèi)容，并且還必須是防篡改的，以防“精明”的企業(yè)用戶在閱讀到一些網(wǎng)上修復(fù) WiFi 的可疑指導(dǎo)后嘗試禁用它，以避免提交 IT 工單。

如何實現(xiàn)像 Falcon 這樣的產(chǎn)品？最簡單的方法，也是 Windows 鼓勵的方法，就是編寫一個內(nèi)核模塊。很明顯，F(xiàn)alcon 是一個內(nèi)核模塊，因此它運行在內(nèi)核空間。這就意味著，Falcon 代碼中的任何錯誤都可能破壞正在運行的內(nèi)核，進而導(dǎo)致整個系統(tǒng)崩潰。

我所說的“任何錯誤”，是真的。內(nèi)核不僅會因為內(nèi)存錯誤而崩潰，也不一定非要“內(nèi)核崩潰”才能讓機器無法使用：死鎖會讓阻止內(nèi)核前進，系統(tǒng)調(diào)用處理程序中的邏輯錯誤會阻止用戶空間之后打開任何文件，一個無限遞歸算法會耗盡內(nèi)核的堆棧……破壞內(nèi)核穩(wěn)定性的方法實在是太多了，所以我說就算是 Rust 也不能完全避免這種事故的發(fā)生。

Rust 的內(nèi)存安全性只能解決一種類型的崩潰。另外，Rust 生態(tài)系統(tǒng)中對正確性的關(guān)注也確實可以最大限度地減少其他類型邏輯錯誤的出現(xiàn)。但是……雖然我們都希望做到完美，但也必須接受錯誤會發(fā)生的事實——斷言 Rust 是解決問題的唯一答案和堅持使用 C++ 一樣，都是不負(fù)責(zé)任的行為。

要知道，在內(nèi)核空間工作的 C++ 開發(fā)者，要比了解內(nèi)核內(nèi)部結(jié)構(gòu)的 Rust 開發(fā)者多得多。因此，大部分 C++ 開發(fā)者都知道這種說法的可笑之處，同時也會增加兩個社區(qū)之間的敵意，更是完全違背了讓人們轉(zhuǎn)向安全語言的這個目標(biāo)。Rust 開發(fā)者知道 Rust 確實可以改善現(xiàn)狀，但 C++ 開發(fā)者無法接受，因為他們聽到的觀點無法引起他們的共鳴。

從內(nèi)核空間到用戶空間

還有人說，如果 Falcon 不在內(nèi)核中運行，就根本不會發(fā)生這種情況。嗯，這個說法要好一點，但……僅此一點也不一定就能解決問題。

正如我之前提到的，F(xiàn)alcon 需要盡可能防篡改，防止惡意軟件對其進行干擾，并防止被入侵的用戶試圖禁用它。如果惡意軟件或人類能夠輕易做到這一點，那么這個產(chǎn)品就毫無用處。

現(xiàn)在，Windows 內(nèi)核完全有能力禁止類似 Falcon 的內(nèi)核模塊。相反，內(nèi)核可以暴露一系列 API，讓用戶空間的應(yīng)用程序能夠接入這些 API 來提供類似的功能。你知道嗎，微軟確實嘗試過讓 Windows 朝這個方向發(fā)展，但殺毒軟件公司威脅要以反壟斷為由起訴，結(jié)果整個計劃無疾而終。因此，我們現(xiàn)在只能忍受一個安全性較低的系統(tǒng)，因為殺毒軟件公司需要銷售那些煩人的產(chǎn)品。

但是，我們先暫時放下這個麻煩不談。即使 Falcon 運行在用戶空間，并通過受控 API 與內(nèi)核通信……這就足以防止系統(tǒng)故障嗎？請注意，這些 API 也需要防篡改。試想一下，如果你希望這個用戶空間驅(qū)動程序在內(nèi)核執(zhí)行每個二進制文件之前進行驗證，也就是讓內(nèi)核在每次執(zhí)行時都需要從用戶空間驅(qū)動程序獲得答案，而這個驅(qū)動程序又有問題，那么系統(tǒng)將無法再執(zhí)行任何程序。

可如果你讓內(nèi)核與驅(qū)動程序通信變成可選項，以便內(nèi)核可以容忍崩潰的驅(qū)動程序，那么就等于給惡意軟件開了一條路，它們可以先嘗試崩潰驅(qū)動程序，然后再入侵系統(tǒng)。

因此，僅僅“遷移到用戶空間”顯然也不是解決辦法。

部署中的漏洞

如果我們必須接受 bug 的存在，而內(nèi)存相關(guān)的 bug 并不是唯一會導(dǎo)致系統(tǒng)崩潰的原因，且將驅(qū)動程序移到用戶空間也不是很好的解決方案……那難道就無計可施了？真的沒有辦法防止這種情況發(fā)生嗎？

以上我說的這些，都是可以（也應(yīng)該）采取的措施，以減少系統(tǒng)故障發(fā)生的概率，但我們必須接受這樣一個事實：這次代碼 bug 只是特定的觸發(fā)因素，就算換一個觸發(fā)因素也可能會產(chǎn)生類似的惡果。本次全球宕機事件的根本原因，在于配置變更的發(fā)布流程。

根據(jù) SRE 101（或 DevOps，隨便你怎么叫）規(guī)定，配置變更必須分階段進行，以緩慢和受控的方式部署，并在每個步驟進行驗證。這些變更應(yīng)該先在很小的范圍內(nèi)進行驗證，然后再向全球推送，而且每次推送都應(yīng)是漸進的。

考慮到 Falcon 的關(guān)鍵性以及 bug 可能帶來的巨大影響，我很難相信 CrowdStrike 沒有對部署進行任何驗證。但根據(jù) CrowdStrike 最新更新的事后分析來看，他們確實沒有進行任何形式的測試或金絲雀部署（在將更改推廣到整個服務(wù)集群之前，先把更改推廣到一小部分用戶進行測試），這實在是令人難以置信的疏忽。

所以說，CrowdStrike 的部署實踐是造成此次事件的罪魁禍?zhǔn)住?strong>也就是說，這次宕機事件是一個流程問題，而不是代碼或技術(shù)問題，改用 Rust 也無濟于事。

CrowdStrike 發(fā)布初步審查報告，總結(jié)：“測試和流程不完善”

誠然如 Julio Merino 所說，CrowdStrike 在其官網(wǎng)最新發(fā)布了此事件的初步審查報告，并公開了此次事件的整體時間線：

• 安全故障始于 2 月 28 日，當(dāng)時 CrowdStrike 開發(fā)并分發(fā)了一個 Falcon 傳感器更新，旨在檢測一種新興的、利用 Windows 命名管道的攻擊技術(shù)，而傳感器更新在發(fā)布前通過了常規(guī)測試。

• 3 月 5 日，該更新接受了壓力測試并得到驗證，可以投入使用。因此，當(dāng)天 CrowdStrike 就向使用新的惡意命名管道檢測的客戶分發(fā)了快速響應(yīng)更新。

• 在 4 月 8 日-4 月 24 日期間，CrowdStrike 又推送了三次使用這種新代碼模板的快速響應(yīng)更新，并表示所有這些更新“在生產(chǎn)環(huán)境中按預(yù)期運行”。

• 到了 7 月 19 日，CrowdStrike 又用 3 月份的傳感器模板發(fā)布了兩個快速響應(yīng)更新，但這次其中一個更新推送的數(shù)據(jù)格式不正確。然而，CrowdStrike 用于檢查內(nèi)容更新是否按預(yù)期運行的驗證系統(tǒng)有問題，它沒有發(fā)現(xiàn)這個要推送給所有人的配置文件存在錯誤。于是乎，這個本該停止發(fā)布的錯誤更新就造成了全球 850 萬 PC 藍(lán)屏。

部分網(wǎng)友在看過 CrowdStrike 這份冗長的初步審查報告后，精辟總結(jié)：“說了這么多，就是想說我們的測試和流程不完善，不小心把垃圾發(fā)布出來了”；“字?jǐn)?shù)驚人，但歸根結(jié)底還是測試代碼有 bug 以及測試不夠”；“不好意思，我們對此更新進行的唯一測試，是一個沒真正通過的自動化測試”。

因此對于這種事故原因，絕對不是改用 Rust 就能解決的，根本還是在于測試環(huán)節(jié)和部署流程的不規(guī)范。與此同時，CrowdStrike 也在事后總結(jié)中表示，今后要在發(fā)布更新前增加軟件測試，并逐步推出更新，具體補救措施大體分為三個部分：

1、軟件彈性和測試

（1）通過使用以下測試類型改進快速響應(yīng)內(nèi)容測試：本地開發(fā)人員測試，內(nèi)容更新和回滾測試，壓力測試、模糊測試和故障注入，穩(wěn)定性測試和內(nèi)容接口測試；

（2）在快速反應(yīng)內(nèi)容的驗證器中增加額外的驗證檢查；

（3）增強內(nèi)容解釋器中現(xiàn)有的錯誤處理功能。

2、快速響應(yīng)內(nèi)容部署

（1）對快速響應(yīng)內(nèi)容實施交錯部署策略，從金絲雀部署開始，再逐步將更新部署到更大的區(qū)域；

（2）改進對傳感器和系統(tǒng)性能的監(jiān)控，在快速響應(yīng)內(nèi)容部署期間收集反饋信息，以指導(dǎo)分階段部署；

（3）允許用戶選擇部署的時間和位置，使其能夠更好地控制快速響應(yīng)內(nèi)容更新的交付；

（4）通過客戶可訂閱的發(fā)布說明提供內(nèi)容更新詳情。

3、第三方驗證

（1）進行多個獨立的第三方安全代碼審查；

（2）對從開發(fā)到部署的端到端質(zhì)量流程進行獨立審查。

參考鏈接：

https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/

https://blogsystem5.substack.com/p/crowdstrike-and-rust