"league/commonmark ตารางทำ DoS: GHSA-3q6v-r5mr-hxv8"
"เว็บที่รับ Markdown จากภายนอกและเปิด Table extension ควรเร่งอัปเดต league/commonmark เป็น 2.10.2"
สรุปใน 1 นาที
- อาการ/ปัญหา
- การตรวจจุดเริ่มต้นตารางสแกนย่อหน้าเดิมซ้ำ ทำให้ใช้ CPU เพิ่มแบบกำลังสองและอาจทำให้บริการหยุดตอบสนอง
- ใครควรอ่าน
- แอปที่ใช้ league/commonmark รุ่น 2.0.0–2.10.1 พร้อม GithubFlavoredMarkdownConverter หรือเปิด TableExtension กับข้อมูลที่ไม่น่าเชื่อถือ
- ทางแก้แบบสั้น
- อัปเดตเป็น 2.10.2 ระหว่างรอให้จำกัดขนาด Markdown หรือปิด Table extension สำหรับข้อมูลจากภายนอก
พอดีไล่ฟีด Packagist เจอประกาศของ league/commonmark ไลบรารีแปลง Markdown ใน PHP ที่มีช่องโหว่ในส่วนขยายตาราง GitHub Flavored Markdown ประเด็นคือข้อความที่ส่งมาแปลงอาจกิน CPU มากผิดสัดส่วน จนเว็บไม่พร้อมให้บริการ ประกาศ GHSA-3q6v-r5mr-hxv8 อยู่ในระดับ High คะแนน CVSS 3.1 เท่ากับ 7.5 และยังไม่มีหมายเลข CVE ระบุไว้
เกิดอะไรขึ้น
เมื่อรับบรรทัดใหม่ TableStartParser::tryStart() จะอ่านทั้งย่อหน้าซ้ำเพื่อหาเครื่องหมาย pipe ยิ่งย่อหน้ายาวก็ยิ่งทำงานซ้ำมาก งานรวมเลยโตแบบกำลังสอง หรือ O(n²) แม้ข้อความนั้นจะไม่ใช่ตารางก็ตาม commit แก้ไข อธิบายว่ามีเพียงบรรทัดสุดท้ายของย่อหน้าที่เป็นหัวตารางได้ แพตช์เลยจำกัดการตรวจเบื้องต้นไว้ที่บรรทัดนั้น แทนการค้นหาทั้งย่อหน้า
ผลกระทบตามประกาศคือผู้โจมตีจากเครือข่ายที่ไม่ต้องยืนยันตัวตน สามารถส่ง Markdown ที่จัดรูปแบบมาเฉพาะให้ใช้ CPU จน PHP worker ไม่ว่างรับงานอื่นได้ ความเสียหายอยู่ที่ความพร้อมใช้งาน ประกาศไม่ได้ระบุผลกระทบต่อความลับหรือความถูกต้องของข้อมูล เงื่อนไขสำคัญคือแอปต้องแปลงข้อมูลที่ไม่น่าเชื่อถือและเปิดส่วนขยายตาราง แค่มีแพ็กเกจอยู่ในโครงการยังบอกไม่ได้ว่าเสี่ยง ต้องดูว่าแอปเรียกใช้ส่วนนี้กับข้อมูลจากใคร
ใครโดนและรุ่นที่แก้
กลุ่มที่ต้องตรวจคือเว็บที่ใช้ GithubFlavoredMarkdownConverter ซึ่งเปิดตารางในชุด GFM หรือกำหนด TableExtension เอง แล้วรับข้อความจากผู้ใช้มาประมวลผล ช่วงรุ่นและรุ่นแก้ไขในประกาศต้นทาง เป็นดังนี้
| แพ็กเกจ / การใช้งาน | รุ่นที่ได้รับผลกระทบ | รุ่นที่แก้ |
|---|---|---|
| league/commonmark พร้อม Table extension | ตั้งแต่ 2.0.0 ถึง 2.10.1 | 2.10.2 |
เนื้อหารายงานเดิมในหน้าประกาศยังเขียนว่าไม่มีแพตช์ แต่ช่อง Patched versions ระบุ 2.10.2 และ release 2.10.2 ยืนยันว่าแก้การแปลงย่อหน้ายาวที่ใช้เวลาแบบกำลังสองเมื่อเปิด Table extension แล้ว ให้ยึดข้อมูลแพตช์ที่ยืนยันตรงกันนี้ในการวางแผนอัปเดต
ต้องทำอะไร
เริ่มจากตรวจรุ่นที่ติดตั้งและการตั้งค่า converter ในโครงการ สำรอง composer.json กับ composer.lock แล้วทดลองอัปเดตในสภาพแวดล้อมทดสอบก่อน คำสั่งตัวอย่างนี้กำหนดรุ่นเป้าหมายไว้ที่รุ่นแก้ไขของประกาศ และเปิดให้ Composer ขยับ dependency ที่เกี่ยวข้องได้ตามข้อกำหนดเดิม
composer show league/commonmark
composer update league/commonmark:2.10.2 --with-all-dependencies
composer show league/commonmark
composer audit
ตามคู่มือ Composer การอัปเดตแบบระบุแพ็กเกจและรุ่นชั่วคราวยังต้องอยู่ภายใต้ constraint ใน composer.json ถ้าคำสั่งติดข้อจำกัด ให้ตรวจแพ็กเกจที่บังคับรุ่นก่อนเปลี่ยน dependency และตรวจ diff ของ lock file หลังอัปเดตด้วย เมื่อผ่านการทดสอบแล้วค่อยนำ lock file ชุดที่ตรวจแล้วเข้าสู่ขั้นตอน deploy ของโครงการ
ควรทดสอบทั้งย่อหน้าปกติและตารางที่แอปใช้งานจริง เพราะ release เดียวกันปรับการตรวจตารางให้ตรงกับข้อกำหนด GFM ด้วย เช่น จำนวนเซลล์หัวตารางต้องเท่ากับแถวคั่น การตรวจผลลัพธ์ HTML หลังอัปเดตช่วยให้เห็นความเปลี่ยนแปลงด้านการแสดงผลก่อนเปิดใช้งาน
ประกาศเสนอให้จำกัดขนาด Markdown ที่รับมาแปลง หรือปิด Table extension สำหรับข้อมูลที่ไม่น่าเชื่อถือ เป็นการลดความเสี่ยงชั่วคราวและยังไม่แก้สาเหตุในโค้ด
ส่วนตัวผมแนะนำให้เร่งแพตช์เว็บที่เปิดรับ Markdown จากภายนอกและใช้ตาราง เพราะเป็นเส้นทางที่กระทบความพร้อมให้บริการได้โดยตรง ที่มา: GitHub Security Advisory GHSA-3q6v-r5mr-hxv8 หากมีรายละเอียดจากผู้ดูแลเพิ่มเติม เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai
ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย