SBAT คืออะไร และทำไมจู่ ๆ ทุกคนถึงให้ความสนใจ

 (mjg59.dreamwidth.org)
2 คะแนน โดย GN⁺ 2024-08-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

คำจำกัดความของ SBAT(Secure Boot Advanced Targeting)

  • ตอนที่มีการกำหนด UEFI Secure Boot ขึ้นครั้งแรก ผู้เกี่ยวข้องทุกฝ่ายค่อนข้างมองโลกในแง่ดีเกินไปเล็กน้อย
  • โมเดลความปลอดภัยพื้นฐานของ Secure Boot คือ โค้ดทั้งหมดที่ทำงานในสภาพแวดล้อมสิทธิ์ระดับเคอร์เนลต้องได้รับการตรวจสอบก่อนรัน
  • มีวิธีเพิกถอนคอมโพเนนต์ที่มีลายเซ็นซึ่งพบช่องโหว่อยู่ในนั้นด้วย
  • แต่ Linux distribution ทั้งหมดที่ทำงานในระบบนิเวศของ Secure Boot ต่างก็สร้างไบนารีบูตโหลดเดอร์ของตัวเอง จึงทำให้เมื่อมีการระบุช่องโหว่ จะมีไบนารีจำนวนมากที่ต้องเพิกถอน
  • พื้นที่สำหรับเก็บแฮชมีจำกัด จึงมีการพัฒนา SBAT ขึ้นมา

วิธีการทำงานของ SBAT

  • คอมโพเนนต์สำคัญทุกตัวใน boot chain จะประกาศ security generation ที่บรรจุอยู่ในไบนารีที่มีลายเซ็น
  • เมื่อมีการระบุและแก้ไขช่องโหว่ generation นั้นก็จะเพิ่มขึ้น
  • สามารถกำหนด minimum generation ได้ผ่านการอัปเดต
  • คอมโพเนนต์บูตจะตรวจดูรายการถัดไปใน chain แล้วเปรียบเทียบชื่อและหมายเลข generation กับค่าที่เก็บอยู่ในตัวแปรเฟิร์มแวร์ เพื่อพิจารณาว่าจะอนุญาตให้รันหรือไม่
  • แทนที่จะเพิกถอนแฮชรายตัวจำนวนมาก เราสามารถปล่อยอัปเดตเพียงครั้งเดียวเพื่อระบุว่า grub เวอร์ชันที่มี security generation ต่ำกว่าหมายเลขที่กำหนดนั้นไม่น่าเชื่อถือ

สาเหตุของประเด็นล่าสุด

  • Microsoft ปล่อย Windows update เพื่อไม่ให้เชื่อถือ grub เวอร์ชันที่มี security generation ต่ำกว่าระดับหนึ่ง
  • เหตุผลคือ grub เวอร์ชันดังกล่าวมีช่องโหว่ด้านความปลอดภัยจริงที่สามารถทำลาย secure boot chain ของ Windows ได้
  • ปัญหาคือ Linux distribution บางตัว ยังไม่ได้จัดส่ง grub เวอร์ชัน security generation ใหม่
  • ความตั้งใจของ Microsoft คือให้ใช้ SBAT update นี้เฉพาะกับระบบที่มี Windows อย่างเดียว แต่สิ่งนี้ไม่ทำงานตามที่ตั้งใจไว้

สรุป

  • Microsoft ผลักดัน Windows update เพื่อไม่ให้มีการใช้ grub เวอร์ชันที่มีช่องโหว่มาโจมตี Windows ได้
  • อัปเดตนี้ถูกตั้งใจไม่ให้ใช้กับระบบ dual boot แต่สุดท้ายก็ไม่เป็นผล
  • Linux distribution บางตัวไม่ได้อัปเดตทั้งโค้ด grub และ security generation ของ SBAT
  • ผลลัพธ์คือผู้ใช้บางส่วนไม่สามารถบูตระบบได้อีก

ใครควรถูกตำหนิ

  • Microsoft ควรทดสอบให้มากกว่านี้เพื่อให้สามารถระบุการตั้งค่า dual boot ได้อย่างแม่นยำ
  • แต่อีกด้านหนึ่ง distribution ที่จัดส่งบูตโหลดเดอร์แบบ signed ก็ต้องอัปเดตสิ่งนี้และอัปเดต security generation ด้วย
  • เพราะมันอาจกลายเป็นช่องทางที่ถูกใช้เพื่อโจมตีระบบปฏิบัติการอื่นได้

บทสรุป

  • น่าเสียดายที่ผู้ใช้ปลายทางที่จู่ ๆ ไม่สามารถบูต OS ที่ต้องการได้ กลายเป็นผู้เสียหาย
  • นี่เป็นสิ่งที่ไม่ควรเกิดขึ้นอย่างยิ่ง
  • แม้จะรู้สึกว่า UEFI Secure Boot ไม่ได้ให้ประโยชน์กับผู้ใช้ปลายทางส่วนใหญ่มากนัก แต่ก็ไม่อยากมารู้ทีหลังว่ามันจำเป็น ดังนั้นจึงเข้าใจการตัดสินใจของ Microsoft ที่เปิดใช้งานไว้เป็นค่าเริ่มต้น
  • ยกเว้นความพยายามที่ล้มเหลวในการหลีกเลี่ยงอัปเดตบนระบบ dual boot ก็ยังพอเข้าใจการตัดสินใจของ Microsoft

