超碰人人人人人,亚洲AV午夜福利精品一区二区,亚洲欧美综合区丁香五月1区,日韩欧美亚洲系列

編譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

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

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

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

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

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

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

我驚訝地發(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è)界應該宣布這些語言已被淘汰?！?br/>

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

以下為譯文：

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

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

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

故障分析

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

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

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

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

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

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

3、Falcon 中的這個 bug 導致了 Windows 崩潰。

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

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

內(nèi)存錯誤

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

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

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

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

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

內(nèi)核崩潰

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

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

如何實現(xiàn)像 Falcon 這樣的產(chǎn)品？最簡單的方法，也是 Windows 鼓勵的方法，就是編寫一個內(nèi)核模塊。很明顯，F(xiàn)alcon 是一個內(nèi)核模塊，因此它運行在內(nèi)核空間。這就意味著，Falcon 代碼中的任何錯誤都可能破壞正在運行的內(nèi)核，進而導致整個系統(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)中對正確性的關注也確實可以最大限度地減少其他類型邏輯錯誤的出現(xiàn)。但是……雖然我們都希望做到完美，但也必須接受錯誤會發(fā)生的事實——斷言 Rust 是解決問題的唯一答案和堅持使用 C++ 一樣，都是不負責任的行為。

要知道，在內(nèi)核空間工作的 C++ 開發(fā)者，要比了解內(nèi)核內(nèi)部結(jié)構(gòu)的 Rust 開發(fā)者多得多。因此，大部分 C++ 開發(fā)者都知道這種說法的可笑之處，同時也會增加兩個社區(qū)之間的敵意，更是完全違背了讓人們轉(zhuǎn)向安全語言的這個目標。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，讓用戶空間的應用程序能夠接入這些 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)存相關的 bug 并不是唯一會導致系統(tǒng)崩潰的原因，且將驅(qū)動程序移到用戶空間也不是很好的解決方案……那難道就無計可施了？真的沒有辦法防止這種情況發(fā)生嗎？

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

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

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

所以說，CrowdStrike 的部署實踐是造成此次事件的罪魁禍首——也就是說，這次宕機事件是一個流程問題，而不是代碼或技術問題，改用 Rust 也無濟于事。

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

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

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

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

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

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

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

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

1、軟件彈性和測試

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

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

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

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

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

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

（3）允許用戶選擇部署的時間和位置，使其能夠更好地控制快速響應內(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