สรุปสั้น

EDK II คือ โค้ดโอเพนซอร์สที่ผู้ผลิตฮาร์ดแวร์เกือบทุกรายใช้เป็นฐานสร้างเฟิร์มแวร์ UEFI ซึ่งเป็นซอฟต์แวร์ชุดแรกที่ทำงานเมื่อเปิดเครื่องก่อนระบบปฏิบัติการ โครงการ TianoCore ผู้ดูแล EDK II ออกประกาศเมื่อวันที่ 22 ตุลาคม 2569 เปิดเผยช่องโหว่ CVE-2026-97631 คะแนน 9.5 จาก 10 เป็นบั๊ก buffer overflow ในโค้ดบูตผ่านเครือข่าย (PXE) ที่อยู่ในโค้ดมาตั้งแต่ปี 2010 ผู้โจมตีที่เข้าถึงเครื่องทางเครือข่ายได้ในช่วงที่เครื่องกำลังบูตแบบ PXE ส่งข้อความแจ้งข้อผิดพลาดที่ประดิษฐ์ขึ้นเพียงข้อความเดียวก็ทำให้บูตค้างได้ หรือถ้าสร้าง exploit ให้ตรงกับ build ของเฟิร์มแวร์ก็รันโค้ดของตัวเองได้ก่อนที่ Secure Boot และกลไกป้องกันตอนบูตจะเริ่มทำงาน

ช่องโหว่นี้กระทบเครื่องที่บูตผ่านเครือข่ายเป็นหลัก ซึ่งส่วนใหญ่ คือ เซิร์ฟเวอร์และอุปกรณ์ในศูนย์ข้อมูล ไม่กระทบเครื่องที่บูตจากดิสก์ในเครื่องเท่านั้น ยังไม่มีรายงานการโจมตีจริง แต่รายละเอียดถูกเปิดเผยก่อนกำหนดเพราะมีคนส่ง pull request ที่ระบุเลข CVE ขึ้นสาธารณะ ปัญหาใหญ่ คือ แม้โค้ดแก้ถูก merge แล้ว EDK II ยังไม่มีรุ่นเสถียรที่รวมการแก้ และผู้ใช้ต้องรอผู้ผลิตเฟิร์มแวร์ออก BIOS/UEFI ใหม่ ระหว่างนี้ผู้ดูแลควรปิด PXE ในเครื่องที่ไม่จำเป็นต้องบูตผ่านเครือข่าย

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 28 ตุลาคม 2569 ว่าช่องโหว่วิกฤตอายุ 16 ปีใน EDK II เปิดทางให้รันโค้ดก่อนระบบปฏิบัติการโหลด โดย TianoCore ให้คะแนน 9.5 และประกาศเมื่อวันที่ 22 ตุลาคม ส่วนบริษัท Red Hat และบริษัท SUSE ซึ่งส่งโค้ดนี้ไปกับดิสทริบิวชันของตน ประเมินว่าผู้โจมตีต้องอยู่ในเครือข่ายข้างเคียง (adjacent network) ไม่ใช่โจมตีข้ามอินเทอร์เน็ตได้

ไทม์ไลน์ของการเปิดเผยเริ่มจากผู้ค้นพบ 2 คน คือ นาย Alex Matrosov จากบริษัท Anthropic และนาย Dan Holmes-Mitra จากบริษัท Google ซึ่งวางแผนเปิดเผยแบบประสานงานในเดือนมกราคม 2570 แต่เมื่อวันที่ 28 กันยายน มี pull request เข้า EDK II ที่วิศวกรของบริษัท AMI ลงชื่อรับรอง ระบุเลข CVE พร้อมโค้ดแก้แบบสาธารณะ TianoCore จึงออกประกาศเร็วกว่ากำหนดหลายสัปดาห์ โค้ดแก้เข้าสาขาพัฒนาหลักเมื่อวันที่ 15 ตุลาคม

The Hacker News ไล่ประวัติโค้ดแล้วพบว่าลูปคัดลอกที่ผิดพลาดอยู่มาตั้งแต่ commit เมื่อเดือนพฤศจิกายน 2010 และตรวจ release tag เมื่อวันที่ 28 ตุลาคม พบว่ารุ่นเสถียรล่าสุด edk2-stable202608 (21 สิงหาคม) ออกก่อนการแก้ ประกาศยังระบุเวอร์ชันที่แก้ว่า “ยังไม่ได้แพตช์” ขณะที่ Project Mu ซึ่งเป็น fork ที่เสริมความแข็งแรงของบริษัท Microsoft ดึงการแก้เข้า release branch และออก build แล้วเมื่อวันที่ 26 ตุลาคม

