Canonical แก้ CVE-2026-112816 ใน LXD ช่องสวมสิทธิ์ผ่าน TLS certificate chain

Canonical เตือน CVE-2026-112816 ใน LXD: ใบรับรองลูกค้าสาธารณะอาจถูกใช้สวมสิทธิ์เข้าถึงคลัสเตอร์

Canonical เปิดเผยช่องโหว่สำคัญในกลไกตรวจสอบใบรับรอง TLS ของ LXD และ MicroCloud เมื่อวันที่ 28 ตุลาคม 2026 ภายใต้หมายเลข CVE-2026-112816 สำหรับ LXD ผู้โจมตีที่เชื่อมต่อ HTTPS API ของ LXD ได้และมีใบรับรองสาธารณะของไคลเอนต์ที่ระบบไว้วางใจ อาจสร้าง certificate chain ที่ทำให้เซิร์ฟเวอร์ยอมรับตนเป็นไคลเอนต์รายนั้น แม้ไม่มี private key ของไคลเอนต์เป้าหมาย Canonical ระบุว่าผลกระทบอาจรุนแรงถึงการได้สิทธิระดับ root บนโฮสต์ ขึ้นกับสิทธิของตัวตนที่ถูกสวมรอย

ประเด็นนี้ควรได้รับความสนใจจากผู้ดูแลระบบที่เปิด remote API ให้เข้าถึงได้ รวมถึงผู้ใช้งาน MicroCloud เพราะ Canonical ระบุว่าในขั้นตอนเข้าร่วมคลัสเตอร์ ผู้โจมตีอาจดักรับใบรับรอง TLS สาธารณะของสมาชิกที่กำลังเข้าร่วม แล้วใช้สวมรอยเป็นสมาชิกดังกล่าวได้ ความเสี่ยงไม่ได้เกิดจากการขโมย private key โดยตรง แต่เกิดจากวิธีที่เซิร์ฟเวอร์ใช้ข้อมูลใน certificate chain เพื่อตัดสินว่าใครเป็นผู้เชื่อมต่อ

วันเปิดเผย วันที่เผยแพร่ CVE และวันออกแพตช์

ประกาศความปลอดภัยของ Canonical ใน Ubuntu Discourse เผยแพร่ครั้งแรกวันที่ 28 ตุลาคม 2026 เวลา 17:50:37 UTC โดยระบุลักษณะช่องโหว่ ผลกระทบ และหมายเลข CVE อย่างชัดเจน นี่เป็นวันเปิดเผยต่อสาธารณะครั้งแรกจากผู้พัฒนาที่ตรวจยืนยันได้ ระเบียน CVE Program สำหรับ CVE-2026-112816 เผยแพร่ครั้งแรกวันที่ 30 ตุลาคม 2026 เวลา 16:42:06 UTC ขณะที่ตารางแพตช์ในประกาศของ Canonical ระบุวันออกเวอร์ชันแก้ไขสำหรับ LXD และ MicroCloud เป็น 29 ตุลาคม 2026 ทั้งวันเปิดเผยและวันเผยแพร่ระเบียน CVE อยู่ภายใน 48 ชั่วโมงก่อนรอบตรวจนี้

Canonical ระบุด้วยว่าได้รับแจ้งประเด็นจากโครงการ Incus แล้วตรวจยืนยันว่ากระทบ LXD เช่นกัน ประกาศที่ใช้อ้างอิงนี้เป็นข้อมูลของ Canonical LXD และ MicroCloud จึงไม่ควรนำเลขรุ่นแก้ไขของ LXD ไปเทียบกับ Incus หรือสรุปว่ารุ่นของอีกโครงการหนึ่งมีขอบเขตเหมือนกันโดยอัตโนมัติ

ข้อผิดพลาดอยู่ตรงไหน

ในการยืนยันตัวตนแบบ mutual TLS ฝั่งไคลเอนต์ส่งชุดใบรับรองไปให้ HTTPS listener ของ LXD ตรวจสอบ ใบรับรองตัวแรกหรือ leaf certificate ต้องสัมพันธ์กับ private key ที่ไคลเอนต์ถืออยู่ เพราะไคลเอนต์ต้องพิสูจน์การครอบครองกุญแจดังกล่าว แต่การตรวจสอบเดิมของ LXD เปรียบเทียบใบรับรองทุกใบที่ไคลเอนต์ส่งมาใน chain กับรายการตัวตนที่ไว้วางใจ หากใบรับรองสาธารณะของไคลเอนต์ที่ระบบไว้วางใจถูกวางไว้เป็นใบรับรองตัวกลาง ระบบอาจตีความว่าผู้เชื่อมต่อเป็นไคลเอนต์ที่ไว้วางใจนั้น แม้ leaf certificate ที่พิสูจน์ private key จริงจะเป็นของผู้โจมตี

