CERT công bố các CVE cho 6 lỗ hổng bảo mật nghiêm trọng trong dnsmasq
(lists.thekelleys.org.uk)- CERT đã công bố vào ngày 11 tháng 5 năm 2026 một bộ CVE cho 6 lỗ hổng bảo mật nghiêm trọng trong dnsmasq
- Tất cả các lỗ hổng này đều là các lỗi đã tồn tại từ lâu và ảnh hưởng đến gần như mọi phiên bản dnsmasq, ngoại trừ một số phiên bản rất cũ
- Các CVE đã được tiết lộ trước cho các nhà cung cấp, và mỗi nhà cung cấp cần phát hành phiên bản vá của gói dnsmasq kịp thời
- 2.92rel2, bản đã áp dụng các bản vá lên bản phát hành ổn định dnsmasq 2.92, đã được tạo và có thể tải từ địa điểm tải xuống hiện có
- Thẻ dnsmasq-2.93rc1 dự kiến sẽ sớm được tạo, và sau khi kiểm thử sẽ hướng tới phát hành 2.93 trong khoảng một tuần
Công bố lỗ hổng và bản vá của dnsmasq
- CERT đã công bố vào ngày 11 tháng 5 năm 2026 bộ CVE cho 6 lỗ hổng bảo mật nghiêm trọng trong dnsmasq
- Các lỗ hổng này đều là lỗi cũ và áp dụng cho gần như mọi phiên bản dnsmasq, ngoại trừ một số phiên bản rất cũ
- Các CVE đã được tiết lộ trước cho các nhà cung cấp, và mỗi nhà cung cấp cần phát hành phiên bản vá của gói dnsmasq kịp thời
- Có thể xem chi tiết và bản vá tại https://thekelleys.org.uk/dnsmasq/CVE/
- 2.92rel2, bản đã áp dụng các bản vá lên bản phát hành ổn định dnsmasq 2.92, đã được tạo và có thể tải từ địa điểm tải xuống hiện có
- Các commit sửa lỗi cũng sẽ được đưa lên nhánh phát triển vào cùng thời điểm; một số dùng cùng bản vá như các bản backport, còn một số là các bản viết lại toàn diện hơn để xử lý nguyên nhân gốc rễ
Sự gia tăng báo cáo dựa trên AI và kế hoạch cho 2.93
- Trong vài tháng gần đây, số lượng báo cáo lỗi đã tăng mạnh do nghiên cứu bảo mật dựa trên AI, và việc loại bỏ trùng lặp cùng phân loại lỗi đã tốn rất nhiều thời gian
- Các lỗi được chia thành những mục cần tiết lộ trước cho nhà cung cấp và những mục tốt hơn nên sửa ngay sau khi công khai; sự phân biệt này về mặt tất yếu mang tính chủ quan
- Vì cùng một lỗi đã bị nhiều “good guys” tìm thấy lặp lại, nên cũng có khả năng “bad guys” đã tìm ra, do đó embargo kéo dài được cho là không còn nhiều hiệu quả
- Việc điều phối embargo và cung cấp backport đòi hỏi rất nhiều thời gian và công sức từ tất cả các bên tham gia
- Phần lớn lỗi nên được sửa trong các bản phát hành sắp tới để các bản phát hành dnsmasq mới càng ít lỗi càng tốt, và đây là ưu tiên hàng đầu
- Việc có nhiều commit sửa lỗi bảo mật được đưa lên kho git trong vài tuần trước khi công bố cũng phù hợp với định hướng này
- Dự kiến sẽ sớm tạo thẻ dnsmasq-2.93rc1, và mục tiêu là phát hành bản ổn định 2.93 sớm nhất có thể
- Việc kiểm thử bản phát hành ứng viên rất quan trọng, vì vậy những ai có thể nên thử càng sớm càng tốt
- Nếu mọi việc diễn ra thuận lợi, 2.93 có thể ra mắt trong khoảng một tuần
- “Cơn sóng thần” báo cáo lỗi do AI tạo ra chưa có dấu hiệu dừng lại, nên nhiều khả năng quy trình tương tự sẽ sớm lặp lại
- Có sự căng thẳng giữa việc đưa càng nhiều càng tốt luồng lỗi đang tiếp diễn vào 2.93 và việc phát hành đúng lúc, và ưu tiên là phát hành kịp thời
1 bình luận
Ý kiến trên Hacker News
Có vẻ như chúng ta đã đến điểm mà việc chuyển mã viết bằng C sang ngôn ngữ an toàn bộ nhớ trở nên cấp bách
Phần lớn các lỗ hổng được phát hiện gần đây có liên quan trực tiếp đến những ngôn ngữ không an toàn bộ nhớ, và thật khó để biện minh rằng không thể viết máy chủ DNS/DHCP bằng Rust hay Go, nếu có thể thì không dùng
unsafeCác nhà nghiên cứu bảo mật AI ít nhất cũng đang làm gì đó. Nếu việc viết lại mọi thứ bằng Rust dễ đến vậy thì ngay ngày hôm sau những sự cố kiểu này phải có một bản thay thế Rust vững chắc xuất hiện rồi
Điều đó không xảy ra vì làm việc như thế rất khó kiếm sao GitHub
Tôi nghi ngờ việc “không biết kích thước tối đa nên mọi thứ đều phải là động” có thực sự đúng hay không. Chương trình khai báo kích thước đầu vào tối đa chấp nhận được, và nếu vượt quá thì báo lỗi hoặc dùng ring buffer, chuyện đó đâu phải tận thế
Nếu biết kích thước thì có thể thiết kế theo nó. RAM là hữu hạn, nên thật kỳ lạ khi mọi lớp bên trong lại được thiết kế như thể là vô hạn
Chuyển sang Rust có vẻ là một sự lãng phí thời gian khổng lồ, và nó không giải quyết được vấn đề gốc là không mô hình hóa chương trình theo thực tế rằng tài nguyên hệ thống là hữu hạn. Đây không chỉ là vấn đề bộ nhớ. Việc Chrome đưa mô hình 4GB lên thiết bị người dùng cũng tương tự
https://xchglabs.com/blog/dnsmasq-five-cves.html
Tôi đã tự hỏi liệu OpenWRT đã ra bản build mới chưa, và câu trả lời là chưa, vẫn đang làm
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
Bản phát hành được nói là “coming soon”
MaraDNS của tôi đã được kiểm toán khá sâu rộng khi bước vào thời kỳ kiểm toán bảo mật có hỗ trợ AI
Từ năm 2023 đến nay không phát hiện thêm dù chỉ một lỗi bảo mật nghiêm trọng nào [1]
Những gì kiểm toán viên tìm thấy chỉ là kiểu như “Deadwood khi ở chế độ đệ quy hoàn toàn, nếu nhận gói tin bất thường thì mất nhiều thời gian hơn bình thường để giải phóng tài nguyên” [2], hoặc “một tiện ích phụ đi kèm MaraDNS thậm chí còn không biên dịch được từ năm 2022 nhưng lại có buffer overflow chỉ khi
$HOMEdài hơn 50 ký tự” [3]Cá nhân tôi rất hài lòng khi MaraDNS tỏ ra khá an toàn trong lúc đang được kiểm toán bảo mật thực sự, ở mức sâu
[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 cũng không phải là chưa từng có bản vá bảo mật
Tôi cũng có vài thư viện tự viết, và từ năm 1991 đến nay chưa từng phát hiện một lỗi bảo mật nghiêm trọng nào. Tất nhiên là chẳng ai dùng thư viện của tôi cả
Không phải để hạ thấp thành quả đó, nhưng những tuyên bố như vậy cần được đặt trong bối cảnh quy mô người dùng
Màn quảng bá này hầu như không có giá trị gì trong thảo luận về dnsmasq
Phần mềm được dùng nhiều hơn sẽ bị soi xét nhiều hơn, và sẽ phát hiện ra nhiều lỗi cũng như trường hợp biên hơn
May mà phần mềm này đâu có chạy trên hàng triệu thiết bị gần như chẳng bao giờ nhận cập nhật
Khá nghiêm trọng
“Kẻ tấn công từ xa có thể thực hiện truy vấn DNS hoặc có thể trả lời DNS có thể gây ra ghi ngoài phạm vi lớn trên heap”
Một phản hồi DNS sai có thể “gây ra vòng lặp vô hạn khiến dnsmasq không trả lời bất kỳ truy vấn nào nữa”
Yêu cầu DHCP độc hại có thể gây buffer overflow
Cơn sóng thần bug report do AI tạo ra không có ở mọi dự án. Như đã nói ở trên, MaraDNS không gặp chuyện đó
Tôi cũng cho rằng djbdns và tinydns không gặp. Nếu có thì hẳn họ đã quảng bá rầm rộ rồi
Tôi chưa bao giờ thực sự hiểu vì sao có dự án cực kỳ nổi tiếng còn có dự án thì không
Có cảm giác như các công cụ “quá nguy hiểm để công bố” đang quét mọi dự án nhưng chỉ chọn lọc liên hệ với nơi có vấn đề. Như vậy họ không phải thừa nhận rằng công cụ của mình đã chẳng tìm ra gì
Tôi chưa bao giờ thích dùng dnsmasq. Nó luôn cho cảm giác nhét quá nhiều thứ vào một công cụ
Tôi luôn thích cấu hình riêng bộ phân giải đệm cục bộ, máy chủ DHCP và cấu hình khởi động TFTP/PXE hơn
Ví dụ như chuyển tiếp truy vấn
*.example.comđến một máy chủ upstream cụ thể, trả về NXDOMAIN cho các trang lừa đảo, hoặc thêm mọi IP được phân giải từ*.example.orgvàoipsetđể dùng cho định tuyến theo chính sáchTính năng cuối cùng còn hoạt động trên FreeBSD dù BSD không có
ipset. Danh sách*.example_xyz.comcó thể rất lớn, và dnsmasq gần đây được cho là xử lý việc này hiệu quả10/10, không hối hận, đáng để khuyên dùng
Ví dụ Opnsense chỉ dùng phần DHCP của dnsmasq và dùng unbound cho DNS, điều này tạo cảm giác hơi “kỳ quặc”
DHCP và DNS có liên hệ với nhau, còn PXE thì cần các mục DHCP. Nếu muốn thiết lập đơn giản, nếu không bạn phải nối ít nhất 3 daemon có cú pháp cấu hình khác nhau với nhau
Đây là một câu hỏi của người mới muốn hỏi những ai có nhiều kinh nghiệm hơn trong lĩnh vực này: tại sao phần mềm trong mảng này lại không được viết nhiều hơn bằng các runtime ngôn ngữ có garbage collection và đồng thời như Erlang?
Tổn thất hiệu năng là quá lớn, có một runtime khá mờ mịt mà khó biết lúc đó có ổn định hay không, ít người đóng góp, và dấu chân phụ thuộc cũng lớn vì hầu hết hệ thống không cài sẵn
Ngay cả khi tôi dùng Erlang cho hệ thống production vào khoảng năm 2015, chỉ cần lệch hơi khỏi mục đích sử dụng ban đầu là vẫn có những chỗ thô ráp. Đây không phải chỉ trích riêng Erlang; nhiều ngôn ngữ và runtime khác cũng tương tự
Không ít hệ thống sẽ còn tiếp tục bị ảnh hưởng trong vài tuần hay vài tháng tới cũng có bối cảnh tương tự. Với Linux kernel, lựa chọn thay thế tiềm năng vào thời đó gần như chỉ là C++ mà thôi. OpenSSL, một cái tên quen thuộc của các vấn đề bảo mật, bắt đầu từ năm 1998
Tôi rất đồng ý với quan điểm “đừng viết dự án mới có truy cập mạng bằng C”, nhưng nếu quay lại năm 1998 thì thật khó nói lựa chọn nào khác là thực tế
Đã có những ngôn ngữ an toàn hơn, nhưng cộng đồng của chúng nhỏ hơn cộng đồng C rất nhiều và cũng khó bảo đảm độ ổn định hơn. Java khi đó đã tồn tại, nhưng tôi không rõ chính xác từ lúc nào nó trở thành ứng viên nghiêm túc cho máy chủ mạng; tôi đoán đâu đó cuối những năm 2000. Java mà tôi thấy năm 1999 thì chưa tới mức đó
Chẳng hạn năm 2011 tôi từng vận hành một máy chủ mạng Haskell cho mục đích tương đối không quá quan trọng, và nó sập trong những điều kiện mà với mạng production thì không thể xem là quá cực đoan. Năm 2013 tôi tái sử dụng cùng codebase đó mà không thay đổi vòng lặp thực thi cốt lõi, và nó tốt hơn khoảng 90%, nên tôi cho rằng vấn đề ở phía Haskell hơn là do mã của tôi
Dù vậy nó vẫn chưa đủ để đưa vào production thực sự, nhưng ít nhất nó cho thấy không phải mã của tôi bị lỗi. Điều đó cũng có nghĩa là dù Haskell đã tồn tại trong thập niên 2000, vẫn khó xem nó là một lựa chọn thực tế cho máy chủ mạng thời điểm đó
Bây giờ thì chúng ta có nhiều lựa chọn hơn rất nhiều so với trước đây
structtrực tiếp vào gói tin mạng nên khá dễỞ các ngôn ngữ khác thì thường không đơn giản như vậy
Tất nhiên là còn chậm hơn và cồng kềnh hơn nữa