OpenSSL vá lỗ hổng DTLS mức độ nghiêm trọng cao có thể gây rò rỉ bộ nhớ Heap không mã hóa

Một lỗ hổng OpenSSL mức độ nghiêm trọng cao có thể làm rò rỉ bộ nhớ heap sang phía bên kia của kết nối DTLS hoặc làm treo chương trình. OpenSSL đã công bố thông tin này vào ngày 29 tháng 9 cùng với các bản vá lỗi. DTLS, một biến thể của TLS dùng cho lưu lượng UDP, sẽ gửi lại tin nhắn bắt tay (handshake) nếu không nhận được phản hồi trước khi bộ đếm thời gian hết hạn. Việc rò rỉ hoặc treo máy có thể xảy ra khi quá trình gửi lại bắt đầu trong khi một tin nhắn bắt tay lớn hơn đang bị kẹt giữa chừng.
Lỗ hổng OpenSSL DTLS

Một lỗ hổng OpenSSL mức độ nghiêm trọng cao có thể làm rò rỉ bộ nhớ heap sang phía bên kia của kết nối DTLS hoặc làm treo chương trình, OpenSSL cho biết vào ngày 29 tháng 9 khi phát hành các bản vá lỗi.

DTLS, một biến thể của TLS được sử dụng cho lưu lượng UDP, sẽ gửi lại tin nhắn bắt tay (handshake) nếu không nhận được phản hồi trước khi bộ đếm thời gian hết hạn. Việc rò rỉ hoặc treo máy có thể xảy ra khi quá trình gửi lại như vậy bắt đầu trong khi một tin nhắn bắt tay lớn hơn đang bị kẹt giữa chừng trong quá trình gửi.

Lỗ hổng này, được theo dõi với mã CVE-2026-84782, đã được khắc phục trong OpenSSL 4.0.3, 3.6.5, 3.5.9 và 3.4.8. Các phiên bản đã vá cho các nhánh cũ hơn như 3.0, 1.1.1 và 1.0.2 chỉ dành cho những khách hàng trả phí hỗ trợ cao cấp của OpenSSL. Nhánh OpenSSL 3.0 đã ngừng nhận các bản vá bảo mật công khai vào ngày 7 tháng 9.

OpenSSL chưa cho biết liệu kẻ tấn công có thể chủ động gây ra việc gửi lại tin nhắn khi tin nhắn bị kẹt hay không, và cũng chưa ghi nhận bất kỳ cuộc tấn công nào khai thác lỗ hổng này trong thực tế.

DTLS được sử dụng, ví dụ, để bảo vệ các kênh dữ liệu WebRTC và thiết lập khóa mã hóa cho các cuộc gọi internet. Phần mềm chỉ bị ảnh hưởng bởi lỗ hổng này nếu nó sử dụng OpenSSL cho DTLS.

DTLS chia một tin nhắn bắt tay lớn thành các phân đoạn (fragment), mỗi phân đoạn nằm vừa trong một datagram UDP. Nếu kết nối không thể chấp nhận thêm dữ liệu tại thời điểm đó, việc gửi có thể tạm dừng giữa chừng và tiếp tục sau. Trong khi việc gửi bị tạm dừng, bộ đếm thời gian gửi lại vẫn có thể kích hoạt và gửi lại tin nhắn trước đó.

Trước khi có bản vá, quá trình gửi lại đã sử dụng vị trí của tin nhắn đang bị tạm dừng trong bộ đệm (buffer) thay vì quay trở lại điểm bắt đầu của tin nhắn đang được gửi lại. Tin nhắn được gửi lại đi kèm với nhãn sai. Nội dung của nó là các byte còn sót lại từ tin nhắn lớn hơn, và việc đọc nó có thể gây tràn bộ đệm (buffer overrun).

Theo OpenSSL, tin nhắn bị dán nhãn sai có thể mang theo bộ nhớ heap sang phía bên kia dưới dạng dữ liệu bắt tay không được mã hóa. Nếu việc đọc chạm đến vùng nhớ chưa được ánh xạ (unmapped memory), chương trình sẽ bị treo.

OpenSSL không giới hạn lỗ hổng này chỉ ở DTLS client hay server, và bản vá đã được thử nghiệm thành công ở cả hai vai trò.

Laurent Gaffie từ Secorizon đã báo cáo lỗ hổng vào ngày 17 tháng 8, và Ryan Hooper đã phát triển bản vá.

OpenSSL xếp hạng lỗ hổng này ở mức Cao (High), thấp hơn một bậc so với mức Nguy cấp (Critical) trong thang đo mức độ nghiêm trọng của họ. Chính sách bảo mật của dự án khuyến nghị cài đặt các bản cập nhật có bản vá mức Cao càng sớm càng tốt.

CISA đã đưa ra điểm CVSS là 8.2 trên 10 vào ngày 29 tháng 9, đánh giá tác động của nó đối với tính bảo mật là Thấp và đối với tính khả dụng là Cao. Hồ sơ của CISA liệt kê tình trạng khai thác là "none" vào thời điểm đó. OpenSSL không sử dụng CVSS để thiết lập xếp hạng mức độ nghiêm trọng và cho biết điểm số từ các bên thứ ba có thể khác biệt đáng kể so với đánh giá của họ.

