สรุปสั้น

นักวิจัยด้านความปลอดภัยจากบริษัท FoxIO เปิดเผยช่องโหว่ร้ายแรงที่ตั้งชื่อเล่นว่า XRING ในไลบรารี XQUIC ซึ่งเป็นไลบรารี QUIC และ HTTP/3 แบบโอเพนซอร์สที่พัฒนาโดยบริษัท Alibaba โดยความผิดพลาดของตัวแปรเพียงบรรทัดเดียวเปิดทางให้ผู้โจมตีจากระยะไกลส่งทราฟฟิกที่ถูกต้องตามกฎทุกประการเข้าไปทำให้กระบวนการของเซิร์ฟเวอร์ล่มได้ในพริบตา จุดที่น่ากังวลคือการโจมตีนี้ไม่ต้องล็อกอิน ไม่ต้องใช้แพ็กเก็ตที่ผิดรูปแบบ และใช้ข้อมูลเพียงประมาณ 260 ไบต์เท่านั้นก็เพียงพอที่จะปิดเซิร์ฟเวอร์ลงได้

เนื่องจาก XQUIC เป็นโอเพนซอร์ส ความเสี่ยงจึงไม่ได้จำกัดอยู่แค่ Alibaba เท่านั้น แต่ครอบคลุมทุกเซิร์ฟเวอร์ที่นำไลบรารีนี้ไปฝังใช้และเปิดบริการ HTTP/3 ด้วยค่าตั้งต้น QPACK แบบดีฟอลต์ ซึ่งรวมถึง Tengine เว็บเซิร์ฟเวอร์ของ Alibaba ที่พัฒนาต่อยอดจาก Nginx และทำหน้าที่รองรับระบบคลาวด์และ CDN ของบริษัทบนเว็บไซต์ยักษ์ใหญ่อย่าง Taobao และ Alipay ช่องโหว่นี้กระทบทุกเวอร์ชันไปจนถึง v1.9.4 ซึ่งเป็นรุ่นล่าสุด และ ณ วันที่ 10 กรกฎาคม 2569 ยังไม่มีเวอร์ชันแก้ไขและยังไม่มีการออกหมายเลข CVE ผู้ดูแลระบบทำได้เพียงตั้งค่า SETTINGS_QPACK_MAX_TABLE_CAPACITY เป็น 0 เพื่อปิดตาราง dynamic ของ QPACK หรือปิดการรองรับ HTTP/3 ไปเลยเป็นการชั่วคราว

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 10 กรกฎาคม 2569 ว่า นาย Sébastien Féry นักวิจัยจากบริษัท FoxIO ได้เปิดเผยช่องโหว่ XRING ต่อสาธารณะเมื่อวันที่ 8 กรกฎาคม โดยระบุว่าช่องโหว่นี้ไม่ต้องอาศัยการยืนยันตัวตนและไม่ต้องใช้แพ็กเก็ตที่ผิดรูปแต่อย่างใด เพียงส่งทราฟฟิก QPACK ธรรมดาราว 260 ไบต์ก็ทำให้กระบวนการของเซิร์ฟเวอร์หยุดทำงานได้

ช่องโหว่นี้ซ่อนตัวอยู่ในกลไกที่ HTTP/3 ใช้บีบอัดส่วนหัว (header) ของข้อมูล เพื่อหลีกเลี่ยงการส่งส่วนหัวเดิมซ้ำ ๆ เช่น user-agent HTTP/3 จึงใช้กลไก QPACK ที่เก็บตารางร่วมกันไว้ โดยฝั่งไคลเอนต์เป็นผู้สั่งให้เซิร์ฟเวอร์สร้างและปรับขนาดตารางผ่านช่องทางควบคุมเฉพาะที่เรียกว่า encoder stream ปัญหาคือ XQUIC เก็บข้อมูลของตารางนั้นไว้ใน ring buffer ซึ่งเป็นบล็อกหน่วยความจำขนาดคงที่ที่ข้อมูลจะวนกลับไปเริ่มต้นใหม่เมื่อเต็ม

เมื่อไคลเอนต์ร้องขอให้ขยายตาราง XQUIC จะจองบัฟเฟอร์ก้อนใหญ่ขึ้นแล้วคัดลอกข้อมูลเก่ามาไว้ ซึ่งการคัดลอกนี้มีอยู่ 4 กรณีขึ้นอยู่กับว่าข้อมูลวนรอบในบัฟเฟอร์เก่า บัฟเฟอร์ใหม่ ทั้งคู่ หรือไม่วนเลย และในกรณีหนึ่งโค้ดกลับคำนวณขนาดของข้อมูลส่วนท้ายที่เหลือโดยเทียบกับความจุของบัฟเฟอร์ใหม่ที่ใหญ่กว่า แทนที่จะเทียบกับบัฟเฟอร์เก่า ทำให้นับเกินไปมาก นาย Féry ยกตัวอย่างว่าหากขยายตารางขนาด 64 ไบต์โดยให้ตัวชี้เขียนอยู่ใกล้ปลาย แล้วปรับขนาดเป็น 65 XQUIC จะเข้าใจผิดว่ามีข้อมูลส่วนท้ายต้องย้ายถึง 70 ไบต์ ทั้งที่จริงมีเพียง 6 ไบต์

ตัวเลขที่ผิดพลาดนี้จะไหลเข้าสู่คำสั่งคัดลอกหน่วยความจำ โดยความยาวของการคัดลอกได้จากการลบค่าที่นับเกินออกจากค่าที่เล็กกว่า และเนื่องจากค่าดังกล่าวเป็นชนิด unsigned size_t จึงเกิด underflow วนกลับไปเป็นตัวเลขที่เกือบสูงสุด ส่งผลให้การคัดลอกวิ่งเลยขอบเขตของหน่วยความจำ ในบิลด์ที่บริษัท FoxIO ทดสอบบน Ubuntu 26.04 กลไก _FORTIFY_SOURCE=2 ของ glibc ตรวจพบความยาวที่ผิดปกติและสั่งปิดกระบวนการทันที แต่หากไม่มีการตรวจสอบนี้ การคัดลอกจะเขียนข้อมูลออกนอกขอบเขต ซึ่งอาจนำไปสู่ผลกระทบที่ร้ายแรงกว่าการล่มได้

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

จุดเด่นที่ทำให้ XRING อันตรายคือไม่มีค่าใดในการโจมตีเลยที่ละเมิดกฎของ QPACK โดยค่าเริ่มต้น XQUIC ประกาศเพดานตาราง dynamic ไว้ที่ 16 KiB ขณะที่เพย์โหลดของการโจมตีขอเพียง 64 ไบต์แล้วตามด้วย 65 ไบต์เท่านั้น ไคลเอนต์เพียงต้องบังคับให้ตารางเข้าสู่รูปแบบการวนรอบที่พอดีกับสาขาโค้ดที่มีข้อบกพร่อง บริษัท FoxIO ระบุว่าความผิดพลาดนี้ฝังอยู่ใน XQUIC มาตั้งแต่การเผยแพร่สู่สาธารณะครั้งแรกในเดือนมกราคม 2565 และขณะนี้มีโค้ดสาธิตการโจมตี (proof of concept) เผยแพร่ต่อสาธารณะแล้ว