ด้านผู้ผลิตชิป บริษัท Intel ให้ข้อมูลกับเว็บไซต์ Ars Technica ว่าไม่พบผลิตภัณฑ์เชิงพาณิชย์ที่ยังอยู่ในการสนับสนุนด้านความปลอดภัยได้รับผลกระทบ และโค้ดอ้างอิงของ Intel ไม่ได้รวมฟังก์ชัน EDK2 ส่วนนี้ แต่ผู้ผลิตบอร์ดหรือผู้ประกอบระบบอาจใส่เพิ่มเองได้ ส่วนบริษัท Arm ระบุว่าช่องโหว่ไม่เกี่ยวกับผลิตภัณฑ์ของตนโดยตรง

ข้อจำกัดของข้อมูล คือ ยังไม่มีใครรู้ว่าผลิตภัณฑ์ที่วางขายจริงมีโค้ดที่มีช่องโหว่กี่รุ่น บริษัท AMD, Phoenix Technologies, AMI, Microsoft และ Amazon ไม่ได้ตอบคำถามของ Ars Technica และ TianoCore ก็ไม่ได้ตอบเช่นกัน ณ การอัปเดตวันที่ 27 ตุลาคม ช่องโหว่ยังไม่อยู่ในบัญชี KEV ของ CISA

รายละเอียดช่องโหว่

สาเหตุ — ตัวตรวจขนาดในโค้ด PXE ผิดทั้งฝั่ง IPv4 และ IPv6 ระหว่างบูต PXE เครื่องจะโหลดอิมเมจเริ่มต้นจากเครือข่ายแทนดิสก์ และไดรเวอร์ PXE จะรอรับข้อความแจ้งข้อผิดพลาด ICMP กับข้อความสถานะจากอุปกรณ์เครือข่าย แล้วคัดลอกแต่ละข้อความลงพื้นที่หน่วยความจำขนาดตายตัว 504 ไบต์ เมื่อข้อความยาวเกิน 504 ไบต์ ข้อมูลจะล้นออกไปทับหน่วยความจำข้างเคียงด้วยข้อมูลที่ผู้โจมตีเลือกเอง

เงื่อนไข — ผู้โจมตีไม่ต้องมีรหัสผ่านหรือสิทธิ์ใด ๆ บนเครื่อง ขอแค่ส่งข้อความ error ที่ประดิษฐ์ขึ้นหนึ่งข้อความไปยังที่อยู่ของเครื่องในช่วงสั้น ๆ ที่เครื่องกำลังบูตผ่านเครือข่าย PXE เปิดเป็นค่าเริ่มต้นใน build มาตรฐานของ EDK II ช่องโหว่กระทบ EDK II จนถึงและรวม edk2-stable202608 ซึ่งเป็นฐานของผู้ผลิต BIOS อิสระอย่าง AMI, Insyde และ Phoenix รวมถึง Project Mu ฝั่งดิสทริบิวชัน Red Hat ระบุว่าแพ็กเกจ edk2 ใน Red Hat Enterprise Linux 8, 9 และ 10 ได้รับผลกระทบและยังไม่แก้ SUSE และ Debian ก็ระบุสถานะเดียวกัน

ผลลัพธ์ — ผลที่ทำได้ง่าย คือ เครื่องค้างตอนบูตและเปิดไม่ขึ้น การรันโค้ดทำได้ยากกว่ามาก ประกาศระบุว่าผู้โจมตีที่รู้ build ของเฟิร์มแวร์แน่ชัดจะวาง “event ปลอม” ให้เฟิร์มแวร์เรียกโค้ดของผู้โจมตีได้ exploit จึงต้องสร้างเฉพาะ build โค้ดที่รันได้จะทำงานในระดับเฟิร์มแวร์ก่อนที่ Secure Boot จะตรวจสอบอะไร ซึ่ง คือ เหตุที่ช่องโหว่นี้ร้ายแรง โค้ดที่ฝังแบบนี้รันครั้งเดียวและไม่อยู่รอดหลังรีบูต แต่ครั้งเดียวก็พอให้ติดตั้งโค้ดอื่นที่ทำงานทุกครั้งที่บูตได้

ฉากการโจมตีที่เป็นไปได้ — นักวิจัยเฟิร์มแวร์หลายรายบอก Ars Technica ว่าช่องโหว่นี้ไม่ใช่ทางเข้าเครือข่ายด้วยตัวเอง ผู้โจมตีที่สมจริง คือ คนใน หรือผู้ที่มีที่มั่นในเครือข่ายภายในแล้วและต้องการเจาะลึกขึ้น นาย HD Moore ผู้สร้าง Metasploit และหัวหน้าฝ่ายวิจัยของบริษัท Dragos ชี้ว่าการยึด flow ของโปรแกรมในจังหวะที่กระบวนการบูตยังเข้าถึง TPM ได้ อาจใช้ทำลายการเข้ารหัสดิสก์ได้เมื่อผู้โจมตีเข้าถึงเครือข่ายได้ระยะสั้น และจะง่ายกว่านั้นถ้าเครื่องถูกขโมย

