Cảnh báo Unbound: Lỗ hổng DNSSEC nghiêm trọng có thể dẫn đến thực thi mã từ xa

NLnet Labs đã phát hành Unbound 1.26.1 để xử lý chín lỗ hổng bảo mật, nổi bật là CVE-2026-81642 trong bộ xác thực DNSSEC. Lỗi tràn bộ đệm heap được đánh giá nghiêm trọng, có thể khiến dịch vụ ngừng hoạt động và trong một số điều kiện cho phép thực thi mã từ xa. Các tổ chức vận hành trình phân giải DNS Unbound nên ưu tiên cập nhật, dù chưa có bằng chứng công khai về việc lỗ hổng bị khai thác ngoài thực tế.

Biểu trưng NLnet Labs, đơn vị phát triển Unbound
Unbound là trình phân giải DNS mã nguồn mở do NLnet Labs phát triển. Ảnh: NLnet Labs

CVE-2026-81642 nguy hiểm như thế nào?

CVE-2026-81642 ảnh hưởng đến mọi phiên bản Unbound đến và bao gồm 1.26.0. Theo khuyến cáo của NLnet Labs, lỗi xuất hiện khi bộ xác thực DNSSEC xử lý bản ghi DNSKEY có tên chủ sở hữu sử dụng con trỏ nén trỏ vào chính dữ liệu của bản ghi. Quá trình tính toán digest có thể ghi vượt ra ngoài vùng nhớ heap.

Kẻ tấn công cần kiểm soát một vùng DNS độc hại và khiến trình phân giải dễ bị ảnh hưởng truy vấn vùng đó. Điều kiện khai thác không yêu cầu tài khoản hay tương tác của người dùng. NLnet Labs chấm lỗi ở mức Critical với điểm CVSS 4.0 là 9,1; tác động được xác định gồm từ chối dịch vụ và khả năng thực thi mã từ xa bằng dữ liệu do kẻ tấn công kiểm soát.

Tại thời điểm công bố, NLnet Labs chưa ghi nhận hoạt động khai thác. Cơ sở dữ liệu CVE của CISA cũng đánh dấu trạng thái khai thác là “none”. Vì vậy, thông tin hiện có cho thấy đây là rủi ro cần vá khẩn cấp, nhưng không phải bằng chứng về một chiến dịch tấn công đang diễn ra.

Unbound 1.26.1 xử lý tổng cộng chín lỗ hổng

Bên cạnh CVE-2026-81642, bản phát hành ngày 16/9/2026 còn khắc phục tám vấn đề khác. Đáng chú ý nhất là CVE-2026-82717, lỗi hỏng bộ nhớ trong quá trình tổng hợp CNAME. NLnet Labs xếp lỗi này ở mức High và cho biết nó có thể dẫn đến thực thi mã trên một số hệ thống, tùy thuộc tùy chọn biên dịch.

Các bản vá còn lại xử lý tràn bộ đệm trong quá trình chuẩn hóa DNSSEC, cửa sổ bỏ qua xác minh ZONEMD, lỗi use-after-free ở DNS-over-QUIC và DNS-over-HTTPS, tình trạng một kết nối TCP hoặc DoT chiếm dụng worker, các cuộc tấn công độ phức tạp thuật toán ReTrap, cùng khả năng cơ chế serve-expired bị lợi dụng trong tấn công khuếch đại từ chối dịch vụ.

Dòng thời gian phát hiện và khắc phục

Hai nhà nghiên cứu Yuqi Qiu và Xiang Li thuộc AOSP Lab, Đại học Nankai, báo cáo CVE-2026-81642 cho NLnet Labs vào ngày 11/8/2026. Nhà phát triển chuyển bản vá cho nhóm nghiên cứu vào ngày hôm sau và nhận xác nhận vào ngày 13/8. Sau khoảng năm tuần phối hợp, bản vá được phát hành cùng Unbound 1.26.1 vào ngày 16/9.

Quy trình này cho thấy khoảng thời gian công bố có trách nhiệm được sử dụng để kiểm thử bản sửa và gom nhiều thay đổi bảo mật vào một bản phát hành. Tuy nhiên, sau khi chi tiết kỹ thuật đã công khai, các hệ thống chưa cập nhật có nguy cơ bị phân tích và xây dựng mã khai thác nhanh hơn.

Ai cần hành động ngay?

Quản trị viên nên kiểm kê các máy chủ, thiết bị mạng, nền tảng DNS nội bộ và sản phẩm đóng gói Unbound. Việc chỉ kiểm tra dịch vụ DNS hướng Internet là chưa đủ, bởi trình phân giải nội bộ vẫn có thể được dẫn tới một vùng do kẻ tấn công kiểm soát thông qua lưu lượng người dùng hoặc ứng dụng.

  • Nâng cấp lên Unbound 1.26.1 hoặc gói đã được nhà phân phối xác nhận chứa bản vá.
  • Nếu chưa thể nâng cấp, áp dụng bản vá độc lập cho CVE-2026-81642 hoặc bản vá kết hợp do NLnet Labs cung cấp, sau đó biên dịch và triển khai lại theo quy trình quản lý thay đổi.
  • Xác minh phiên bản thực tế của tiến trình đang chạy, không chỉ phiên bản gói đã tải xuống; khởi động lại dịch vụ nếu bản cập nhật yêu cầu.
  • Theo dõi tình trạng crash, khởi động lại bất thường, truy vấn DNSKEY khác thường và lưu lượng tới các vùng DNS mới xuất hiện.
  • Với thiết bị hoặc sản phẩm nhúng, liên hệ nhà cung cấp để xác định phiên bản Unbound đi kèm và lịch phát hành firmware.

Bài học cho vận hành hạ tầng DNS

DNS resolver là thành phần nền tảng, thường chạy liên tục và tiếp xúc với dữ liệu từ nhiều miền bên ngoài. Một lỗi bộ nhớ trong bước xác thực DNSSEC có thể biến dữ liệu vốn được thiết kế để tăng độ tin cậy thành đường kích hoạt sự cố. Do đó, DNS cần được đưa vào cùng chu kỳ quản trị lỗ hổng với hệ điều hành, VPN và cổng truy cập từ xa.

Các tổ chức cũng nên duy trì cấu hình dự phòng, giám sát sức khỏe resolver và kế hoạch chuyển lưu lượng khi cập nhật. Phân đoạn hạ tầng, chạy dịch vụ với quyền tối thiểu và áp dụng cơ chế bảo vệ bộ nhớ của hệ điều hành có thể giảm hậu quả, nhưng không thay thế bản vá chính thức.

VNCyberS tổng hợp từ NLnet Labs và The Hacker News

Liên hệ với chúng tôi

Email: [email protected]
Điện thoại: +84 903260277