Krill 0.16.1 แก้ 3 CVE กระทบ token และสิทธิ์จัดการ RPKI CA
NLnet Labs ออก Krill 0.16.1 แก้ CVE-2026-109140, CVE-2026-109141 และ CVE-2026-109142 ที่เกี่ยวกับ token และสิทธิ์ CA
Krill 0.16.1 แก้สาม CVE กระทบการเข้าสู่ระบบและสิทธิ์จัดการ RPKI CA
NLnet Labs เผยแพร่ Krill 0.16.1 เพื่อแก้ช่องโหว่สามรายการในซอฟต์แวร์ Certificate Authority และ publication server สำหรับ RPKI ได้แก่ CVE-2026-109140, CVE-2026-109141 และ CVE-2026-109142 ทั้งสามรายการมีผลต่อระบบที่ใช้ Krill 0.16.0 หรือต่ำกว่า ตามคำแนะนำของผู้พัฒนา แต่เงื่อนไขการโจมตีไม่เหมือนกัน รายการแรกต้องใช้การเข้าสู่ระบบหลายผู้ใช้ ส่วนอีกสองรายการเกี่ยวข้องกับการจำกัดสิทธิ์ของผู้ปฏิบัติงาน CA การแก้ไขอยู่ในรุ่น 0.16.1 หรือใหม่กว่า
ลำดับเวลาที่ตรวจสอบจากต้นทาง
ก่อนออกรุ่นแก้ไข โครงการเปิด pull request ที่อธิบายการเปลี่ยนแปลงด้านความปลอดภัยต่อสาธารณะเมื่อ 2 พฤศจิกายน 2026 เวลา 12:43:59 UTC สำหรับปัญหา nonce ของ token, 13:29:05 UTC สำหรับสิทธิ์ bulk import และ 13:45:59 UTC สำหรับการตรวจ child handle ใน local RFC 6492 exchange เวลานี้เป็นหลักฐานการเปิดเผยที่เก่ากว่าหน้ารุ่นเผยแพร่ จึงใช้เป็นวันเปิดเผยครั้งแรกที่ยืนยันได้ ไม่ใช้เวลาที่ NVD รับระเบียนภายหลังเป็นวันเริ่มข่าว
Krill v0.16.1 เผยแพร่วันที่ 2 พฤศจิกายน 2026 เวลา 15:28:20 UTC และระบุชื่อ CVE ทั้งสามในบันทึกรุ่น ระเบียน CVE แรกเผยแพร่วันเดียวกันเวลา 15:41:58 UTC สำหรับ CVE-2026-109140, 15:42:05 UTC สำหรับ CVE-2026-109141 และ 15:42:13 UTC สำหรับ CVE-2026-109142 ทั้งวันเปิดเผยต่อสาธารณะและวันเผยแพร่ระเบียน CVE แรกอยู่ในช่วง 48 ชั่วโมงก่อนรอบตรวจนี้ แหล่งต้นทางที่ใช้ตรวจผลกระทบและเวอร์ชันคือคำแนะนำแบบข้อความของ NLnet Labs, pull request ของโครงการ และบันทึกรุ่นบน GitHub
CVE-2026-109140: token เข้าสู่ระบบใช้ nonce ซ้ำหลังรีสตาร์ต
คำแนะนำของ NLnet Labs ระบุว่า Krill เข้ารหัส token ของเซสชันเข้าสู่ระบบโดยใช้ nonce ที่สร้างจากตัวนับ ซึ่งกลับไปเริ่มที่ศูนย์เมื่อ Krill รีสตาร์ต การใช้คู่ key และ nonce ซ้ำเป็นเงื่อนไขที่อาจทำให้ผู้ใช้ที่เข้าสู่ระบบได้สร้าง token ที่มีสิทธิ์ admin ได้ ปัญหานี้สำคัญกับระบบที่เปิด multi-user login; บันทึกรุ่นระบุชัดว่าหากไม่ได้เปิดความสามารถนี้ เงื่อนไขของช่องโหว่รายการดังกล่าวไม่เกิดขึ้นแบบเดียวกัน
ผลกระทบคือการยกระดับสิทธิ์จากผู้ใช้ที่มีบัญชีเข้าสู่ระบบไปสู่สิทธิ์ผู้ดูแล ไม่ควรตีความว่าเป็นการยึดระบบจากผู้ที่ไม่มีข้อมูลเข้าสู่ระบบเลย โครงการแก้ด้วยการทำให้ส่วนของสถานะการเข้ารหัสสำหรับ HTTP authentication ไม่กลับมาใช้ซ้ำหลังรีสตาร์ต ผู้ดูแลควรอัปเดตระบบและทบทวนเซสชันที่ยังคงมีผล โดยเฉพาะระบบที่ให้ผู้ใช้หลายคนจัดการ CA ผ่านหน้าเว็บหรือ API
CVE-2026-109141: สิทธิ์จำกัด CA ไม่ถูกบังคับใน bulk import
Krill อาจกำหนด role ให้ผู้ใช้จัดการ CA ได้เฉพาะรายการที่กำหนด เช่น cas = [...] แต่คำแนะนำระบุว่าเมื่อคำขอไม่ได้ผูกกับ CA เดี่ยว ระบบใช้ชุดสิทธิ์ของ role นั้นโดยไม่ตรวจทุก CA ที่อยู่ในคำขอ เส้นทางที่เป็นปัญหาคือ POST /api/v1/bulk/cas/import ผู้ใช้ที่ควรจัดการได้เพียงบาง CA อาจเพิ่ม child CA ใต้ CA อื่น กำหนดทรัพยากรให้ child และสร้าง ROA ตามข้อมูลในคำขอได้ นี่เป็นการข้ามขอบเขตการมอบหมายสิทธิ์ภายในระบบ RPKI CA ซึ่งอาจส่งผลต่อข้อมูลการรับรอง prefix และการประกาศเส้นทาง
แพตช์ของโครงการเพิ่มการตรวจสิทธิ์สำหรับ ทุก CA ก่อนดำเนิน bulk import ผู้ดูแลที่แบ่งงานให้หลายทีมจัดการ CA คนละชุดควรตรวจว่ามีการใช้งาน bulk import ระหว่างช่วงก่อนอัปเดตหรือไม่ ตรวจ child CA และ ROA ที่ถูกสร้างใหม่ รวมถึงบันทึกผู้เรียก API การจำกัดสิทธิ์เฉพาะ CA จะมีความหมายก็ต่อเมื่อเส้นทางแบบ bulk บังคับข้อจำกัดเดียวกัน
CVE-2026-109142: local parent เชื่อ child handle โดยไม่ตรวจ
เมื่อ parent CA อยู่บน Krill server เดียวกัน กระบวนการ RFC 6492 provisioning สามารถทำงานภายในโปรเซสได้โดยไม่ต้องสร้างและตรวจข้อความ CMS ที่ลงลายมือชื่อแบบกรณีระยะไกล คำแนะนำของ NLnet Labs ระบุว่าเส้นทางนี้เชื่อค่า child_handle ที่ผู้เรียกกำหนดในข้อมูลติดต่อ parent โดยไม่ตรวจว่า child นั้นเป็นของ CA ที่ทำคำขอจริง ผู้ปฏิบัติงาน CA หนึ่งจึงอาจแสดงตัวเป็น child ของ CA อื่นบนเซิร์ฟเวอร์เดียวกันได้
ขอบเขตคือการใช้งานหลาย CA และ local parent/child exchange บนเซิร์ฟเวอร์เดียวกัน ไม่ใช่การโจมตีได้กับ Krill ทุกการตั้งค่า แพตช์เพิ่มการตรวจ child handle ก่อนดำเนินการ ผู้ดูแลควรตรวจความสัมพันธ์ parent/child ที่ตั้งไว้และบันทึกการเปลี่ยนแปลง provisioning ในช่วงก่อนอัปเดต โดยเฉพาะการติดตั้งที่มีผู้ดูแลหลายกลุ่มในเซิร์ฟเวอร์เดียว
แนวทางรับมือ
อัปเดต Krill เป็น 0.16.1 หรือใหม่กว่า จากช่องทางของ NLnet Labs แล้วตรวจว่าบริการที่กำลังรันใช้ไบนารีรุ่นใหม่จริง ควรสำรองข้อมูล CA และตรวจการทำงานของการออกใบรับรอง การสร้าง ROA และการเข้าสู่ระบบหลังอัปเดต หากยังอัปเดตทันทีไม่ได้ ให้จำกัดบัญชีที่เข้าถึง multi-user login และ bulk import ลดสิทธิ์ของผู้ใช้ที่ไม่จำเป็น และตรวจความสัมพันธ์ CA อย่างใกล้ชิด มาตรการเหล่านี้ช่วยลดโอกาสเกิดเหตุ แต่ไม่แทนแพตช์
ผู้ดูแลควรบันทึกแยกสามวันสำคัญสำหรับแต่ละรายการ: เปิดเผยครั้งแรกผ่าน pull request วันที่ 2 พฤศจิกายน 2026, ออกแพตช์ 0.16.1 วันที่ 2 พฤศจิกายน 2026, และ เผยแพร่ระเบียน CVE แรกวันที่ 2 พฤศจิกายน 2026 เพื่อไม่ให้การปรากฏของเลข CVE ในฐานข้อมูลภายหลังถูกเข้าใจผิดว่าเป็นวันเริ่มต้นของปัญหา