การแก้ไข — commit แก้จะตัดข้อความที่ยาวเกินให้เหลือ 504 ไบต์แทนที่จะปล่อยให้ล้น นาย Jesse Michael นักวิจัยหลักของบริษัท Eclypsium ระบุว่าต่างจากการข้าม Secure Boot อย่าง BootHole และ BlackLotus ช่องโหว่นี้แก้ด้วยโค้ดธรรมดาได้ ไม่ต้องเพิกถอนใบรับรองหรือคีย์ ส่วนนี้ของ EDK II เคยมีปัญหามาก่อน เมื่อเดือนมกราคม 2567 นักวิจัยเปิดเผย PixieFail ชุด 9 ช่องโหว่ที่เข้าถึงได้ตอนบูต PXE เช่นกัน และโครงการ fuzzing ที่เริ่มหลัง PixieFail ก็ไม่ได้จับบั๊กนี้

ผลกระทบ

กลุ่มที่โดนโดยตรง คือ องค์กรที่ให้เซิร์ฟเวอร์หรือเครื่องในศูนย์ข้อมูลบูตผ่านเครือข่าย เช่น ฟาร์มเซิร์ฟเวอร์ที่ติดตั้งระบบอัตโนมัติด้วย PXE, คลัสเตอร์ HPC และเครื่อง thin client รวมถึงเครื่องเสมือนที่ใช้เฟิร์มแวร์ OVMF จากแพ็กเกจ edk2 ของดิสทริบิวชัน Linux ส่วนผู้ใช้บ้านและสำนักงานที่บูตจากดิสก์ในเครื่องไม่กระทบ จำนวนผลิตภัณฑ์จริงที่มีโค้ดนี้ยังไม่ชัดเพราะผู้ผลิตหลายรายยังไม่ให้ข้อมูล

ความเสี่ยงหลักไม่ใช่การเจาะจากภายนอก แต่เป็นการยกระดับจากที่มั่นในเครือข่ายภายในไปสู่ระดับเฟิร์มแวร์ ซึ่งเครื่องมือ EDR และการตรวจของระบบปฏิบัติการมองไม่เห็น และอาจใช้ติดตั้ง implant ถาวรหรือทำลายการเข้ารหัสดิสก์ที่ผูกกับ TPM ได้ เมื่อแพตช์เป็นสาธารณะแล้ว ผู้โจมตีที่มีฝีมือก็ศึกษาเพื่อสร้าง exploit ได้ ในขณะที่ช่องว่างระหว่างโค้ดแก้กับ BIOS ที่ผู้ผลิตส่งมาจริงมักกินเวลาหลายเดือน

คำแนะนำ

  • ปิด PXE ทันทีในเครื่องที่ไม่จำเป็นต้องบูตผ่านเครือข่าย ทั้งใน BIOS/UEFI setup และใน boot order เพราะช่องโหว่เข้าถึงได้เฉพาะตอนบูต PXE และยังไม่มี workaround อื่นในประกาศ
  • จำกัดเครือข่ายที่ใช้บูต PXE แยกเป็น VLAN เฉพาะที่มีเฉพาะเซิร์ฟเวอร์ DHCP/TFTP ที่เชื่อถือได้ และกรอง ICMP ที่ผิดปกติในเซกเมนต์นั้น เพื่อลดโอกาสที่คนในเครือข่ายเดียวกันจะส่งแพ็กเก็ตถึงเครื่องตอนบูต
  • ติดตามประกาศของผู้ผลิตเซิร์ฟเวอร์และเฟิร์มแวร์ (Dell, HPE, Lenovo, Supermicro, AMI, Insyde, Phoenix) แล้วติดตั้ง BIOS/UEFI ที่อ้าง CVE-2026-97631 ทันทีที่ออก
  • อัปเดตแพ็กเกจ edk2/OVMF บน Linux เมื่อ Red Hat, SUSE หรือ Debian ออกแพ็กเกจแก้ แล้วรีสตาร์ต VM ที่ใช้เฟิร์มแวร์นั้น
  • เฝ้าดูทราฟฟิกเครือข่ายและล็อกตอนบูต มองหาข้อความ ICMP error ที่ยาวผิดปกติ (เกิน 504 ไบต์) ส่งไปยังเครื่องที่กำลังบูต PXE และเครื่องที่บูตค้างโดยไม่ทราบสาเหตุ
  • ระยะยาว ใช้ TPM ร่วมกับ PIN หรือการยืนยันตัวตนก่อนบูตสำหรับการเข้ารหัสดิสก์บนเครื่องสำคัญ และตรวจความสมบูรณ์ของเฟิร์มแวร์เป็นระยะ

แหล่งอ้างอิง