Exim ระส่ำอีกครั้ง: ช่องโหว่ SQL Injection ลุกลามสู่ Heap Overflow ระดับวิกฤต

ช่องโหว่ใหม่ที่ถูกเปิดเผยใน Exim 4.99 ทำให้โลกความปลอดภัยไซเบอร์ต้องจับตาอย่างใกล้ชิด เมื่อ Andrew Fasano จาก NIST ระบุว่าการอุดช่องโหว่เดิม (CVE-2025-26794) นั้น “ปิดไม่สนิท” จนกลายเป็นประตูบานใหญ่ให้แฮ็กเกอร์สามารถโจมตีลึกกว่าเดิมได้ ช่องโหว่นี้เริ่มจากการฉีดคำสั่ง SQL ผ่านฟิลด์ที่ควรจะถูก sanitize แต่กลับถูกละเลยในฟังก์ชัน xtextencode() ส่งผลให้ฐานข้อมูล SQLite ภายใน Exim ถูกควบคุมได้จากภายนอกอย่างไม่ตั้งใจ

ความร้ายแรงไม่ได้หยุดแค่ SQL Injection เพราะ Fasano พบว่าช่องโหว่นี้สามารถเชื่อมโยงไปสู่ Heap Buffer Overflow ผ่านฟิลด์ bloom_size ที่ระบบอ่านโดยไม่ตรวจสอบความถูกต้อง เมื่อผู้โจมตีใส่ค่าขนาดผิดปกติ ระบบจะเขียนข้อมูลเกินขอบเขตหน่วยความจำ ทำให้เกิด memory corruption สูงสุดกว่า 1.5MB ซึ่งอาจนำไปสู่การยึดเครื่องได้ แม้ ASLR จะช่วยลดโอกาส RCE แต่ Fasano ยืนยันว่า “มีความเป็นไปได้” หากมีการพัฒนา exploit ต่อเนื่อง

การโจมตีนี้เกิดขึ้นได้เฉพาะในสภาพแวดล้อมที่ Exim ถูกคอมไพล์ด้วย USE_SQLITE=yes และใช้ ratelimit ACL ที่อิงข้อมูลจากผู้โจมตี เช่น sender_address ซึ่งเป็นการตั้งค่าที่พบได้ในองค์กรจำนวนไม่น้อย โดยเฉพาะระบบอีเมลที่ปรับแต่งเองหรือใช้ config เก่าไม่เคย audit ความปลอดภัย นอกจากนี้ เทรนด์การโจมตี MTA ยังเพิ่มขึ้นต่อเนื่องในปี 2025 จากกลุ่ม APT ที่มองหา entry point ราคาถูกแต่ทรงพลัง เช่นเดียวกับกรณี Postfix และ Sendmail ที่เพิ่งถูกตรวจพบช่องโหว่คล้ายกันในช่วงไตรมาสที่ผ่านมา

ผู้เชี่ยวชาญแนะนำให้ผู้ดูแลระบบอัปเดต Exim ทันที พร้อมตรวจสอบ config ที่ใช้ SQLite และ ratelimit ACL อย่างละเอียด รวมถึงพิจารณาเปลี่ยนไปใช้ parameterized queries เพื่อลดความเสี่ยง SQL Injection แบบถาวร นี่เป็นอีกหนึ่งสัญญาณว่าระบบอีเมลแบบ self-hosted ยังคงเป็นจุดอ่อนสำคัญขององค์กร หากไม่มีการดูแลเชิงรุกและตรวจสอบความปลอดภัยอย่างสม่ำเสมอ

สรุปประเด็นสำคัญ
ช่องโหว่ SQL Injection ใน Exim 4.99
เกิดจากการ sanitize ข้อมูลไม่สมบูรณ์ในฟังก์ชัน xtextencode()
สามารถฉีดคำสั่ง SQL ผ่าน sender_address ได้

ช่องโหว่ลุกลามสู่ Heap Buffer Overflow
bloom_size ถูกอ่านโดยไม่มีการตรวจสอบ
memory overflow สูงสุดกว่า 1.5MB

เงื่อนไขที่ทำให้ระบบเสี่ยง
Exim ถูกคอมไพล์ด้วย USE_SQLITE=yes
ใช้ ratelimit ACL ที่อิงข้อมูลจากผู้โจมตี

ความเสี่ยงระดับองค์กร
อาจนำไปสู่ Remote Code Execution หาก exploit พัฒนาเพิ่ม
ระบบอีเมล self-hosted ที่ไม่ได้อัปเดตมีความเสี่ยงสูงมาก

คำแนะนำเร่งด่วน
อัปเดต Exim ทันที
ตรวจสอบ config ที่ใช้ SQLite และ ratelimit ACL

