ไมโครซอฟท์ออกมาอธิบายรายละเอียดของปัญหาจอฟ้า BSOD จากกรณี CrowdStrike โดยอาศัยข้อมูล kernel crash dump ที่ผู้ใช้ส่งผ่าน Windows Error Reporting (WER) เข้ามาจำนวนมาก (4 ล้านครั้งในวันเกิดเหตุ) และวิเคราะห์ด้วยเครื่องมือมาตรฐานอย่าง WinDBG Kernel Debugger
ผลการวิเคราะห์ของไมโครซอฟท์ออกมาสอดคล้องกับรายงานเบื้องต้นของ CrowdStrike เอง ว่าตัวไดรเวอร์ CSagent.sys เข้าถึงข้อมูลหน่วยความจำในพื้นที่หวงห้าม (a read out-of-bounds access violation)
ไมโครซอฟท์อธิบายการทำงานว่า CrowdStrike เลือกใช้วิธีสร้างไดรเวอร์ file system filter ขึ้นมา เพื่อดักการเปลี่ยนแปลงของไฟล์ในเครื่อง (ซึ่งอาจโดนไวรัสหรือมัลแวร์) วิธีการนี้ใช้กันทั่วไปในหมู่ซอฟต์แวร์แอนตี้ไวรัส รวมถึงไมโครซอฟท์เองด้วย
CrowdStrike สร้างโมดูลไดรเวอร์ขึ้นมาทั้งหมด 4 ตัวทำงานแตกต่างกันไป โดยไดรเวอร์ตัวหนึ่งทำหน้าที่คอยรับอัพเดตจาก CrowdStrike ตามที่บริษัทเคยแถลงไว้ และเป็นไฟล์อัพเดต channel file ที่สร้างปัญหาจนทำเครื่องแครชในที่สุด
ไมโครซอฟท์ยังอธิบายว่าบริษัทความปลอดภัยเลือกใช้วิธีสร้างไดรเวอร์เคอร์เนล เพื่อคอยมอนิเตอร์การเปลี่ยนแปลงของไฟล์ในระบบ ด้วยเหตุผลทั้งหมด 3 ข้อคือ
ไมโครซอฟท์นั้นอนุญาตให้ซอฟต์แวร์ความปลอดภัยสามารถโหลดตัวเองเข้ามาตั้งแต่ช่วงบูตเครื่องแรกๆ มาตั้งแต่ยุค Windows 8 แล้ว ไดรเวอร์แบบนี้มีชื่อเรียกว่า Early Launch AntiMalware (ELAM) ซึ่ง CrowdStrike ทำตามกระบวนการถูกต้องทุกอย่าง
อย่างไรก็ตาม การรันงานที่ระดับเคอร์เนลไดรเวอร์ก็มีข้อเสียคือ มีสิทธิเข้าถึงเยอะมาก ผู้พัฒนาซอฟต์แวร์ความปลอดภัยจึงต้องระมัดระวังให้ดีๆ เพราะถ้าเกิดปัญหาขึ้น ไม่สามารถรีสตาร์ตใหม่เฉพาะแอพได้เหมือนกับแอพระดับ user ทั่วไป ต้องบูตระบบปฏิบัติการใหม่หมด ไมโครซอฟท์เองก็พยายามย้ายงานหลายอย่างจากระดับเคอร์เนลไปรันระบบ user mode แทน และออกระบบความปลอดภัยหลายอย่างที่รันใน user mode ด้วยเช่นกัน
ส่วนในระยะยาว ไมโครซอฟท์ระบุว่าจะทำงานร่วมกับบริษัทซอฟต์แวร์แอนตี้ไวรัส เพื่อให้บริษัทเหล่านี้ใช้ช่องทางหรือฟีเจอร์ความปลอดภัยสมัยใหม่มากขึ้น เพื่อเพิ่มเสถียรภาพและความน่าเชื่อถือ ลดการเข้าถึงไดรเวอร์เคอร์เนลลง แต่ยังรักษาระดับความปลอดภัยโดยรวมเอาไว้ได้ ผ่านมาตรการหลายๆ อย่างผสมผสานกันไปด้วย
ที่มา - Microsoft
Comments
มุมมองของผมสิ่งที่ควรทำเพิ่มคือแทนที่จะปล่อยให้เกิดจอฟ้า
ควรเพิ่มสิ่งเหล่านี้เข้าไปเพื่อป้องกัน เคสแบบนี้ขึ้นอีก
1. มี snapshot system driver สำหรับ boot ที่ไม่มีปัญหา เพื่อจะได้ rollback กลับ
2. ทนทานต่อการ ร้องขอแบบนี้ ให้มากขึ้น เช่น จับให้มัน unload หรือ ข้ามไปเลย
ผมรู้ว่าไม่ง่าย แต่ต้องทำอะไรแบบนี้มารองรับโดยเฉพาะกับองค์กรใหญ่ ๆ เคสที่ผ่านมาสาหัสกันเลย ทำงานกันไม่ได้
ขัดกันในทาง Logic ครับ
เช่นตำรวจเจอผู้ต้องสงสัย(หรือคิดว่าเจอ) แล้วถามผู้ต้องสงสัยว่าชื่ออะไร แต่ผู้ต้องสงสัยไม่ตอบ แล้วเดินจากไป กรณีนี้ จะให้ตำรวจปล่อยผ่านไป เพราะผู้ต้องสงสัยไม่พูดตอบ ก็ดูจะแปลก
และผมมองว่ามันคือปลายเหตุ
ต้นเหตุของปัญหา คือกระบวนการ release update ของทาง CS ครับ
มันแก้ปลายเหตุไป
เห็นด้วยกับแนวทางที่ ms ควรแยกเลเยอร์ system ตัวเอง กับ 3rd party เท่านี้ไม่ว่า attacker หรือ antivirus ต่างฝาายก็ทำอะไรไม่ได้เหมือนกัน
😂😂😂😂😂เอาให้สุดแล้วจบที่ไหนดี
แนวทางที่ Windows จะทำเป็นสัญญาณที่ดีแต่คงใช้เวลาพักใหญ่และต้องการ input จากหลายส่วน
ส่วนกรณีของ CrowdStrike จริงๆแล้วถ้ากระบวนการ release ทำได้รัดกุมหรือทำตามมาตรฐานทั่วๆไป ก็จะไม่ส่งผลกระทบเป็นวงกว้างขนาดนี้ จุดนี้เป็นปัญหาที่ทาง CrowdStrike รับไปเต็มๆคนเดียว
..: เรื่อยไป