Ubuntu Unbound CVE-2026-81634 และอีก 7 ช่องโหว่ เร่งเช็กแพตช์ DNS
ผู้ดูแล Ubuntu ที่ใช้ Unbound ควรตรวจรุ่นแพ็กเกจและฟีเจอร์ที่เปิด แล้วเร่งอัปเดต resolver ที่รับคำถามจากภายนอก
สรุปใน 1 นาที
- อาการ/ปัญหา
- คำถามหรือคำตอบ DNS ที่ผู้โจมตีเตรียมมาอาจทำให้ resolver ล่ม ใช้ทรัพยากรมาก หรือเก็บคำตอบผิดลง cache
- ใครควรอ่าน
- ผู้ใช้ Unbound รุ่นที่มีช่องโหว่ โดยบางรายการต้องเปิด DNSCrypt, DNS-over-QUIC หรือ dns-error-reporting ก่อน
- ทางแก้แบบสั้น
- ใช้แพตช์ของ Ubuntu ให้ตรงรุ่น อัปเดตแพ็กเกจที่ติดตั้ง รีสตาร์ตบริการ และทดสอบ DNS โดยยังต้องตรวจเลขแพ็กเกจที่แก้สำหรับ Ubuntu 26.10
พอดีผมไล่ประกาศ Unbound ของ Ubuntu แล้วเห็นว่า USN-8946-1 ลงวันที่ 21 ต.ค. 2026 ส่วน หน้า CVE-2026-81634 มีลิงก์ USN-8946-2 ลงวันที่ 10 พ.ย. 2026 แต่ผมเปิดตัวประกาศฉบับหลังไม่สำเร็จ เลยยังสรุปขอบเขตแพตช์ของฉบับนั้นไม่ได้ ผมเลือกช่องโหว่ที่เกี่ยวกับงาน DNS resolver มาให้ตรวจ 8 รายการ ช่องโหว่เหล่านี้มีประกาศ upstream แล้ว และแต่ละตัวมีเงื่อนไขต่างกัน
เกิดอะไรขึ้นกับ Unbound
Unbound ส่งคำถาม DNS ต่อ เก็บคำตอบใน cache และตรวจ DNSSEC บางช่องโหว่เกิดจากคำตอบของ authoritative server ที่ผู้โจมตีควบคุม แม้ resolver จะไม่เปิดรับคำถามสาธารณะก็ยังมีความเสี่ยง ถ้า resolver ล่ม เว็บ แอป และระบบเมลที่ใช้ resolver ตัวนั้นอาจแปลงชื่อไม่ได้ตามไปด้วย
ตัวหลัก CVE-2026-81634 อยู่ในขั้นจัดรูป RRSet ก่อนตรวจ DNSSEC โค้ดคำนวณขนาด buffer โดยไม่นับชื่อเจ้าของ record แรก ถ้าชื่อที่ถามยาว 255 และได้คำตอบ TCP ขนาดใหญ่ ก็อาจเขียนเกิน heap buffer ได้ ผู้โจมตีต้องควบคุม nameserver ที่ส่งคำตอบ หรือแก้ไขคำตอบระหว่างทางได้ การเปิด DNSSEC เลยไม่ป้องกันช่องโหว่นี้ เพราะปัญหาเกิดก่อนตรวจลายเซ็น ตาม ประกาศ NLnet Labs
คะแนนความรุนแรงต้องอ่านพร้อมชื่อแหล่ง
สำหรับ CVE-2026-81634 Amazon Linux ให้ระดับ Important และ CVSS 3.1 8.6 เวกเตอร์ CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H ขณะที่ หน้า CVE ของ Ubuntu แสดง 7.5 High พร้อมเวกเตอร์ CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H และจัด Ubuntu priority เป็น Medium สองแหล่งให้ค่าผลกระทบต่อความลับและความถูกต้องของข้อมูลต่างกัน เลยไม่ควรเรียก 8.6 ว่าคะแนนของ Ubuntu หรือใช้เป็นคะแนนของทุก CVE ในชุด
หน้า Ubuntu เขียนว่า CVSS v3.0 แต่เวกเตอร์ขึ้นต้นด้วย 3.1 ผมคงข้อความตามต้นทาง ส่วน CVE record ของ NLnet Labs ให้ CVSS 3.1 ที่ 7.5 และเวกเตอร์เดียวกับ Ubuntu คะแนนนี้ประเมินว่าผู้โจมตีผ่านเครือข่ายอาจทำให้บริการใช้งานไม่ได้ โดยไม่ต้องมีบัญชีหรือรอให้ผู้ใช้กดอะไร
NLnet Labs จัด CVE-2026-81634 เป็น High และระบุผลกระทบเป็น DoS แต่ Red Hat ระบุใน Statement ว่าอาจทำให้รันโค้ดตามที่ผู้โจมตีต้องการได้ด้วย ทั้งสองแหล่งอธิบายผลกระทบต่างกัน ข้อความเรื่องความเป็นไปได้นี้ไม่ใช่รายงานว่ามีการโจมตีจริง
ประกาศ NLnet Labs ของทั้ง 8 รายการไม่ได้ระบุว่าพบการโจมตีจริง ทั้ง 8 รายการยังไม่อยู่ใน KEV ฉบับ 9 พ.ย. 2026 (catalogVersion: 2026.11.09) เลยไม่มีวันเพิ่มรายการหรือเส้นตาย KEV ของรายการเหล่านี้ให้อ้าง การไม่อยู่ใน KEV ไม่ได้แปลว่าไม่เคยมีใครโจมตี
รุ่นที่กระทบและเงื่อนไขที่ต้องตรวจ
ตารางนี้ใช้ช่วงรุ่น upstream จากประกาศ NLnet Labs ส่วนแพ็กเกจ Ubuntu อาจนำแพตช์กลับมาใส่ในรุ่นเก่าแล้ว ต้องเทียบเลขแพ็กเกจให้ครบถึง revision
| CVE | upstream ที่กระทบ | แก้ใน | กลไกและเงื่อนไข |
|---|---|---|---|
| CVE-2026-32665 | 1.22.0–1.25.1 | 1.25.2 | DoQ จองหน่วยความจำเกินงบ ต้องคอมไพล์ด้วย --with-libngtcp2 และตั้ง quic-port ให้รับการเชื่อมต่อ |
| CVE-2026-40691 | 1.9.0–1.25.1 | 1.25.2 | DNSCrypt ผ่าน TCP ทำให้บัฟเฟอร์ผิดขอบเขตและล่ม ต้องคอมไพล์ด้วย --enable-dnscrypt และเปิดส่วน dnscrypt: บน listener |
| CVE-2026-44690 | 1.7.0–1.25.1 | 1.25.2 | cache poisoning ไปยังโซนที่มี parent เดียวกันและ parent ลงนามด้วย NSEC ผ่าน wildcard และ RRSIG เมื่อใช้ aggressive-nsec |
| CVE-2026-50252 | 1.4.22–1.25.1 | 1.25.2 | ผู้โจมตีจับคู่พอร์ตกับ worker เพื่อลดจำนวนพอร์ตที่ต้องเดาและช่วยโจมตี cache poisoning เมื่อใช้ so-reuseport: yes ซึ่งเป็นค่าเริ่มต้น |
| CVE-2026-55973 | 1.23.0–1.25.1 | 1.25.2 | stack buffer overflow จาก EDNS Report-Channel ต้องตั้ง dns-error-reporting: yes |
| CVE-2026-80225 | ถึง 1.26.0 | 1.26.1 | ส่งคำถามชื่อที่ยังไม่มีใน cache ต่อเนื่องผ่าน TCP/DoT จน worker ไม่มีเวลาทำงานอื่น ทำให้บริการช้าลง |
| CVE-2026-81634 | ถึง 1.26.0 | 1.26.1 | heap buffer overflow ระหว่างจัดรูป RRSet ก่อนตรวจ DNSSEC |
| CVE-2026-85501 | ถึง 1.26.0 | 1.26.1 | ReTrap ทำให้ขั้นตรวจ DNSSEC ใช้ทรัพยากรมากจากข้อมูลของโซนอันตราย |
รายละเอียดเงื่อนไขตรวจได้จากประกาศ 32665, 40691, 44690, 50252, 55973, 80225 และ 85501
Ubuntu USN-8946-1 สรุปว่าการจัดการพอร์ตขาออกอาจทำให้ Unbound ล่ม แต่ประกาศ NLnet Labs อธิบายการลดความสุ่มของพอร์ตต่อ worker ซึ่งช่วยโจมตี cache poisoning ผมเก็บคำอธิบายทั้งสองแหล่งไว้ให้ตรวจเทียบ ไม่สรุปว่าผลกระทบมีแค่บริการล่ม
สำหรับแพ็กเกจ Ubuntu USN-8946-1 ระบุรุ่นที่แก้ของทั้ง unbound และ libunbound8 ไว้ดังนี้: 26.04 LTS ใช้ 1.24.2-1ubuntu2.4, 24.04 LTS ใช้ 1.19.2-1ubuntu3.12 และ 22.04 LTS ใช้ 1.13.1-1ubuntu5.17
ส่วน หน้า Ubuntu CVE-2026-81634 ที่เปิดอ่านยังระบุ Ubuntu 26.10 ว่า Vulnerable แม้มีลิงก์ USN-8946-2 ลงวันที่ 10 พ.ย. 2026 อยู่ด้วย ตัวประกาศ USN-8946-2 เปิดไม่สำเร็จระหว่างตรวจทาน เลยยังไม่มีเลขแพ็กเกจที่แก้ของ 26.10 ให้อ้างในบทความนี้ อย่าใช้เลขแพ็กเกจของ LTS ตัดสินว่า 26.10 แก้แล้ว
อัปเดตอย่างไรให้ตรวจสอบผลได้
ดูรุ่นระบบ แพ็กเกจที่ติดตั้ง และ candidate ในคลัง แล้วเทียบประกาศ Ubuntu รุ่นนั้น หากไม่พบ libunbound8 ให้ตรวจเฉพาะแพ็กเกจที่ติดตั้งอยู่
cat /etc/os-release
dpkg-query -W -f='${binary:Package}\t${Version}\n' unbound libunbound8
apt-cache policy unbound libunbound8
ดูข้อมูล build ด้วย unbound -V แล้วอ่านค่าจาก config ด้วย unbound-checkconf -o ตาม คู่มือผู้พัฒนา ถ้า service ใช้ config คนละไฟล์กับค่าเริ่มต้น ให้ใส่ path ของไฟล์นั้นต่อท้าย option ถ้าคำสั่งแจ้งว่าไม่รู้จัก option อย่าอ่านผลนั้นว่าเป็นการปิดฟีเจอร์
unbound -V
sudo unbound-checkconf -o dnscrypt-enable
sudo unbound-checkconf -o quic-port
sudo unbound-checkconf -o dns-error-reporting
sudo unbound-checkconf -o aggressive-nsec
sudo unbound-checkconf -o so-reuseport
- ตรวจขอบเขต จดรุ่น Ubuntu รุ่นแพ็กเกจ และฟีเจอร์ที่เปิด สำรอง config ก่อนเปลี่ยน
- เทียบประกาศ ยืนยันรุ่นที่แก้ของ Ubuntu สายนั้น รวมแพ็กเกจไลบรารีที่ติดตั้งอยู่
- อัปเดต รับแพตช์จากคลัง Ubuntu ที่ใช้งาน แล้วตรวจ config
- เริ่มบริการใหม่ รีสตาร์ตและทดสอบการแปลงชื่อจากเครื่องที่ใช้ resolver จริง
เมื่อเทียบรุ่นแพ็กเกจที่แก้แล้ว ให้อัปเดตผ่าน APT ตัวอย่างนี้ใช้กับเครื่องที่ติดตั้งทั้ง unbound และ libunbound8 ถ้ามีแอปโหลดไลบรารีนี้อยู่ ให้เริ่ม process ของแอปใหม่ตามรอบงานด้วย
sudo apt update
sudo apt install --only-upgrade unbound libunbound8
sudo unbound-checkconf && sudo systemctl restart unbound
การไม่เปิด DNSCrypt, DoQ หรือ dns-error-reporting ช่วยตัดเงื่อนไขของรายการที่พึ่งฟีเจอร์นั้น แต่ไม่ได้แก้ 81634 หรือช่องโหว่ทุกตัวในชุด ประกาศ upstream ให้ทางแก้เป็นรุ่นที่มีแพตช์หรือการลงแพตช์ source อย่าใช้การปิดฟีเจอร์บางตัวแทนการอัปเดตทั้งหมด
เช็กอาการหลังอัปเดตและหลักฐานที่ควรเก็บ
ดูสถานะและ log หลังเริ่มใหม่ แล้วทดสอบ DNS จาก client จริง ควรได้คำตอบและเวลาแปลงชื่อตามปกติ หากล้มซ้ำ ให้เก็บ log ก่อนเปลี่ยนค่าเพิ่ม
systemctl is-active unbound
sudo journalctl -u unbound -b --no-pager -n 100
dpkg-query -W -f='${binary:Package}\t${Version}\n' unbound libunbound8
ประกาศ NLnet Labs ที่ลิงก์ไว้ไม่มี IOC เช่น IP ผู้โจมตีหรือ hash ให้ใช้ยืนยันเหตุ หลังอัปเดตควรดูว่า process ยังล่มหรือเริ่มใหม่บ่อยไหม ตรวจหน่วยความจำและ CPU ถ้าสูงพร้อมกับมีคำถาม DNS ผิดปกติ ให้เก็บข้อมูลไว้ตรวจต่อ คำตอบใน cache ที่ไม่ตรงกับข้อมูลโซนก็ควรตรวจเช่นกัน อาการเหล่านี้อย่างเดียวใช้ยืนยัน CVE หรือการบุกรุกไม่ได้ อ่านแนวทางตรวจระบบต่อได้ใน ตรวจความปลอดภัย Debian server
ผมจะจัดลำดับงานอย่างไร
ผมจะเร่งแพตช์ resolver ที่รับคำถามจากภายนอก หรือที่เว็บและเมลใช้ร่วมกันก่อน เพราะ DNS ล่มแล้วงานอื่นอาจหยุดตามไปด้วย ระบบภายในก็ควรเข้ารอบอัปเดตที่ใกล้ที่สุด การไม่ได้เปิด DoQ ไม่ได้ป้องกันทุกช่องโหว่ในชุดนี้ ส่วน Ubuntu 26.10 ต้องตรวจสถานะและเลขแพ็กเกจที่แก้จาก Ubuntu ให้ชัดก่อนปิดงาน
ที่มา: Ubuntu USN-8946-1, Ubuntu CVE-2026-81634 และรายการประกาศต่อเนื่อง, Amazon Linux CVE-2026-81634, NLnet Labs Security Advisories, ประกาศราย CVE ที่ลิงก์ไว้ในเนื้อหา, CVE record ของ NLnet Labs, Red Hat CVE-2026-81634, CISA KEV และ คู่มือ unbound-checkconf ตรวจทานวันที่ 11 พ.ย. 2026 โดย KEV ที่เปิดอ่านเป็นฉบับ 9 พ.ย. 2026 ส่วน USN-8946-2 เปิดตัวประกาศไม่สำเร็จ เลยยังไม่ใส่เลขแพ็กเกจ Ubuntu 26.10 เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai



ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย