波及全球的微軟藍屏事件，至今還有25萬台設備未完全恢復！另據估計，崩潰的設備多達850萬台，到目前為止已經恢復了97%，雖然看似修復效率很高，但剩下的3%仍有25萬台之多。

同時微軟也發布了一份全面調查報告，提供了根本原因的技術概述，解釋了為什麼安全產品使用內核模式驅動程序，以及未來如何增強安全產品的可擴展性。

這事件影響範圍幾乎覆蓋全球，涉及了涵蓋航空公司、電視廣播、醫療機構、銀行金融等眾多行業，甚至連奧運會也受到了影響。

光是在航空業，就有5,000多架次航班被迫取消，佔了全球定期航線的4.6%，美國一家航空公司甚至連續三天都出現了航班取消的情況。

經濟損失也是數以十億計，根據數據分析機構Parametrix的估計，單是財富500強企業，這次事件帶來的損失就高達54億美元（約391.8億人民幣）。

還有不法份子趁火打劫，冒充Crowdstrike的名義，假借發布「修復工具」之名，公然散播惡意軟體。

網路安全專家Troy Hunt稱之為「史上最大規模的IT中斷事件」。

抓馬的是，Crowdstrike在此次事件之後，給幫助修復問題的員工和合作夥伴發放了10美元的外賣代金券作為感謝，結果被外賣平台標記為了「欺詐」。

收到優惠券的人在準備使用時發現券已被取消，導致Crowdstrike本已經受到巨大影響的口碑又進一步下滑。

微軟的調查報告，確認了Crowdstrike初步報告中提及的驅動文件正是造成此事件的罪魁禍首。

進一步分析結果表明，該檔案對記憶體的越界讀取，是導致事故的直接原因。

隨著研究的深入，第三方安全軟體到底該不該被授予了核心級的操作權限，也引發了廣泛討論。

核心原因：越權讀取內存

透過分析大量的崩潰報告，微軟發現這些記錄都指向了CrowdStrike的驅動程式csagent.sys。

透過調閱故障時系統留下的崩潰轉儲，微軟再現了崩潰發生時的場景——

首先查看崩潰線程的Trap Frame後，發現引發異常的指令是一條針對R8暫存器、指向記憶體的讀取操作。

進一步觀察Trap Frame附近的指令，又發現在該讀取操作之前，有一個對R8的空值檢查，檢查失敗才會繼續執行後續的讀取操作。

但是檢查R8指向的虛擬位址後，微軟發現它指向了一個非法位址，導致核心存取違規，從而引發了崩潰。

另外，Crowdstrike也解釋了流程層面的原因－在上線前的測試過程中，未能偵測到更新中的「有問題的內容資料」。

事件發生後，微軟和Crowdstrike都緊急應對，Crowdstrike發動了全部技術人員，微軟也派出了5000多名技術人員7 x 24小時應對此事。

經過兩家合作研究，主要得出了兩種該問題的解決方案——

第一種簡單粗暴，就是重啟，以便在錯誤的檔案啟動之前取得更新並將其覆蓋。

修復方案也提到，如果重啟一次不管用就多試幾次，照微軟的說法，最多可能要15次。

如果無法透過重新啟動來取得更新，微軟還提供了透過網路或USB設備的啟動工具，以便能夠刪除問題檔案。

針對後續工作，兩家也分別做出表態：

微軟表示，將計畫與反惡意軟體生態系統合作，減少對核心驅動的依賴；

Crowdstrike則承諾，正在對其測試和部署流程進行更改，以防止類似情況再次發生。

該不該開放內核層級操作？

造成這次崩潰的csagent.sys，正是一個核心級的驅動程式。

具體來說，csagent.sys被註冊為一個檔案系統篩選驅動，用於接收檔案操作事件。

所以在這次事件之後，到底應不應該把系統的核心級操作權限開放給第三方，也引發了廣泛討論。

在微軟的報告中，也解釋了一些使用核心驅動程式進行安全防禦的原因：

-可見性和執行力：核心驅動可以全系統範圍內可見，並能夠在啟動早期加載，以檢測bootkit和rootkit；

-效能：某些高吞吐量的資料收集和分析場景，使用核心驅動可以帶來效能優勢；

-防篡改：即便管理員權限也難以停用處於核心模式的驅動，因為Windows提供了早期載入（ELAM）等機制，讓驅動器能儘早運作。

但同時微軟也指出，驅動運作在最高權限，一旦出問題難以隔離和恢復，因此驅動程式碼必須經過嚴格測試。

不過在HackerNews上，網友們並不認同核心層級的運作方式，並指出蘋果和Linux早就禁用核心級操作，改為用戶級操作了。

依照這位網友的說法，雖然直接原因是由Crowdstrike導致，但微軟不禁用核心操作給了問題程式運行的土壤，所以也難辭其咎。

其實微軟也不是沒試過停用，甚至這次事件中的Crowdstrike，還是微軟的競爭對手。

但其他網友指出，這是為了符合歐盟的監管要求，因為微軟自己的安全軟體有核心級操作，所以公平起見，也得開放給第三方。

但這句話只說對了一半，歐盟並未要求微軟將核心操作開放給第三方，他們也可以選擇把自己的安全產品也移出核心。

當然，如果只從技術角度分析，網友們的觀點還是比較一致的，都認為核心級操作還是開放的越少越好。

微軟的報告也提到，今後會聯合安全軟體生態，盡可能減少核心操作對重要安全資料的存取需求。

One More Thing

最後再說說直接造成這次事件的Crowdstrike。

實際上，這已經不是這家公司的Falcon程式第一次把作業系統搞崩了。

從今年四月開始到現在這四個月，Falcon每個月都會把作業系統搞崩一次。

前三次的受害者都是Linux核心的作業系統，不過影響範圍和受關注程度都和這次事件無法相提並論：

4月19日晚，Crowdstrike發布了一個有缺陷的軟體更新，導致運行Debian 的電腦崩潰且無法正常重新啟動；

5月13日，安裝CrowdStrike軟體的伺服器在升級到Rocky Linux 9.4後可能會凍結（freeze）；

6月，Red Hat在啟動了Crowdstrike的falcon-sensor進程後，也觀察到了核心恐慌（Kernel Panic）。

參考連結：

[1]https://www.microsoft.com/en-us/security/blog/2024/07/27/windows-security-best-practices-for-integrating-and-managing-security-tools/

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

[3]https://news.ycombinator.com/item?id=41095530