XRING เป็นช่องโหว่ล่าสุดในชุดของการทำให้เซิร์ฟเวอร์ล่มจากระยะไกลบนสแตก HTTP/2 และ HTTP/3 โดยก่อนหน้านี้สามสัปดาห์ The Hacker News เคยรายงานช่องโหว่ use-after-free ในโมดูล HTTP/3 ของ NGINX (CVE-2026-42530) ที่ผู้โจมตีระยะไกลเข้าถึงได้ผ่าน encoder stream ของ QPACK เดียวกันกับที่ XRING ใช้ประโยชน์ เป็นข้อบกพร่องคนละประเภทแต่อยู่บนพื้นผิวการโจมตีเดียวกัน ก่อนหน้านั้นในเดือนมิถุนายนก็มีช่องโหว่ HTTP/2 Bomb ของ Calif ที่ทำให้ Nginx, Apache, IIS และ Envoy ปฏิเสธการให้บริการผ่านการใช้ HPACK ซึ่งเป็นการบีบอัดส่วนหัวของ HTTP/2 และในเดือนกุมภาพันธ์ HAProxy ก็เพิ่งแพตช์ช่องโหว่ QUIC สองรายการ หนึ่งในนั้นคือ integer underflow ระหว่างตรวจสอบ token ซึ่งเป็นข้อบกพร่องประเภทเดียวกับ XRING แม้จะต้องใช้แพ็กเก็ตผิดรูปในขณะที่ XRING ไม่ต้องใช้เลย

บริษัท FoxIO ระบุว่าได้สาธิตเพียงการทำให้เซิร์ฟเวอร์ล่ม ไม่ใช่การรันโค้ด และยังไม่พบการโจมตีจริงในวงกว้าง โดยบริษัทได้อีเมลแจ้ง Alibaba ตั้งแต่วันที่ 7 เมษายนผ่านนโยบายความปลอดภัยของโครงการที่ระบุว่าจะตอบกลับภายในสามวันทำการ และติดตามอีกสี่ครั้งจนถึงวันที่ 9 พฤษภาคมโดยไม่ได้รับการตอบกลับ ก่อนตัดสินใจเปิดเผยต่อสาธารณะ

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

แม้ XQUIC และ Tengine จะเป็นเทคโนโลยีที่พัฒนาโดย Alibaba แต่เนื่องจากเป็นโอเพนซอร์ส หน่วยงานและผู้ให้บริการในไทยที่นำ XQUIC ไปฝังในระบบของตนเองหรือใช้ Tengine เป็นเว็บเซิร์ฟเวอร์และเปิดบริการ HTTP/3 ด้วยค่าตั้งต้น QPACK จึงมีความเสี่ยงถูกทำให้ระบบล่มได้โดยตรง นอกจากนี้ ธุรกิจไทยจำนวนมากที่ใช้บริการคลาวด์และ CDN ในเครือ Alibaba Cloud รวมถึงร้านค้าที่พึ่งพาแพลตฟอร์มอย่าง Taobao และระบบชำระเงิน Alipay ก็อาจได้รับผลกระทบทางอ้อมหากบริการเบื้องหลังถูกโจมตี เนื่องจากมีโค้ดสาธิตการโจมตีเผยแพร่แล้วและยังไม่มีแพตช์ ผู้ดูแลระบบในไทยจึงควรประเมินการใช้งาน HTTP/3 บนไลบรารีนี้อย่างเร่งด่วน

คำแนะนำ

ผู้ดูแลระบบที่ใช้ XQUIC หรือ Tengine และเปิดบริการ HTTP/3 ควรดำเนินมาตรการบรรเทาผลกระทบทันทีระหว่างรอแพตช์ทางการ โดยตั้งค่า SETTINGS_QPACK_MAX_TABLE_CAPACITY เป็น 0 เพื่อปิดตาราง dynamic ของ QPACK ซึ่งเป็นจุดที่เกิดช่องโหว่ หรือหากไม่จำเป็นต้องใช้ HTTP/3 ก็ควรปิดการรองรับโปรโตคอลนี้ไปก่อน นอกจากนี้ควรติดตามประกาศจากโครงการ XQUIC และ Alibaba อย่างใกล้ชิดเพื่อรับแพตช์ทันทีที่ออก ตรวจสอบว่าซอฟต์แวร์หรืออุปกรณ์ของบุคคลที่สามที่ใช้งานอยู่มีการฝัง XQUIC หรือไม่ และเฝ้าระวังทราฟฟิก HTTP/3 ที่ผิดปกติซึ่งอาจเป็นความพยายามใช้ประโยชน์จากช่องโหว่นี้

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