CERT เปิดเผย CVE 6 รายการสำหรับช่องโหว่ความปลอดภัยร้ายแรงใน dnsmasq
(lists.thekelleys.org.uk)- CERT เปิดเผย ชุด CVE สำหรับ ช่องโหว่ความปลอดภัยร้ายแรง 6 รายการ ใน dnsmasq เมื่อวันที่ 11 พฤษภาคม 2026
- ช่องโหว่ทั้งหมดเป็น บั๊กเก่า และส่งผลกระทบต่อ dnsmasq แทบทุกเวอร์ชัน ยกเว้นเวอร์ชันที่เก่ามากบางรุ่น
- CVE ถูกเปิดเผยล่วงหน้าให้ผู้จำหน่ายรับทราบแล้ว และผู้จำหน่ายแต่ละรายจำเป็นต้องเผยแพร่ เวอร์ชันแพตช์ ของแพ็กเกจ dnsmasq ให้ทันเวลา
- มีการสร้าง 2.92rel2 ซึ่งเป็น dnsmasq 2.92 รุ่นเสถียรที่ใส่แพตช์แล้ว และสามารถดาวน์โหลดได้จากตำแหน่งเดิม
- คาดว่าจะมีการสร้างแท็ก dnsmasq-2.93rc1 ในเร็ว ๆ นี้ และตั้งเป้าออกรีลีส 2.93 ภายในประมาณหนึ่งสัปดาห์หลังผ่านการทดสอบ
การเปิดเผยช่องโหว่และแพตช์ของ dnsmasq
- CERT เปิดเผยชุด CVE สำหรับ ช่องโหว่ความปลอดภัยร้ายแรง 6 รายการของ dnsmasq เมื่อวันที่ 11 พฤษภาคม 2026
- ช่องโหว่ทั้งหมดเป็นบั๊กเก่า และมีผลกับ dnsmasq แทบทุกเวอร์ชัน ยกเว้นเวอร์ชันที่เก่ามากบางรุ่น
- CVE ถูกเปิดเผยล่วงหน้าให้ผู้จำหน่ายรับทราบแล้ว และผู้จำหน่ายแต่ละรายจำเป็นต้องเผยแพร่ เวอร์ชันแพตช์ ของแพ็กเกจ dnsmasq ให้ทันเวลา
- ดูรายละเอียดและแพตช์ได้ที่ https://thekelleys.org.uk/dnsmasq/CVE/
- มีการสร้าง 2.92rel2 ซึ่งเป็น dnsmasq 2.92 รุ่นเสถียรที่ใส่แพตช์แล้ว และสามารถดาวน์โหลดได้จากตำแหน่งเดิม
- จะมีการเพิ่มคอมมิตแก้ไขเข้าไปใน development tree ในช่วงเวลาเดียวกัน โดยบางส่วนใช้แพตช์เดียวกับการ backport และบางส่วนเป็นการเขียนใหม่ที่ครอบคลุมมากกว่าเพื่อจัดการกับ สาเหตุราก
การเพิ่มขึ้นของรายงานที่ขับเคลื่อนด้วย AI และแผนสำหรับ 2.93
- ในช่วงไม่กี่เดือนที่ผ่านมา รายงานบั๊กจาก งานวิจัยความปลอดภัยที่ขับเคลื่อนด้วย AI เพิ่มขึ้นอย่างมาก ทำให้ต้องใช้เวลามากกับการคัดกรองรายงานซ้ำและการจัดประเภทบั๊ก
- บั๊กถูกแบ่งเป็นรายการที่ต้องเปิดเผยล่วงหน้าให้ผู้จำหน่ายรับทราบ กับรายการที่ควรแก้ทันทีหลังเปิดเผยต่อสาธารณะ ซึ่งการแบ่งนี้ย่อมมีความเป็นอัตวิสัยอย่างหลีกเลี่ยงไม่ได้
- เนื่องจากบั๊กเดียวกันถูก “good guys” หลายกลุ่มพบซ้ำ ๆ จึงมีความเป็นไปได้ว่า “bad guys” ก็หาเจอได้เช่นกัน ทำให้มองว่า embargo ที่ยาวนาน อาจไม่ได้มีประสิทธิผลมากนัก
- การประสานงานเรื่อง embargo และการจัดเตรียม backport ต้องใช้เวลาและความพยายามอย่างมากจากผู้เกี่ยวข้องทุกฝ่าย
- บั๊กส่วนใหญ่จะถูกแก้ในรีลีสถัดไป และให้ความสำคัญกับการทำให้ dnsmasq รีลีสใหม่มีบั๊กน้อยที่สุดเท่าที่เป็นไปได้
- การที่มี คอมมิตแก้ไขด้านความปลอดภัย จำนวนมากขึ้นไปอยู่ใน git repository ในช่วงหลายสัปดาห์ก่อนการประกาศก็สอดคล้องกับแนวทางนี้
- มีแผนจะสร้างแท็ก dnsmasq-2.93rc1 ในเร็ว ๆ นี้ โดยมีเป้าหมายให้ออกเวอร์ชันเสถียร 2.93 ให้เร็วที่สุด
- การทดสอบ release candidate มีความสำคัญ จึงควรให้ผู้ที่ทำได้ช่วยทดสอบโดยเร็ว
- หากทุกอย่างเป็นไปอย่างราบรื่น 2.93 อาจออกได้ภายในประมาณหนึ่งสัปดาห์
- “tsunami” ของรายงานบั๊กที่สร้างโดย AI ยังไม่มีสัญญาณว่าจะหยุด จึงมีแนวโน้มว่ากระบวนการแบบเดียวกันนี้จะเกิดซ้ำอีกในไม่ช้า
- ใน 2.93 มีความตึงเครียดระหว่างการรวมบั๊กที่กำลังไหลเข้ามาให้ได้มากที่สุดกับการออกรุ่นให้ทันเวลา และลำดับความสำคัญคือ การออกรุ่นอย่างทันท่วงที
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ดูเหมือนว่าเรากำลังมาถึงจุดเปลี่ยนที่การย้ายโค้ดที่เขียนด้วย C ไปเป็นภาษาแบบ memory-safe กลายเป็นเรื่องเร่งด่วนแล้ว
ช่องโหว่ส่วนใหญ่ที่ถูกพบในช่วงหลังเกี่ยวข้องโดยตรงกับภาษาที่ไม่ปลอดภัยต่อหน่วยความจำ และก็ดูยากมากที่จะอธิบายว่าทำไม DNS/DHCP server ถึงเขียนด้วย Rust หรือ Go โดยไม่ใช้
unsafeไม่ได้นักวิจัยด้านความปลอดภัย AI อย่างน้อยก็ยังได้ลงมือทำอะไรบ้าง ถ้าการเขียนทุกอย่างใหม่ด้วย Rust ง่ายขนาดนั้น วันถัดจากเหตุการณ์แบบนี้ก็ควรจะมีตัวแทน Rust ที่แข็งแรงออกมาทันที
ที่ไม่เป็นแบบนั้นก็เพราะทำงานแนวนี้แล้วไม่ได้ดาวบน GitHub มากนัก
แนวคิดว่า “ไม่รู้ขนาดสูงสุดก็เลยทุกอย่างต้องเป็น dynamic” อาจไม่ถูกต้องจริงเสมอไป โปรแกรมสามารถประกาศขนาดอินพุตสูงสุดที่ยอมรับได้ และถ้าเกินก็คืน error หรือใช้ ring buffer ซึ่งก็ไม่ใช่จุดจบของโลก
ถ้ารู้ขนาด ก็ออกแบบให้สอดคล้องกับขนาดนั้นได้ RAM มีจำกัด แต่กลับแปลกที่ทุกชั้นของระบบในนั้นถูกออกแบบราวกับว่าไม่มีที่สิ้นสุด
การย้ายไป Rust ดูเหมือนเสียเวลามหาศาล และไม่ได้แก้ปัญหาพื้นฐานที่ว่าเราไม่สามารถจำลองโปรแกรมให้สอดคล้องกับข้อเท็จจริงของทรัพยากรระบบที่มีจำกัดได้ ปัญหานี้ไม่ใช่แค่เรื่องหน่วยความจำด้วย กรณีที่ Chrome ลงโมเดล 4GB บนอุปกรณ์ผู้ใช้ก็คล้ายกัน
https://xchglabs.com/blog/dnsmasq-five-cves.html
สงสัยว่า OpenWRT ออกบิลด์ใหม่หรือยัง คำตอบคือตอนนี้ยัง แต่กำลังดำเนินการอยู่
https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...
https://github.com/mirror/dd-wrt/issues/465
https://svn.dd-wrt.com/changeset/64944
https://svn.dd-wrt.com/changeset/64905
โดยระบุว่ารีลีสจะ “coming soon”
MaraDNS ของฉันได้รับการตรวจสอบค่อนข้างกว้างขวาง หลังเข้าสู่ยุคของการตรวจสอบความปลอดภัยแบบมี AI ช่วย
ตั้งแต่ปี 2023 เป็นต้นมา ยังไม่พบ security bug ร้ายแรงแม้แต่รายการเดียว [1]
สิ่งที่ผู้ตรวจสอบเจอก็มีแค่ “Deadwood ใช้เวลาคืนทรัพยากรนานกว่าปกติเมื่อได้รับ packet แปลก ๆ ในโหมด recursive เต็มรูปแบบ” [2] หรือ “utility เสริมที่มากับ MaraDNS คอมไพล์ไม่ได้มาตั้งแต่ปี 2022 แต่มี buffer overflow เฉพาะตอนที่
$HOMEยาวเกิน 50 ตัวอักษร” [3] เท่านั้นโดยส่วนตัวผมพอใจมากที่ MaraDNS ดูปลอดภัยค่อนข้างมากในตอนนี้ที่มันได้รับการตรวจสอบความปลอดภัยเชิงลึกจริง ๆ
[1] https://samboy.github.io/MaraDNS/webpage/security.html
[2] https://github.com/samboy/MaraDNS/discussions/136
[3] https://github.com/samboy/MaraDNS/pull/137
Lua เองก็ไม่ใช่ว่าไม่เคยมี security fix
ฉันเองก็มีไลบรารีที่เขียนเองอยู่ไม่กี่ตัว และตั้งแต่ปี 1991 ก็ไม่เคยพบ security bug ร้ายแรงเลยสักตัว แน่นอนว่าไม่มีใครใช้ไลบรารีของฉัน
ไม่ได้จะลดทอนความสำเร็จนี้ แต่การอ้างแบบนี้ควรถูกใส่บริบทเรื่องฐานผู้ใช้ประกอบด้วย
การโปรโมตนี้แทบไม่มีคุณค่าต่อการคุยเรื่อง dnsmasq เลย
ซอฟต์แวร์ที่มีคนใช้มากกว่าจะถูกตรวจสอบมากกว่า และจะพบทั้งบั๊กกับกรณีขอบเขตมากกว่า
โชคดีนะที่ซอฟต์แวร์นี้คงไม่ได้ถูกรันอยู่บน อุปกรณ์หลายล้านเครื่อง ที่แทบไม่ได้รับอัปเดตเลย
ค่อนข้างร้ายแรงทีเดียว
“ผู้โจมตีระยะไกลที่สามารถทำ DNS query หรือส่ง DNS response ได้ อาจทำให้เกิด out-of-bounds write ขนาดใหญ่บน heap ได้”
DNS response ที่ผิดพลาดสามารถ “ทำให้เกิด infinite loop จน dnsmasq ไม่ตอบ query ใด ๆ เลย”
DHCP request ที่เป็นอันตรายสามารถทำให้เกิด buffer overflow ได้
ไม่ใช่ทุกโปรเจกต์ที่จะเจอ คลื่นสึนามิของ AI bug report อย่างที่พูดถึงข้างบน MaraDNS ไม่มีแบบนั้น
คิดว่า djbdns กับ tinydns ก็คงไม่มีเหมือนกัน ถ้ามีคงประกาศกันใหญ่โตไปแล้ว
ฉันไม่เคยเข้าใจเลยว่าทำไมบางโปรเจกต์ถึงได้รับความนิยมมหาศาล ในขณะที่บางโปรเจกต์ไม่เป็นแบบนั้น
ดูเหมือนว่าเครื่องมือประเภท “อันตรายเกินกว่าจะเปิดเผย” กำลังสแกนทุกโปรเจกต์ แต่จะติดต่อเฉพาะโครงการที่มีปัญหาเท่านั้น แบบนั้นก็ไม่ต้องยอมรับว่าเครื่องมือของตัวเองหาอะไรไม่เจอ
ฉันไม่เคยชอบการใช้ dnsmasq เลย รู้สึกว่ามันยัดหลายอย่างเกินไปไว้ในเครื่องมือเดียว
ปกติฉันชอบแยกตั้งค่า local caching resolver, DHCP server และการตั้งค่า TFTP/PXE boot ออกจากกันเสมอ
เช่น การส่ง query ของ
*.example.comไปยัง upstream server เฉพาะ, การคืนค่า NXDOMAIN ให้เว็บฟิชชิง, หรือการเพิ่มทุก IP ที่ resolve ได้จาก*.example.orgเข้าipsetเพื่อใช้กับ policy routingฟีเจอร์สุดท้ายนั้นทำงานบน FreeBSD ได้แม้ BSD จะไม่มี
ipsetและรายการ*.example_xyz.comก็อาจมีขนาดใหญ่มาก ซึ่ง dnsmasq รุ่นใหม่ ๆ ว่ากันว่าจัดการได้อย่างมีประสิทธิภาพให้ 10 เต็ม 10 ไม่เสียใจ และแนะนำได้
อย่างเช่น Opnsense ใช้เฉพาะส่วน DHCP ของ dnsmasq แต่ใช้ unbound สำหรับ DNS ซึ่งมันให้ความรู้สึก “แปลก ๆ” อยู่บ้าง
DHCP กับ DNS เชื่อมโยงกัน และ PXE ก็ต้องใช้รายการใน DHCP ถ้าจะตั้งค่าอะไรให้ง่าย ไม่อย่างนั้นก็ต้องเอา daemon อย่างน้อย 3 ตัวที่มี syntax config ไม่เหมือนกันมาต่อเข้าด้วยกัน
ขอถามแบบมือใหม่กับคนที่มีประสบการณ์ในด้านนี้มากกว่า ว่าทำไมซอฟต์แวร์ในพื้นที่นี้ถึงไม่ได้เขียนด้วย runtime ของภาษาอย่าง Erlang ที่มี garbage collection และ concurrency กันมากกว่านี้
overhead ด้านประสิทธิภาพสูงเกินไป, มี runtime ที่ไม่โปร่งใสซึ่งยากจะรู้ว่าเสถียรแค่ไหนในเวลานั้น, มีผู้ร่วมพัฒนาน้อย, และมี footprint ของ dependency ที่ใหญ่เพราะไม่ได้ติดตั้งอยู่บนระบบส่วนใหญ่
แม้กระทั่งตอนที่ฉันใช้ Erlang กับ production system ราวปี 2015 ถ้าออกนอก use case ที่มันตั้งใจไว้เดิมนิดหน่อย ก็ยังมีมุมที่หยาบอยู่ เรื่องนี้ไม่ใช่คำวิจารณ์ที่มีต่อ Erlang อย่างเดียว หลายภาษาและหลาย runtime ก็คล้ายกัน
ระบบจำนวนมากที่กำลังจะโดนผลกระทบต่อเนื่องอีกหลายสัปดาห์หรือหลายเดือนข้างหน้าก็มีพื้นหลังแบบเดียวกัน Linux kernel เอง ตัวเลือกทางเลือกที่พอเป็นไปได้ในยุคนั้นก็คงมีแค่ C++ ส่วน OpenSSL ซึ่งเป็นขาประจำของปัญหาความปลอดภัยก็เริ่มมาตั้งแต่ปี 1998
ฉันเห็นด้วยอย่างมากกับคำพูดที่ว่า “อย่าเขียนโปรเจกต์ใหม่ที่เปิดให้เข้าถึงผ่านเครือข่ายด้วย C” แต่ถ้าย้อนกลับไปปี 1998 ก็ยากจะบอกว่ามีทางเลือกอื่นใดที่ใช้ได้จริง
มีภาษาที่ปลอดภัยกว่าก็จริง แต่ชุมชนเล็กกว่าชุมชน C มาก และก็ยากจะมั่นใจเรื่องเสถียรภาพได้ Java มีออกมาแล้ว แต่ฉันไม่แน่ใจว่ามันกลายเป็นตัวเลือกจริงจังสำหรับ network server ตั้งแต่เมื่อไร คาดว่าน่าจะช่วงปลายยุค 2000 ประมาณนั้น Java ที่ฉันเห็นในปี 1999 ยังไม่ใช่แบบนั้น
ยกตัวอย่างเช่น ในปี 2011 ฉันเคยรัน Haskell network server สำหรับงานที่ไม่สำคัญมากนัก และมันก็ล้มภายใต้เงื่อนไขที่ไม่น่าจะโหดเกินไปสำหรับ production network จากนั้นในปี 2013 ฉันเอา codebase เดิมกลับมาใช้ซ้ำโดยแทบไม่ต้องเปลี่ยน core execution loop แล้วผลดีขึ้นราว 90% ดังนั้นฉันเลยคิดว่าปัญหาอยู่ที่ Haskell มากกว่าโค้ดของฉัน
ถึงอย่างนั้นมันก็ยังไม่ถึงขั้นที่ฉันจะเอาเข้า production จริงได้ แต่ก็อย่างน้อยพิสูจน์ว่าไม่ใช่โค้ดของฉันที่พัง ซึ่งหมายความว่าแม้ Haskell จะมีอยู่แล้วในยุค 2000s มันก็ยังยากจะมองว่าเป็นตัวเลือกที่ใช้ได้จริงสำหรับ network server ในเวลานั้น
ตอนนี้เรามีตัวเลือกมากกว่าเมื่อก่อนมาก
structเข้ากับ network packet ได้ตรง ๆ เลย จึงค่อนข้างง่ายในภาษาอื่น ๆ หลายครั้งมันไม่ง่ายแบบนั้น
แน่นอนว่ามันยังช้ากว่าและตัวใหญ่กว่าด้วย