สรุปสั้น

นักวิจัยจาก Argus เปิดเผยช่องโหว่ที่ซ่อนอยู่นาน 27 ปีในระบบย่อย sppp(4) ของ OpenBSD ซึ่งใช้จัดการ synchronous PPP link สำหรับการเชื่อมต่อ PPPoE โดยช่องโหว่อยู่ในฟังก์ชัน sppp_pap_input() ที่รับผิดชอบการตรวจสอบ credential ของ Password Authentication Protocol (PAP) ตรรกะการเปรียบเทียบใช้ bcmp() โดยอ้างค่าความยาวจาก PAP frame ที่ผู้โจมตีควบคุมได้โดยตรง หากส่งค่าความยาวเป็นศูนย์ทั้ง username และ password การเปรียบเทียบจะไม่เคยล้มเหลว ทำให้ OpenBSD ยอมรับการยืนยันตัวตนโดยไม่ตรวจสอบ credential ใด ๆ ทั้งสิ้น

นอกจากนี้ หากส่งค่าความยาวที่ใหญ่กว่าขนาดจริงของ credential ที่จัดสรรไว้ bcmp() จะอ่านเกินขอบเขตหน่วยความจำ ทำให้เกิด kernel heap overread ที่อาจเปิดเผยเนื้อหาของหน่วยความจำข้างเคียง โค้ดที่มีช่องโหว่มีต้นกำเนิดจาก FreeBSD และถูกนำมาใช้ใน OpenBSD ตั้งแต่ปี 1999 ช่องโหว่ถูกรายงานเมื่อวันที่ 12 มิถุนายน 2569 และได้รับการแก้ไขภายใน 2 วัน

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

เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 17 มิถุนายน พ.ศ. 2569 ว่า นักวิจัยจากบล็อก Argus ได้เปิดเผยช่องโหว่ในระบบเครือข่ายของ OpenBSD ที่ซ่อนอยู่มาตั้งแต่ปี ค.ศ. 1999 โดยช่องโหว่อยู่ในฟังก์ชัน sppp_pap_input() ภายในระบบย่อย sppp(4) ซึ่งรับผิดชอบการจัดการ synchronous PPP link ที่ใช้ในการเชื่อมต่อ PPPoE ในระหว่างขั้นตอนการยืนยันตัวตนของ PPP ระบบที่ใช้ Password Authentication Protocol (PAP) จะต้องตรวจสอบ credential ของผู้ใช้ก่อนอนุญาตให้สร้าง session เครือข่าย แต่ตรรกะการตรวจสอบนี้มีข้อบกพร่องพื้นฐานมาตั้งแต่เริ่มแรก

โค้ดที่มีช่องโหว่มีต้นกำเนิดจาก FreeBSD ซึ่งดัดแปลงมาจาก implementation ของบริษัท Cronyx Engineering ที่เขียนขึ้นในกลางทศวรรษ 1990 แม้จะมีการอัปเดตหลายครั้งตลอดหลายปีที่ผ่านมา แต่ตรรกะการเปรียบเทียบที่มีข้อบกพร่องยังคงอยู่โดยไม่เปลี่ยนแปลงเป็นเวลา 27 ปี สิ่งที่น่าสังเกตคือ handler ของ CHAP ซึ่งเป็นโปรโตคอลยืนยันตัวตนอีกแบบหนึ่งในโค้ดเดียวกัน มีรูปแบบการตรวจสอบที่ปลอดภัยกว่าอยู่แล้ว โดยตรวจสอบความยาวให้ตรงกันก่อนการเปรียบเทียบ แต่ PAP handler กลับไม่ได้ใช้รูปแบบเดียวกัน

นักวิจัยได้สาธิต proof-of-concept ที่พิสูจน์ว่าสามารถสร้าง session สำเร็จทั้งหมด รวมถึงการกำหนดค่า IP และการสื่อสาร ICMP ได้จริง ยืนยันว่า exploit ใช้งานได้ในสภาพแวดล้อมจริง ช่องโหว่ถูก responsible disclosure เมื่อวันที่ 12 มิถุนายน พ.ศ. 2569 และทีมพัฒนา OpenBSD แก้ไขได้ภายใน 2 วัน

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