Thông báo bảo mật của Ubuntu cho biết kẻ tấn công có thể sử dụng lỗ hổng này để gây ra "hành vi bắt tay không chính xác hoặc từ chối dịch vụ (DoS)". Thông báo này không đề cập đến việc rò rỉ bộ nhớ.

Các phiên bản khắc phục lỗ hổng

Lỗ hổng ảnh hưởng đến OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 và 1.0.2, trong mọi bản phát hành trước phiên bản đã vá được liệt kê dưới đây.

Nhánh (Branch) Phiên bản đã vá Đối tượng nhận bản vá Trạng thái hỗ trợ
4.0 4.0.3 Tải xuống công khai Hỗ trợ đến 14/05/2027
3.6 3.6.5 Tải xuống công khai Hỗ trợ đến 01/11/2026
3.5 3.5.9 Tải xuống công khai Hỗ trợ dài hạn (LTS), đến 08/04/2030
3.4 3.4.8 Tải xuống công khai Hỗ trợ đến 22/10/2026
3.0 3.0.23 Chỉ khách hàng hỗ trợ cao cấp Hỗ trợ công khai đã kết thúc 07/09/2026
1.1.1 1.1.1zj Chỉ khách hàng hỗ trợ cao cấp Không còn hỗ trợ công khai
1.0.2 1.0.2zs Chỉ khách hàng hỗ trợ cao cấp Không còn hỗ trợ công khai
3.1, 3.2, 3.3 Không có Không áp dụng Không hỗ trợ công khai. OpenSSL không kiểm tra các nhánh này.

OpenSSL không liệt kê giải pháp thay thế nào cho những người dùng chưa thể cập nhật. Ubuntu đã khắc phục lỗ hổng vào ngày 29 tháng 9 trong các gói riêng của mình:

  • Ubuntu 26.04 LTS: libssl3t64 3.5.5-1ubuntu3.6
  • Ubuntu 24.04 LTS: libssl3t64 3.0.13-0ubuntu3.16
  • Ubuntu 22.04 LTS: libssl3 3.0.2-0ubuntu1.30

Người dùng Ubuntu cần khởi động lại máy sau khi cập nhật để tất cả các thay đổi có hiệu lực.

Debian đã sửa lỗ hổng trong Debian 13 với phiên bản 3.5.7-1~deb13u3 của gói openssl, được phát hành dưới mã DSA-6531-1.

Người dùng OpenSSL 3.0 có thể làm gì

Bản phát hành công khai cuối cùng của nhánh 3.0 là 3.0.22 vào ngày 25 tháng 8. Phiên bản 3.0.23 là bản phát hành bảo mật đầu tiên của nhánh 3.0 mà OpenSSL không công khai. Nó khắc phục 6 trong số 14 lỗ hổng được tiết lộ vào ngày 29 tháng 9, bao gồm CVE-2026-84782.

Đối với Ubuntu 22.04 và 24.04 sử dụng OpenSSL 3.0, bản vá đã có sẵn trong các gói liệt kê ở trên. Bất kỳ ai tự xây dựng OpenSSL 3.0 hoặc nhúng một bản sao bên trong phần mềm của họ sẽ không nhận được bản vá công khai từ OpenSSL.

OpenSSL khuyến nghị nâng cấp lên một nhánh mới hơn, chẳng hạn như 4.0 hoặc bản phát hành hỗ trợ dài hạn 3.5. Lựa chọn khác là hợp đồng hỗ trợ trả phí để tiếp tục tiếp cận các bản vá bảo mật sau ngày kết thúc hỗ trợ công khai.

Các bản phát hành ngày 29 tháng 9 cũng khắc phục 13 lỗ hổng khác. Nghiêm trọng nhất trong số đó là CVE-2026-84783, được xếp hạng Trung bình (Moderate) và chỉ ảnh hưởng đến OpenSSL 4.0.

Một thực thể từ xa, không cần xác thực có thể sử dụng nó để làm treo một TLS client đa luồng, hoặc một TLS server đa luồng có yêu cầu chứng chỉ client. Điều đó chỉ xảy ra nếu nhiều kết nối cùng lúc xây dựng chuỗi chứng chỉ đầu tiên của họ đến cùng một chứng chỉ CA đáng tin cậy.

Một lỗ hổng DTLS khác, CVE-2026-75806, được xếp hạng Thấp (Low). Nó ảnh hưởng đến các kết nối DTLS 1.2 đã thiết lập sử dụng bộ mã hóa AEAD. Bất kỳ ai có thể gửi datagram đến một kết nối như vậy đều có thể chấm dứt nó chỉ bằng một datagram quá ngắn mà không cần biết bất kỳ khóa nào.

11 lỗ hổng còn lại cũng được xếp hạng Thấp, bao gồm 5 lỗi trong mã QUIC của OpenSSL và 3 lỗi kênh kề về thời gian (timing side-channels) trong mã ECDSA và SM2.