ความเห็นของ GN⁺

  • เหตุการณ์นี้แสดงให้เห็นว่าการหาสมดุลระหว่างความปลอดภัยกับประสบการณ์ผู้ใช้นั้นยากเพียงใด
  • ทั้ง Microsoft และ Linux distribution ต่างพยายามอย่างดีที่สุดเพื่อปกป้องผู้ใช้ แต่ในกระบวนการนี้ประสบการณ์ผู้ใช้อาจต้องถูกแลกไป
  • สำหรับผู้ใช้ที่ใช้ระบบ dual boot มีแนวโน้มสูงกว่าที่จะเจอปัญหาแบบนี้
  • ดังนั้นผู้ใช้ที่ใช้ dual boot ควรดูแลให้ทั้งสองระบบปฏิบัติการเป็นเวอร์ชันล่าสุดและอัปเดตอย่างสม่ำเสมอ
  • ในระยะยาว ดูเหมือนว่าจะจำเป็นต้องมีความร่วมมือและการประสานงานที่ดีกว่านี้ระหว่างชุมชน Linux และ Windows

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

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

 
GN⁺ 2024-08-23
ความคิดเห็นจาก Hacker News
  • ตอนล่าสุดของ Linux Unplugged พูดถึงการใช้ TPM เพื่อสร้างห่วงโซ่ความเชื่อถือสำหรับกระบวนการบูตของ Linux ซึ่งน่าสนใจมากเมื่อใช้ Clevis
  • เจตนาของ Microsoft คือให้ Windows Update ใช้อัปเดต SBAT เฉพาะกับระบบที่เป็น Windows ล้วน ๆ และปล่อยให้การตั้งค่าแบบดูอัลบูตยังคงเสี่ยงอยู่จนกว่าดิสโทรที่ติดตั้งไว้จะอัปเดต grub และแจกจ่ายอัปเดต SBAT ด้วยตนเอง
    • ถ้าอ่านลำดับการบูต EFI ก็น่าจะระบุชัดว่าควรบูต shim ก่อน เลยสงสัยว่าเกิดอะไรผิดพลาด
    • สงสัยว่าเป็นกรณีที่ผู้ใช้ในการตั้งค่าแบบดูอัลบูตใช้เมนูเฟิร์มแวร์เพื่อเลือก Linux หรือ Windows หรือไม่
    • เรื่องนี้ดูเหมือนเป็นการแก้ไขที่สมเหตุสมผลของ Microsoft แต่การสื่อสารทำได้ไม่ดี
  • ไม่ชอบข้อความผิดพลาดเวลา shim หรือ SB ล้มเหลวในการตรวจสอบความปลอดภัยแบบทั่วไปเลย อยากให้บอกให้ชัดว่าอะไรล้มเหลวแน่ ๆ และควรแก้ยังไง
  • คิดว่าเหตุผลหนึ่งที่ MS บังคับใช้ TPM2.0 และผลักดันอัปเดต SBAT ก็เพราะมีมัลแวร์ระดับรูทคิทแพร่หลายอยู่มาก
  • ในแง่ความเป็นจริงของการใช้ดูอัลบูต เมื่อ 10 ปีก่อนบน Win7/8/10 มีปัญหาเรื่อง suspend-to-hiberfile.sys และปัญหาที่อัปเดตแล้วทำให้ grub พังอยู่บ่อยมาก
    • เลยตัดสินใจใช้แต่ Linux มาตั้งแต่ 10 ปีก่อน และถ้าจำเป็นก็ใช้ VM หรือใช้คอมพิวเตอร์สำรองอีกเครื่องแทน
    • หลังจากนั้นก็ได้เรียนรู้วิธีตั้งค่า Secure Boot ให้ทำงานกับดิสโทรได้สำเร็จ รวมถึงวิธีปรับแต่งประสิทธิภาพและ passthrough ของ QEMU และยังทำ QEMU macOS VM ให้ใช้งานได้ด้วย
    • การต้องอัปเดตทุก ๆ สองสามเดือนเพื่อให้ XCode ใช้งานต่อได้เป็นเรื่องน่ารำคาญ แต่โดยรวมก็พอใจ
  • เวลา ติดตั้ง Linux ปกติสิ่งแรกไม่ใช่การปิด Secure Boot หรอกหรือ?
  • คำถามหลักคือ grub ที่ถูกปฏิเสธนั้นยังแพตช์ไม่ครบจริง ๆ หรือเป็นกรณีที่ดิสโทรแพตช์แล้วแต่ไม่ได้อัปเดต "security generation"
    • อยากรู้มากว่า MS พยายามตรวจจับการมีดูอัลบูตอย่างไร และหวังว่าจะมีใครสักคน (ที่ชำนาญกว่านี้) ช่วยย้อนวิศวกรรมส่วนนั้นจากตัวอัปเดต
  • เหตุผลที่ Microsoft ทำให้ระบบดูอัลบูตพังคือเพื่อไม่ให้มีช่องทางโจมตีระบบปฏิบัติการอื่นได้ และนี่ถือเป็นการละเมิดสัญญาทางสังคม
  • สงสัยว่าสิ่งนี้ขัดขวางการลบ Windows ออกจากระบบแล้วติดตั้ง Linux หรือไม่ หรือถ้าติดตั้ง Windows แล้วโมดูล TPM จะปนเปื้อนถาวรหรือไม่
  • สงสัยว่าสามารถอัปเดต grub จากฝั่ง Windows ได้หรือไม่ หรือแค่ปิด Secure Boot บูตเข้า Linux จากนั้นอัปเกรดแล้วเปิดกลับอีกครั้งก็พอ
  • จุดยืนของ MS ที่จะบล็อกการติดตั้ง grub รุ่นเก่าที่มีช่องโหว่ก็ดูสมเหตุสมผล แต่ผมใช้ Windows แค่สำหรับเล่นเกมกับซอฟต์แวร์เก่าเฉพาะตัวเพียงตัวเดียว และใช้แบบไม่ต่อเครือข่าย
    • ทันทีที่ยอมให้ Windows อัปเดต ทุกอย่างก็ต้องฝากไว้กับดวง
    • การที่ MS ย้ายคีย์รีจิสทรีไปมาและเล่นตลกกับผู้ใช้เพื่อบังคับใช้ "telemetry" (ML สำหรับสแกนโฆษณาและข้อมูลพฤติกรรม) ก็บอกอะไรได้มากพอแล้ว
    • เรื่องแบบนี้เกิดขึ้นแม้แต่บน Windows Pro และผมกำลังใช้ Win 10 อยู่