ข้อบกพร่องเกิดจากการที่ตรรกะการตรวจสอบ PAP credential ใช้ bcmp() เปรียบเทียบ username และ password โดยอ้างค่าความยาวจาก PAP frame ที่ผู้โจมตีส่งเข้ามาโดยตรง โค้ดเดิมตรวจสอบเฉพาะขอบบน (upper-bound) ว่าไม่เกิน AUTHMAXLEN แต่ไม่ได้ตรวจสอบกรณีที่ค่าความยาวเป็นศูนย์ เมื่อส่งค่าความยาวเป็นศูนย์ทั้ง username และ password การเรียก bcmp() จะเปรียบเทียบข้อมูล 0 ไบต์ซึ่งจะ return 0 (เท่ากัน) เสมอ ทำให้ระบบยอมรับ authentication โดยไม่ตรวจสอบ credential ใด ๆ

ปัญหาที่เกี่ยวข้องอีกประการหนึ่งเกิดจากข้อบกพร่องในการออกแบบเดียวกัน หากผู้โจมตีส่งค่าความยาวที่ใหญ่กว่าขนาดจริงของ credential ที่จัดสรรไว้ bcmp() จะอ่านเกินขอบเขตของหน่วยความจำที่จัดสรร ทำให้เกิด kernel heap overread ที่อาจเปิดเผยเนื้อหาของหน่วยความจำข้างเคียง สภาวะนี้สามารถ exploit ได้มากขึ้นหลังจากการอัปเดตในปี 2009 ที่เปลี่ยนจาก fixed-size buffer เป็น dynamically allocated memory

ช่องโหว่นี้สามารถเข้าถึงได้ผ่าน PPPoE data path โดยไม่ต้องมี credential ที่ถูกต้อง ผู้โจมตีที่ตั้ง rogue PPPoE server ภายใน broadcast domain เดียวกันสามารถปลอมตัวเป็นเซิร์ฟเวอร์ที่ถูกต้องได้ โดยทำขั้นตอน PPPoE discovery และ negotiation ให้เสร็จสิ้น จากนั้นส่ง PAP request ที่มี credential ความยาวศูนย์ เมื่อ OpenBSD client ยอมรับ request ก็จะสร้างการเชื่อมต่อและ traffic ของเครือข่ายจะถูก route ผ่าน endpoint ที่ผู้โจมตีควบคุม

แพตช์แก้ไขใช้วิธีเพิ่ม exact-length pre-check ก่อนการเรียก bcmp() ตามรูปแบบที่ปลอดภัยกว่าซึ่งมีอยู่แล้วใน CHAP handler โดยตรวจสอบว่าความยาวที่ส่งมาตรงกับความยาวจริงของ credential ที่เก็บไว้ หากไม่ตรงจะปฏิเสธทันทีโดยไม่ต้องเปรียบเทียบเนื้อหา

ผลกระทบต่อไทย

แม้ OpenBSD ไม่ได้ถูกใช้อย่างแพร่หลายในไทยเท่ากับ Linux หรือ Windows แต่มีการใช้งานในบางองค์กรที่ต้องการระบบปฏิบัติการที่เน้นความปลอดภัยสูง โดยเฉพาะเป็น firewall หรือ router ในสถาบันการศึกษาและหน่วยงานรัฐบางแห่ง หากองค์กรใดใช้ OpenBSD ในบทบาท PPPoE concentrator หรือ access gateway ช่องโหว่นี้จะอนุญาตให้ผู้โจมตีที่อยู่ใน broadcast domain เดียวกันสามารถ bypass การยืนยันตัวตนและ route traffic ผ่านเครื่องที่ตนควบคุมได้ ซึ่งอาจนำไปสู่การดักจับข้อมูลหรือโจมตีแบบ man-in-the-middle

คำแนะนำ

องค์กรที่ใช้ OpenBSD โดยเฉพาะในสภาพแวดล้อมที่พึ่งพาการยืนยันตัวตนผ่าน PPPoE ควรติดตั้งแพตช์ล่าสุดทันที โดยทั่วไปควรหลีกเลี่ยงการใช้ PAP เนื่องจากเป็นโปรโตคอลที่ส่ง credential แบบ plaintext และเปลี่ยนไปใช้ CHAP หรือโปรโตคอลยืนยันตัวตนที่ปลอดภัยกว่าแทน ผู้ดูแลระบบควรตรวจสอบว่ามีอุปกรณ์ PPPoE ที่ไม่ได้รับอนุญาตอยู่ใน broadcast domain หรือไม่ และพิจารณาแบ่ง segment เครือข่ายเพื่อจำกัดขอบเขตที่ rogue PPPoE server จะสามารถเข้าถึงได้

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