ช่องโหว่ข้ามการบังคับใช้ลายเซ็นไดรเวอร์บน Windows อาจเปิดทางติดตั้งเคอร์เนลรูทคิตได้

 (bleepingcomputer.com)
1 คะแนน โดย GN⁺ 2024-10-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้ภายนอกจะเป็น Windows ที่ติดตั้งแพตช์ล่าสุดแล้ว แต่หาก กระบวนการ Windows Update ถูกยึดครอง ก็อาจถูกย้อนกลับไปใช้คอมโพเนนต์เคอร์เนลรุ่นเก่า จนนำไปสู่การข้าม Driver Signature Enforcement และการกระจายเคอร์เนลรูทคิตได้
  • นักวิจัยจาก SafeBreach อย่าง Alon Leviev ได้สาธิต การโจมตีแบบ downgrade/version rollback ที่งาน BlackHat และ DEFCON โดยปัญหา Windows Update takeover ยังไม่ได้ถูกแพตช์อย่างสมบูรณ์
  • ผู้โจมตีที่มีสิทธิ์ผู้ดูแลระบบสามารถสลับ ci.dll เป็นเวอร์ชันที่ยังไม่แพตช์ได้ แม้บน Windows 11 รุ่นล่าสุด เพื่อให้โหลดไดรเวอร์เคอร์เนลที่ไม่ได้เซ็นลายเซ็นได้
  • Virtualization-based Security อาศัยการล็อกด้วย UEFI และการตั้งค่ารีจิสทรี ดังนั้นในการตั้งค่าที่ไม่มี Mandatory flag การแก้ไขรีจิสทรีหรือการสลับไฟล์แกนหลักอาจกลายเป็นเส้นทางข้ามการป้องกันได้
  • Microsoft กำลังพัฒนาอัปเดตความปลอดภัยเพื่อเลิกใช้ไฟล์ระบบ VBS เก่าที่ไม่ได้แพตช์ แต่ยังไม่ชัดเจนว่าจะเผยแพร่เมื่อใด เนื่องจากต้องตรวจสอบเวอร์ชันที่ได้รับผลกระทบ ทดสอบความเข้ากันได้ และป้องกัน regression

การโจมตีแบบดาวน์เกรดที่ทำให้สถานะแพตช์ล่าสุดไร้ผล

  • ผู้โจมตีสามารถควบคุมกระบวนการ Windows Update เพื่อนำ คอมโพเนนต์เก่าที่มีช่องโหว่ กลับเข้าไปในระบบที่ดูเหมือนอัปเดตล่าสุดแล้วได้
  • ระบบปฏิบัติการยังคงดูเหมือนถูกแพตช์ครบถ้วน แต่ในความเป็นจริงกลับเปิดรับช่องโหว่ที่เคยถูกแก้ไปแล้วอีกครั้ง
  • เป้าหมายของการดาวน์เกรดรวมถึง DLL, ไดรเวอร์ และ NT kernel
  • Alon Leviev เปิดเผยเครื่องมือ Windows Downdate เพื่อแสดงให้เห็นว่าสามารถสร้างการดาวน์เกรดแบบกำหนดเองได้

การข้าม Driver Signature Enforcement และความเสี่ยงจากรูทคิต

  • Leviev สาธิตให้เห็นว่าแม้จะมีการเสริมความปลอดภัยของเคอร์เนลแล้ว ก็ยังสามารถข้าม Driver Signature Enforcement(DSE) ได้
  • เมื่อข้าม DSE สำเร็จ ผู้โจมตีจะสามารถโหลดไดรเวอร์เคอร์เนลที่ไม่ได้เซ็นลายเซ็นได้
  • ไดรเวอร์ลักษณะนี้สามารถถูกใช้เพื่อปิดการทำงานของกลไกควบคุมความปลอดภัย และใช้กระจาย มัลแวร์รูทคิต ที่ทำให้การตรวจจับการบุกรุกทำได้ยากขึ้น
  • Leviev เรียกวิธีของตนว่า "ItsNotASecurityBoundary" DSE bypass
    • วิธีนี้เป็นการดาวน์เกรดเอ็กซ์พลอยต์ ItsNotASecurityBoundary
    • เอ็กซ์พลอยต์ดังกล่าวใช้ประโยชน์จากช่องโหว่กลุ่ม false file immutability ของ Windows ที่ Gabriel Landau จาก Elastic เป็นผู้ระบุ ซึ่งทำให้สามารถรันโค้ดตามอำเภอใจด้วยสิทธิ์ระดับเคอร์เนลได้

การสลับ ci.dll และเงื่อนไขการรีบูต

  • ในงานวิจัยใหม่ Leviev แสดงให้เห็นว่า ผู้โจมตีที่มีสิทธิ์ผู้ดูแลระบบสามารถใช้ประโยชน์จากกระบวนการ Windows Update เพื่อข้ามการป้องกัน DSE ได้ แม้บน Windows 11 ที่อัปเดตครบถ้วนแล้ว
  • แก่นสำคัญคือการสลับ ci.dll ที่ใช้บังคับ DSE ให้เป็นเวอร์ชันที่ยังไม่แพตช์และมองข้ามการเซ็นลายเซ็นไดรเวอร์
  • หลังจากคอมโพเนนต์ถูกดาวน์เกรดเป็นเวอร์ชันที่มีช่องโหว่แล้ว ระบบจะต้องรีสตาร์ตเหมือนกระบวนการอัปเดตตามปกติ
  • Leviev เผยแพร่การสาธิตที่ย้อนแพตช์ DSE ด้วยการดาวน์เกรดบนระบบ Windows 11 23H2 ที่แพตช์ครบแล้ว ก่อนนำคอมโพเนนต์ดังกล่าวมาใช้โจมตี

เส้นทางข้ามการป้องกันเมื่อการตั้งค่า VBS อ่อนแอ

  • Leviev ยังกล่าวถึงวิธีปิดใช้งานหรือข้าม Virtualization-based Security(VBS) ของ Microsoft
  • VBS สร้างสภาพแวดล้อมแยกออกมาเพื่อปกป้องทรัพยากรสำคัญและทรัพย์สินด้านความปลอดภัยของ Windows
    • สิ่งที่ได้รับการปกป้องรวมถึง skci.dll ซึ่งเป็นกลไกตรวจสอบความสมบูรณ์ของโค้ดใน security kernel และข้อมูลรับรองผู้ใช้ที่ผ่านการยืนยันตัวตนแล้ว
  • โดยทั่วไป VBS อาศัยกลไกป้องกันอย่างการล็อกด้วย UEFI และการตั้งค่ารีจิสทรี
  • หาก VBS ไม่ได้ถูกกำหนดเป็นการตั้งค่าความปลอดภัยสูงสุดด้วย “Mandatory” flag ก็อาจถูกปิดได้ด้วยการแก้ไขคีย์รีจิสทรีเป้าหมาย
  • หาก VBS เปิดใช้งานเพียงบางส่วน ไฟล์ VBS สำคัญอย่าง SecureKernel.exe อาจถูกสลับเป็นเวอร์ชันที่ถูกดัดแปลงเพื่อรบกวนการทำงานของ VBS
    • สถานะนี้อาจเปิดเส้นทางไปสู่การข้าม “ItsNotASecurityBoundary” และการสลับ ci.dll

การตอบสนองของ Microsoft และช่องว่างที่ยังเหลืออยู่

  • แม้ CVE-2024-21302 และ CVE-2024-38202 ที่ถูกใช้ในการโจมตีแบบดาวน์เกรดซึ่งเปิดเผยใน BlackHat และ DEFCON จะได้รับการจัดการแล้ว แต่ปัญหา Windows Update takeover ยังไม่หมดไป
  • Microsoft มองว่าปัญหานี้ไม่ได้ข้ามเส้นแบ่งด้านความปลอดภัยที่นิยามไว้ และตัดสินว่าการได้สิทธิ์รันโค้ดระดับเคอร์เนลจากสิทธิ์ผู้ดูแลระบบไม่ถือเป็นการละเมิดเส้นแบ่งด้านความปลอดภัย
  • Leviev เน้นว่าจนกว่า Microsoft จะออกการแก้ไข โซลูชันด้านความปลอดภัยควรเฝ้าติดตามและตรวจจับ การโจมตีแบบดาวน์เกรด
  • Microsoft ระบุว่ากำลังพัฒนามาตรการบรรเทาเพื่อป้องกันความเสี่ยงนี้อย่างจริงจัง
  • บริษัทกำลังพัฒนาอัปเดตความปลอดภัยเพื่อเลิกใช้ ไฟล์ระบบ VBS เก่าที่ไม่ได้แพตช์
    • กระบวนการนี้รวมถึงการตรวจสอบทุกเวอร์ชันที่ได้รับผลกระทบ การพัฒนาอัปเดต และการทดสอบความเข้ากันได้
    • เพื่อปกป้องลูกค้าและลดการหยุดชะงักในการดำเนินงาน จึงต้องหลีกเลี่ยงความล้มเหลวในการรวมระบบหรือ regression
    • ด้วยความซับซ้อนของปัญหา จึงยังไม่ชัดเจนว่าจะปล่อยอัปเดตเมื่อใด
  • ในอัปเดตวันที่ 27 ตุลาคม มีการชี้ชัดว่าการโจมตีนี้ต้องอาศัย สิทธิ์ผู้ดูแลระบบ และเพิ่มข้อมูลเพื่อลดความสับสนว่า Microsoft ไม่ได้เพิกเฉยต่อมาตรการบรรเทา

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-27
ความคิดเห็นบน Hacker News

  • MS บอกว่า UAC ไม่ใช่ขอบเขตความปลอดภัย ซึ่งเป็นประเด็นเรื่องผู้ใช้บางคนยกระดับเป็นสิทธิ์ผู้ดูแลระบบ
    แต่ในกรณีนี้ การขยับจากผู้ดูแลระบบไปเป็นเคอร์เนลก็ถูกบอกว่าไม่ใช่ขอบเขตความปลอดภัยเช่นกัน ขณะเดียวกันก็ยังบอกว่า การบังคับใช้ลายเซ็นไดรเวอร์ เป็นฟีเจอร์ความปลอดภัย
    ทั้งที่ฟีเจอร์นั้นถูกเลี่ยงอยู่ตรงนี้ แต่กลับบอกว่าไม่ได้ข้ามขอบเขตความปลอดภัย อยากให้ช่วยอธิบายให้สอดคล้องกันหน่อย

    • ตรรกะของ MS ฟังขึ้นนะ มีประเด็นสำคัญที่หล่นไป
      UAC มีไว้สำหรับผู้ใช้ที่อยู่ในกลุ่มผู้ดูแลระบบอยู่แล้ว ไม่ใช่ฟีเจอร์ที่ทำให้ “ผู้ใช้บางคนกลายเป็นผู้ดูแลระบบ”
      ขอบเขตความปลอดภัยอยู่รอบ ๆ ผู้ใช้มาตรฐาน ไม่ใช่ผู้ใช้ผู้ดูแลระบบ
      อาจจะไม่ถูกใจ แต่ถ้าต้องการขอบเขตความปลอดภัย ก็แค่ไม่ใส่ผู้ใช้ไว้ในกลุ่ม Administrators
    • เรื่องนี้ดูเหมือนเป็น ความไม่สอดคล้องของระบบคุณค่า
      โดยทั่วไปแล้วความขัดแย้งทางความเห็นมักมีทั้งความไม่ตรงกันของนิยามและความไม่สอดคล้องของระบบคุณค่า
      ในกรณีนี้ Microsoft ให้คุณค่ากับการลดทอนความสำคัญของปัญหานี้ และถ้าสิ่งนั้นอยู่บนสุดของลำดับความสำคัญ การตัดสินใจของพวกเขาก็อาจดูสอดคล้องภายใต้เกณฑ์นั้น
      ความไม่ตรงกันของนิยามค่อนข้างแก้ได้ง่าย เช่น เวลาพูดถึงการออกแบบระบบซอฟต์แวร์ ทุกคนใช้คำศัพท์ design pattern เหมือนกัน แต่ถ้าแต่ละคนเข้าใจ A เป็น A′ หรือ A″ ต่างกัน ก็อาจเกิดความสับสนใหญ่ได้
    • ได้เรียนรู้ว่าถ้าจะให้แก้บั๊ก Windows ต้องซื้อ ซัพพอร์ตมืออาชีพแบบเสียเงิน
      ซอฟต์แวร์โอเพนซอร์สที่บริษัทดูแลก็เหมือนกัน
      คำถามจริง ๆ คือทำไมผู้คนถึงใช้พลังทางปัญญาไปทำวิจัยความปลอดภัยฟรีให้ Microsoft แทนที่จะเอาไปปรับปรุง Linux บนเดสก์ท็อป
    • ในทางปฏิบัติ UAC ไม่ได้ทำงานเป็นขอบเขตความปลอดภัย และถ้าทำให้เป็นแบบนั้น ผู้ใช้จะไม่สะดวกเกินไปจนย้ายไปใช้ระบบปฏิบัติการอื่น
      UAC กับ sudo ทั้งคู่คล้ายกับหน้าต่างยินยอมคุกกี้ในระดับระบบปฏิบัติการ และผมคิดว่าควรเอาทั้งสามอย่างออกไปเลยดีกว่า
      ควรเลิกใช้แนวทางยกระดับสิทธิ์ตามผู้ใช้อย่าง UAC/sudo แล้วหันไป แซนด์บ็อกซ์แอป ไม่ใช่ผู้ใช้ เหมือน Android และ iOS
    • Microsoft มีความย้อนแย้งแบบนี้มาตลอด อาจเป็นเพราะรู้ว่ามีวิธีเลี่ยงเต็มไปหมด

  • อีกเรื่องที่น่าสนใจคือ ทั้งใน Windows และ Linux บัญชีโลคัลสิทธิ์ปกติจริง ๆ แล้วแทบจะทำงานเหมือนมี สิทธิ์เทียบเท่า root
    บน Linux เราถูกฝึกให้ใส่ sudo หน้างานที่เกี่ยวกับระบบ ส่วนบน Windows เราถูกฝึกให้กดผ่านพรอมป์ UAC
    ครั้งสุดท้ายที่ sudo บอกใครสักคนว่า “ไม่ได้” ด้วยเหตุผลอื่นนอกจากพิมพ์รหัสผ่านผิดคือเมื่อไหร่กันนะ
    UAC ดีกว่านิดหน่อยตรงที่เป็น UI ที่ระบบจัดการ ในขณะที่ sudo เป็นแค่โปรแกรม ดังนั้นผู้โจมตีอาจเปลี่ยน sudo เป็น shell alias อันตรายเพื่อขโมยรหัสผ่านได้
    ในค่าตั้งต้น การเอา sudo กับ UAC ออก และเลิกทำเหมือนว่ามีขอบเขตความปลอดภัยที่แข็งแรงระหว่าง root กับบัญชีโลคัลของผู้ใช้หลัก น่าจะสะดวกกับผู้ใช้มากกว่าและตรงกับสภาพความปลอดภัยจริงมากกว่า

    • บน Linux แอปพลิเคชันสำหรับผู้ใช้สมัยใหม่ส่วนใหญ่ใช้ polkit แทน sudo
      ในเทอร์มินัลก็ใช้ pkexec แทน sudo ได้
      แทนที่จะรันคำสั่งใด ๆ เป็น root แอปพลิเคชันสามารถใช้การกระทำที่กำหนดไว้ล่วงหน้าอย่าง org.freedesktop.udisks2.filesystem-mount และแสดงข้อความที่แปลตามภาษาผู้ใช้ให้เห็นว่าแอปต้องการทำอะไร เพื่อให้ผู้ใช้ตัดสินใจว่าจะอนุญาตหรือไม่
      ผู้ดูแลระบบยังตั้งค่าได้ด้วยว่าจะไม่ต้องยืนยันตัวตนสำหรับการกระทำบางอย่าง เช่น การอัปเดต flatpak หรือในทางกลับกันจะบล็อกการกระทำนั้นทั้งหมด
    • พูดแบบเดียวกันด้วยถ้อยคำอีกแบบแล้วจะฟังต่างไปมาก: ทั้ง Windows และ Linux ผู้ใช้ที่สร้างจากการติดตั้งเริ่มต้น จริง ๆ แล้วใกล้เคียงกับสิทธิ์เทียบเท่า root
      ผมมองว่ามีสมมติฐานว่าผู้ใช้ที่ติดตั้งระบบควรควบคุมระบบได้ เพราะตั้งแต่แรกเขาอาจเลือกไม่ติดตั้งก็ได้
      sudo ก็เหมือน UAC ไม่ใช่อุปกรณ์ที่มีไว้บอกคนว่า “ไม่ได้” ทั้งคู่มีไว้ให้คนเป็นฝ่ายบอกว่า “ไม่ได้” เมื่อผู้ดูแลระบบกำลังจะทำงานดูแลระบบที่ไม่คาดคิด
      คนที่ไม่มีสิทธิ์ผู้ดูแลระบบแต่จำเป็นต้องทำงานแบบนั้น ต้องได้รับการอนุมัติจากผู้ดูแลระบบ
      ถ้าไม่ใช่ระบบสำหรับคนเดียว คนที่ตั้งค่าเครื่องควรสร้างบัญชีจำกัดสิทธิ์ไว้สำหรับใช้งานประจำวัน
    • บน Linux ผม ไม่ติดตั้ง sudo
      ไม่ค่อยมีเรื่องต้องเป็น root บ่อยนัก และเมื่อต้องใช้ก็มักทำหลายงานต่อเนื่องกัน
      ผมมองว่า sudo มีประโยชน์บนคอมพิวเตอร์หลายผู้ใช้ เช่น คอมพิวเตอร์ที่บริษัทเป็นเจ้าของและดูแล เมื่อผู้ดูแลระบบอยากอนุญาตให้ผู้ใช้บางคนทำงานที่มีสิทธิพิเศษได้เฉพาะบางอย่าง
      เหตุผลหลักที่ใช้บัญชีอื่นที่ไม่ใช่ root อยู่เสมอคือการป้องกันความผิดพลาดมากกว่าความปลอดภัย เพื่อหลีกเลี่ยงการลบหรือเขียนทับไฟล์ที่ไม่ได้ตั้งใจ
      ดังนั้นการต้องใส่รหัสผ่านเพื่อเปลี่ยนบทบาทนาน ๆ ครั้งจึงสมเหตุสมผลพอแล้ว
    • จากประสบการณ์ของผม อย่างน้อยใน Gnome นั้น Linux ก็กำลังไปทาง การป้องกันแบบ sudo สไตล์ Windows
      เพียงแต่ไม่มีทริก “กด ctrl+alt+delete เพื่อยืนยัน”
      ข้อดีของ Windows คือไม่จำเป็นต้องเขียนทุกอย่างเป็นสคริปต์
      ถ้าต้องการก็ครอบเครื่องมือทั้งหมดด้วย runas/System.Management.Automation.PSCredential ได้ แต่ส่วนใหญ่แล้วไม่จำเป็น

  • ดูเหมือนว่าเคอร์เนลบังคับใช้กฎการแชร์ไฟล์โดยไล่ดู file handle ที่เปิดอยู่ทั้งหมดตอนเปิดไฟล์ เพื่อตรวจสอบ การล็อกแบบบังคับ ที่ชนกัน แต่ไม่ได้ตรวจสอบ memory mapping ที่มีสิทธิ์ขัดแย้งกัน
    เป็นความผิดพลาดก็จริง แต่การแก้ดูค่อนข้างตรงไปตรงมา
    น่าสนใจที่ Linux เพิ่งลบร่องรอยสุดท้ายของ mandatory locking ออกไป ตอนนี้เขียนทับไฟล์ executable ที่โหลดอยู่ก็ไม่เจอ EBUSY แล้ว
    น่าสนใจที่ฟีเจอร์เดียวกัน ในระบบปฏิบัติการหนึ่งเป็นส่วนที่รับน้ำหนักของโครงสร้างพื้นฐานด้านความปลอดภัย แต่อีกระบบปฏิบัติการหนึ่งกลับเป็นเศษซาก legacy ที่ควรถูกลบทิ้ง

  • ผมไม่ใช่ผู้เชี่ยวชาญด้านความปลอดภัย และเข้าใจแค่เรื่องพื้นฐาน แต่เหมือนมีโมเดลเชิงแนวคิดบางอย่างที่ผมพลาดไป
    สงสัยว่าทำไม Windows ถึงถูกแฮ็กได้ง่ายขนาดนี้

    • ไม่น่าเชื่อว่ายังไม่มีใครชี้ประเด็นเหตุผลที่ใหญ่ที่สุด
      Windows เป็นเป้าหมายที่ทำเงินได้ โดยเฉพาะเพราะเป็นระบบปฏิบัติการเดสก์ท็อปที่ถูกใช้งานแพร่หลายที่สุดใน สภาพแวดล้อมองค์กร จึงมีเวลาและการลงทุนจำนวนมากทุ่มไปกับการเจาะมัน
    • ปัญหาคือ Windows ถูกพัฒนาขึ้น ก่อนที่ความปลอดภัยจะกลายเป็นเรื่องสำคัญ
      ไม่มีการลงทุนมากพอเพื่อสร้างแพลตฟอร์มคอมพิวติ้งที่ปลอดภัยอย่างแท้จริง
      แพลตฟอร์มความปลอดภัยในอุดมคติควรมีบิลด์ที่ทำซ้ำได้บนโครงสร้างพื้นฐานที่ตรวจสอบได้แบบสาธารณะเหมือน fdroid, จำลองแอปพลิเคชันที่ไม่น่าเชื่อถือทั้งหมดไว้ในแซนด์บ็อกซ์ และใช้โมเดลสิทธิ์ขั้นต่ำสุด
      ตอนนี้เป็นสภาพความปลอดภัยที่แย่ที่สุด มีโค้ดที่ไม่รู้ที่มา และอาจไม่ได้ผ่านการทดสอบเพียงพอซึ่งไม่ปลอดภัย รันอยู่ในทุก ring ตั้งแต่ ME ของ CPU, คอมโพเนนต์ UEFI ไปจนถึงไดรเวอร์จากบุคคลที่สามของระบบปฏิบัติการ
      SeL4 มีเคอร์เนลที่ได้รับการตรวจสอบยืนยันอย่างสมบูรณ์ แต่ยังไม่ได้ทำ virtualization
    • อีกปัจจัยสำคัญคือ โค้ดระดับเคอร์เนลจากบุคคลที่สาม พบได้ทั่วไป
      มัลแวร์บน Windows จำนวนมากในบางช่วงต้องอาศัยไดรเวอร์เคอร์เนลจากบุคคลที่สามที่มีช่องโหว่
      ตรงกันข้าม บน Linux โมดูลเคอร์เนลจากบุคคลที่สามพบได้น้อยและถูกมองว่าไม่ดี ส่วนบน macOS ถูกห้ามไปเลย
    • จากประสบการณ์ของผม ปัญหาคือโดยค่าเริ่มต้นผู้ใช้เป็น ผู้ดูแลระบบ
      และการโน้มน้าวให้ผู้ใช้รันอะไรก็ได้ด้วยสิทธิ์ที่ถูกยกระดับนั้นง่ายเกินไป
    • ไฟล์บล็อกลิสต์สำหรับการเซ็นไดรเวอร์ DriverSiPolicy.p7b ไม่ได้รับการอัปเดตมาหลายปี
      เพิ่งถูกจัดการหลังจาก Will Dormann นักวิเคราะห์จาก CERT ถามในปี 2022 ว่าทำไมถึงเป็นเช่นนั้น
      ตอนนี้มีการอัปเดตเป็นประจำแล้ว แต่เรื่องนี้น่าขันจริง ๆ https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...

  • กรณีนี้ผมค่อนข้างเห็นด้วยกับฝั่ง Microsoft
    ผู้ดูแลระบบสามารถทำสิ่งใดก็ได้กับคอมพิวเตอร์ และนี่ไม่ใช่เรื่องใหม่
    ไม่แน่ใจว่ามีรายละเอียดปลีกย่อยอะไรที่ทำให้ความร้ายแรงสูงขึ้นหรือไม่
    บทความของ Raymond Chen ที่สรุปการโจมตีประเภทนี้ก็น่าอ่าน
    https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

    • ผมก็คิดเหมือนกัน
      ถ้ามีใครสามารถเปลี่ยน DLL ใด ๆ ของระบบได้อยู่แล้ว เงื่อนไขตั้งต้นที่ทำให้ “exploit” นี้ทำงานได้ก็ถูกเติมเต็มแล้ว และ ณ จุดนั้นก็ถือว่าจบทุกอย่าง
      ความสามารถในการเลี่ยงการเซ็นไดรเวอร์น่าจะเป็นหนึ่งในเรื่องที่น่ากังวลน้อยที่สุดด้วยซ้ำ

  • การโจมตีดูเรียบง่ายจนน่าสงสัย
    เป็นวิธีหลอกกระบวนการอัปเดตให้ติดตั้ง คอมโพเนนต์เคอร์เนล รุ่นเก่าที่มีช่องโหว่ที่รู้กันอยู่แล้ว
    แม้ไม่ใช่ผู้เชี่ยวชาญก็ยังสงสัยว่า Microsoft น่าจะคิดเรื่องแบบนี้ไว้แล้ว และควรมีกลไกอย่างบล็อกลิสต์หรือการเลิกใช้งานอยู่
    ประเด็นสำคัญคือสาเหตุรากเป็นปัญหาการออกแบบระบบปฏิบัติการ หรือเป็นความล้มเหลวของกระบวนการที่เสีย/ไม่สามารถบันทึกแฮชที่ไม่ดีไว้ในตำแหน่งที่ถูกต้องได้
    ถ้าเป็นอย่างหลังจะแก้ง่ายกว่ามาก แต่ประกาศด้านความปลอดภัยที่มักถูกแต่งถ้อยคำเล็กน้อยก็ดูเหมือนจะอ้างว่าเป็นอย่างแรก

    • อาจเป็นเพราะผู้ใช้ระดับองค์กรยืนยันว่าต้องสามารถ ดาวน์เกรด ได้หากการอัปเดตทำให้อะไรบางอย่างพัง จึงต้องอนุญาตไว้

  • ไม่น่าเชื่อว่ามีเดโมแล้ว Microsoft ยังโต้แย้ง
    บัญชี Vimeo นั้นยังมีการค้นพบด้านความปลอดภัยอื่น ๆ อีกมาก เช่น มีอันหนึ่งที่ WhatsApp รันสคริปต์ Python ด้วย เลยสงสัยว่าเป็นเรื่องจริงหรือหลอกลวง

    • เดโมแสดงภาพการข้ามสิ่งที่ Microsoft นิยามว่าไม่ใช่ขอบเขตความปลอดภัยที่แท้จริง
      มีเกณฑ์ว่า “โปรเซสและผู้ใช้ที่เป็นผู้ดูแลระบบถือว่าเป็นส่วนหนึ่งของ Trusted Computing Base (TCB) ของ Windows ดังนั้นจึงไม่ได้ถูกแยกอย่างเข้มงวดจากขอบเขตเคอร์เนล” [0]
      ยังมีกรณีล่าสุดอื่นด้วย
      https://arstechnica.com/security/2024/03/hackers-exploited-w...
      [0] https://www.microsoft.com/en-us/msrc/windows-security-servic...

  • นึกถึงความลำบากที่ทุกคนเคยเจอตอนที่ Microsoft เริ่มบังคับใช้ การเซ็นไดรเวอร์ บน Windows ครั้งแรกที่ [1]
    ตอนนั้นเรากำลังทำไดรเวอร์ตรวจสอบแพ็กเก็ตเชิงลึกสำหรับ [2] ซึ่งมองแวบแรกเหมือนเป็นกระบวนการที่ยุ่งยากกว่าการอนุมัติแอปใน Apple Store เสียอีก และเอกสารก็ไม่ชัดเจนเลย
    เมื่อนึกถึงทรัพยากรที่บริษัทต่าง ๆ ทุ่มลงไปเพื่อให้ตรงตามข้อกำหนดของ Microsoft การถูกนำไปใช้ในทางที่ผิดแบบนี้จึงให้ความรู้สึกเหมือนเป็นการถอยหลังครั้งใหญ่
    ช่องโหว่มีอยู่เสมอ แต่คงสบายใจกว่านี้ถ้ามีใครค้นพบเรื่องนี้เร็วกว่านี้
    ขอปรบมือให้ Alon Leviev และ SafeBreach ที่ค้นพบ
    [1] https://www.nektra.com/
    [2] https://www.verizon.com/business/en-nl/products/security/man...

  • การที่บอกว่า “เป็นไปได้เมื่อได้สิทธิ์รันโค้ดเคอร์เนลในฐานะผู้ดูแลระบบ” สุดท้ายก็เป็นเรื่องธรรมดาที่ว่า ผู้ใช้ root สามารถติดตั้ง rootkit ได้
    ต้องไม่ลืมตั้งชื่อเท่ ๆ ให้ด้วย อ้อ นักวิจัยก็ได้เผยแพร่เครื่องมือชื่อ Windows Downdate ไว้แล้ว
    ได้ชื่อเสียงไป 0xF นาทีแล้ว ก็ถือว่าทำได้ดี

    • แนวคิดเรื่องบัญชี root/ซูเปอร์ยูสเซอร์ที่ทำอะไรก็ได้เป็นเรื่องพบได้ทั่วไป แต่นั่นคือ ทางเลือกในการออกแบบระบบปฏิบัติการ
      บัญชีผู้ใช้ก็เป็นเพียงอ็อบเจ็กต์หนึ่งภายในระบบปฏิบัติการเท่านั้น และแม้จะจำกัดบัญชีซูเปอร์ยูสเซอร์ ก็ยังสามารถออกแบบระบบปฏิบัติการที่บังคับใช้กฎบางอย่างกับบัญชีผู้ใช้ทั้งหมดได้
      ตัวอย่างเช่น อาจมีเหตุผลที่ชอบธรรมในการปกป้องความลับบางอย่างเหมือน TPM แม้บัญชีผู้ดูแลระบบจะถูกเจาะ หรือป้องกันไม่ให้ผู้ดูแลระบบเผลอทำให้ระบบเสียจนบูตไม่ได้
      เป้าหมายที่ถกเถียงกันมากกว่านั้นก็มีการบังคับใช้ DRM ด้วย
      สิ่งที่ Microsoft พยายามทำใน Windows ก็คือเรื่องนี้เอง ระบบปฏิบัติการพยายามป้องกันไม่ให้บัญชีผู้ดูแลระบบเข้าไปแทรกแซงเคอร์เนลหรือติดตั้ง rootkit
      ในการอภิปรายนี้ สิ่งสำคัญเสมอคือต้องแยกแยะระหว่างบัญชีผู้ใช้ผู้ดูแลระบบภายในระบบปฏิบัติการ กับคนที่เป็น “ผู้ดูแลระบบ” ซึ่งมีสิทธิ์เข้าถึงทางกายภาพและฮาร์ดแวร์
    • ตรงนี้เขียนว่า 15 น่าจะง่ายกว่า แต่สงสัยว่าทำไมถึงเขียนเป็น 0xF
      ไม่ได้ผิดอะไร แต่เป็นตัวเลือกที่แปลกจนชวนสงสัย อยากรู้ว่าเป็นเพราะสไตล์เฉย ๆ หรือเปล่า

  • เวลาต้องใช้ Windows ผมมักสมมติไว้เสมอว่าคอมพิวเตอร์เครื่องนั้น ถูกเจาะไปแล้ว