https://securityonline.info/exims-poisoned-record-how-a-failed-patch-and-sql-injection-lead-to-critical-heap-overflows/
🛡️ Exim ระส่ำอีกครั้ง: ช่องโหว่ SQL Injection ลุกลามสู่ Heap Overflow ระดับวิกฤต ช่องโหว่ใหม่ที่ถูกเปิดเผยใน Exim 4.99 ทำให้โลกความปลอดภัยไซเบอร์ต้องจับตาอย่างใกล้ชิด เมื่อ Andrew Fasano จาก NIST ระบุว่าการอุดช่องโหว่เดิม (CVE-2025-26794) นั้น “ปิดไม่สนิท” จนกลายเป็นประตูบานใหญ่ให้แฮ็กเกอร์สามารถโจมตีลึกกว่าเดิมได้ ช่องโหว่นี้เริ่มจากการฉีดคำสั่ง SQL ผ่านฟิลด์ที่ควรจะถูก sanitize แต่กลับถูกละเลยในฟังก์ชัน xtextencode() ส่งผลให้ฐานข้อมูล SQLite ภายใน Exim ถูกควบคุมได้จากภายนอกอย่างไม่ตั้งใจ ความร้ายแรงไม่ได้หยุดแค่ SQL Injection เพราะ Fasano พบว่าช่องโหว่นี้สามารถเชื่อมโยงไปสู่ Heap Buffer Overflow ผ่านฟิลด์ bloom_size ที่ระบบอ่านโดยไม่ตรวจสอบความถูกต้อง เมื่อผู้โจมตีใส่ค่าขนาดผิดปกติ ระบบจะเขียนข้อมูลเกินขอบเขตหน่วยความจำ ทำให้เกิด memory corruption สูงสุดกว่า 1.5MB ซึ่งอาจนำไปสู่การยึดเครื่องได้ แม้ ASLR จะช่วยลดโอกาส RCE แต่ Fasano ยืนยันว่า “มีความเป็นไปได้” หากมีการพัฒนา exploit ต่อเนื่อง การโจมตีนี้เกิดขึ้นได้เฉพาะในสภาพแวดล้อมที่ Exim ถูกคอมไพล์ด้วย USE_SQLITE=yes และใช้ ratelimit ACL ที่อิงข้อมูลจากผู้โจมตี เช่น sender_address ซึ่งเป็นการตั้งค่าที่พบได้ในองค์กรจำนวนไม่น้อย โดยเฉพาะระบบอีเมลที่ปรับแต่งเองหรือใช้ config เก่าไม่เคย audit ความปลอดภัย นอกจากนี้ เทรนด์การโจมตี MTA ยังเพิ่มขึ้นต่อเนื่องในปี 2025 จากกลุ่ม APT ที่มองหา entry point ราคาถูกแต่ทรงพลัง เช่นเดียวกับกรณี Postfix และ Sendmail ที่เพิ่งถูกตรวจพบช่องโหว่คล้ายกันในช่วงไตรมาสที่ผ่านมา ผู้เชี่ยวชาญแนะนำให้ผู้ดูแลระบบอัปเดต Exim ทันที พร้อมตรวจสอบ config ที่ใช้ SQLite และ ratelimit ACL อย่างละเอียด รวมถึงพิจารณาเปลี่ยนไปใช้ parameterized queries เพื่อลดความเสี่ยง SQL Injection แบบถาวร นี่เป็นอีกหนึ่งสัญญาณว่าระบบอีเมลแบบ self-hosted ยังคงเป็นจุดอ่อนสำคัญขององค์กร หากไม่มีการดูแลเชิงรุกและตรวจสอบความปลอดภัยอย่างสม่ำเสมอ 📌 สรุปประเด็นสำคัญ ✅ ช่องโหว่ SQL Injection ใน Exim 4.99 ➡️ เกิดจากการ sanitize ข้อมูลไม่สมบูรณ์ในฟังก์ชัน xtextencode() ➡️ สามารถฉีดคำสั่ง SQL ผ่าน sender_address ได้ ✅ ช่องโหว่ลุกลามสู่ Heap Buffer Overflow ➡️ bloom_size ถูกอ่านโดยไม่มีการตรวจสอบ ➡️ memory overflow สูงสุดกว่า 1.5MB ✅ เงื่อนไขที่ทำให้ระบบเสี่ยง ➡️ Exim ถูกคอมไพล์ด้วย USE_SQLITE=yes ➡️ ใช้ ratelimit ACL ที่อิงข้อมูลจากผู้โจมตี ‼️ ความเสี่ยงระดับองค์กร ⛔ อาจนำไปสู่ Remote Code Execution หาก exploit พัฒนาเพิ่ม ⛔ ระบบอีเมล self-hosted ที่ไม่ได้อัปเดตมีความเสี่ยงสูงมาก ‼️ คำแนะนำเร่งด่วน ⛔ อัปเดต Exim ทันที ⛔ ตรวจสอบ config ที่ใช้ SQLite และ ratelimit ACL https://securityonline.info/exims-poisoned-record-how-a-failed-patch-and-sql-injection-lead-to-critical-heap-overflows/
SECURITYONLINE.INFO
Exim’s Poisoned Record: How a Failed Patch and SQL Injection Lead to Critical Heap Overflows
NIST warns of a critical Exim 4.99 flaw. A failed SQLi patch allows attackers to poison SQLite records and trigger a 1.5MB heap buffer overflow.
0 ความคิดเห็น 0 การแบ่งปัน 35 มุมมอง 0 รีวิว