เงื่อนไขการโจมตีตามประกาศคือผู้โจมตีต้องเข้าถึง LXD HTTPS API และมีใบรับรองสาธารณะของไคลเอนต์เป้าหมายที่ถูกเพิ่มไว้ใน trust store การมีข้อมูลสาธารณะนี้ไม่เท่ากับการมี private key แต่ข้อผิดพลาดทำให้ข้อมูลนั้นถูกใช้สวมสิทธิ์ได้ เมื่อสวมรอยสำเร็จ สิทธิที่ได้จะอิงสิทธิของตัวตนเป้าหมาย ไม่ใช่สิทธิของผู้โจมตีเดิม จึงต้องประเมินว่าบัญชีหรือสมาชิกคลัสเตอร์ที่มีใบรับรองเผยแพร่ได้ถือสิทธิอะไรบ้าง

รุ่นที่ได้รับผลกระทบและรุ่นแก้ไข

ระเบียน CVE ของ Canonical ระบุช่วงรุ่น LXD ที่กระทบเป็น 4.0.14 ก่อน 4.0.15, 5.0.10 ก่อน 5.0.11, 5.21.8 ก่อน 5.21.9 และ 6.9.0 ก่อน 6.10.1 ตามสายรุ่นที่เกี่ยวข้อง ผู้ดูแลควรตรวจรุ่นที่ติดตั้งจริงในช่องทาง snap ของตน ไม่ใช้เพียงชื่อสายรุ่นหลักในการตัดสินว่าปลอดภัยแล้ว

ตารางแก้ไขอย่างเป็นทางการของ Canonical ระบุ LXD ช่องทาง 6/stable แก้ใน 6.10.1, 5.21/stable แก้ใน 5.21.9, 5.0/stable แก้ใน 5.0.11 และ 4.0/stable แก้ใน 4.0.15 ส่วน MicroCloud ช่องทาง 2/stable แก้ใน 2.1.5 และ 3/stable แก้ใน 3.4.1 ทั้งหมดระบุวันออกเป็น 29 ตุลาคม 2026 ในประกาศเดียวกัน หมายเลข CVE ที่ระบุไว้ในระเบียนเป็นของผลิตภัณฑ์ LXD ส่วนการกล่าวถึง MicroCloud และรุ่นแก้ไขอ้างอิงประกาศความปลอดภัยของ Canonical โดยตรง

วิธีรับมือสำหรับผู้ดูแลระบบ

Canonical แนะนำให้อัปเดต LXD และ MicroCloud เป็นรุ่นล่าสุดในช่องทางที่ใช้งาน โดยตัวอย่างคำสั่งสำหรับระบบที่ติดตั้งผ่าน snap คือ sudo snap refresh lxd และ sudo snap refresh microcloud ก่อนทำในระบบผลิตจริงควรตรวจ snapshot หรือการสำรองข้อมูลที่องค์กรใช้อยู่ ตรวจเวอร์ชันหลังอัปเดต และยืนยันว่าช่องทาง snap ของเครื่องได้รับรุ่นแก้ไขตามตารางแล้ว Canonical ระบุว่าการปล่อย LXD รุ่นย่อยสู่ stable เป็นแบบ progressive rollout จาก candidate ดังนั้นการสั่ง refresh แล้วต้องตรวจผลลัพธ์จริง ไม่ควรถือว่าคำสั่งสำเร็จเท่ากับได้รุ่นที่แก้แล้วเสมอ

ระหว่างรอรุ่นแก้ไข ให้ลดจำนวนผู้ที่เข้าถึง HTTPS API ด้วยการจำกัดเครือข่ายหรือไฟร์วอลล์ตามสถาปัตยกรรมขององค์กร และตรวจรายการใบรับรองไคลเอนต์ที่ได้รับความไว้วางใจ โดยเฉพาะตัวตนที่มีสิทธิสูง แนวทางนี้ช่วยลดพื้นที่ที่ผู้โจมตีเข้าถึงได้ แต่ไม่แก้ข้อผิดพลาดในการตรวจ certificate chain ผู้ดูแล MicroCloud ควรประเมินเส้นทางเข้าร่วมคลัสเตอร์และเครือข่ายที่เกี่ยวข้องด้วย เพราะประกาศระบุความเป็นไปได้ในการดักใบรับรองสาธารณะของสมาชิกที่กำลังเข้าร่วม

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

แหล่งข้อมูลต้นทาง

• Canonical: ประกาศความปลอดภัย LXD และ MicroCloud
• CVE Program: ระเบียน CVE-2026-112816