- 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 của dnsmasq
- Các lỗ hổng này đều là bug cũ 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 với các bản vá được áp dụng lên bản phát hành ổn định dnsmasq 2.92 đã được tạo ra và có thể tải từ vị trí tải xuống hiện có
- Thẻ dnsmasq-2.93rc1 sẽ sớm được tạo, sau quá trình 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 dnsmasq và bản vá
- 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 của dnsmasq
- Các lỗ hổng này đều là bug 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 với các bản vá được áp dụng lên bản phát hành ổn định dnsmasq 2.92 đã được tạo ra và có thể tải từ vị trí tải xuống hiện có
- Các commit sửa lỗi cũng sẽ được đưa lên cây phát triển cùng thời điểm; một số dùng cùng bản vá như backport, một số khác 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 của báo cáo do AI tạo ra và kế hoạch cho 2.93
- Trong vài tháng gần đây, các nghiên cứu bảo mật dựa trên AI đã làm số lượng báo cáo bug tăng mạnh, và việc loại bỏ trùng lặp cũng như phân loại bug tốn rất nhiều thời gian
- Các bug đượ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 nên sửa ngay sau khi công khai; sự phân biệt này về bản chất khó tránh khỏi tính chủ quan
- Vì cùng một bug đã bị nhiều “good guys” phát hiện lặp đi lặp lại, nên có khả năng “bad guys” cũng có thể tìm ra; do đó họ cho rằng embargo dài không mang lại nhiều hiệu quả thực tế
- 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 bug sẽ được sửa trong các bản phát hành sắp tới, và ưu tiên là đưa ra các bản phát hành dnsmasq mới với trạng thái ít bug nhất có thể
- Việc có nhiều commit sửa lỗi bảo mật được đẩy lên kho git trong vài tuần trước thông báo cũng phù hợp với định hướng này
- Họ sẽ sớm tạo thẻ dnsmasq-2.93rc1, với mục tiêu phát hành phiên 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 là rất quan trọng, vì vậy những ai có thể nên thử nghiệm sớm
- Nếu mọi việc diễn ra suôn sẻ, 2.93 có thể ra mắt trong khoảng một tuần
- “Làn sóng thần” báo cáo bug do AI tạo ra chưa có dấu hiệu dừng lại, nên khả năng cao quy trình tương tự sẽ sớm lặp lại
- Có sự căng thẳng giữa việc đưa vào 2.93 nhiều nhất có thể luồng bug đang tiếp diễn và việc phát hành đúng lúc, và ưu tiên hiện tại 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