CVE-2024-5535 in OpenSSL
Tóm tắt
Bởi VulDB • 24/07/2026
Tóm tắt vấn đề: Việc gọi hàm API OpenSSL `SSL_select_next_proto` với bộ đệm giao thức khách hàng (client protocols) rỗng có thể gây ra sự cố treo ứng dụng hoặc làm rò rỉ nội dung bộ nhớ sang bên đối tác.
Tóm tắt mức độ ảnh hưởng: Một lỗi đọc vượt quá vùng đệm (buffer overread) có thể dẫn đến nhiều hậu quả tiềm ẩn, chẳng hạn như hành vi ứng dụng không mong muốn hoặc bị treo hệ thống. Cụ thể, vấn đề này có thể khiến tối đa 255 byte dữ liệu riêng tư tùy ý từ bộ nhớ được gửi sang bên đối tác, dẫn đến mất tính bảo mật (loss of confidentiality). Tuy nhiên, chỉ các ứng dụng trực tiếp gọi hàm `SSL_select_next_proto` với danh sách giao thức khách hàng hỗ trợ có độ dài bằng 0 mới chịu ảnh hưởng bởi vấn đề này. Thông thường, đây không phải là một kịch bản hợp lệ và cũng thường nằm ngoài khả năng kiểm soát của kẻ tấn công; tuy nhiên, nó có thể xảy ra do lỗi cấu hình hoặc lập trình trong ứng dụng gọi.
Hàm API OpenSSL `SSL_select_next_proto` thường được sử dụng bởi các ứng dụng TLS hỗ trợ ALPN (Application Layer Protocol Negotiation) hoặc NPN (Next Protocol Negotiation). NPN là giao thức cũ hơn, chưa từng được chuẩn hóa và hiện đã bị loại bỏ để nhường chỗ cho ALPN. Chúng tôi tin rằng ALPN được triển khai rộng rãi hơn đáng kể so với NPN. Hàm `SSL_select_next_proto` chấp nhận một danh sách các giao thức từ máy chủ và một danh sách các giao thức từ khách hàng, sau đó trả về giao thức đầu tiên xuất hiện trong cả hai danh sách. Trong trường hợp không có sự trùng lặp giữa hai danh sách, hàm sẽ trả về mục đầu tiên trong danh sách khách hàng. Dù là trường hợp nào, hàm cũng sẽ báo hiệu xem đã tìm thấy sự trùng lặp hay chưa. Khi `SSL_select_next_proto` được gọi với danh sách khách hàng có độ dài bằng 0, nó không nhận ra điều kiện này và trả về bộ nhớ ngay sau con trỏ danh sách khách hàng (và báo cáo rằng không có sự trùng lặp trong các danh sách).
Hàm này thường được gọi từ một callback ứng dụng phía máy chủ cho ALPN hoặc một callback ứng dụng phía khách hàng cho NPN. Trong trường hợp ALPN, libssl đảm bảo rằng danh sách giao thức do khách hàng cung cấp sẽ không bao giờ có độ dài bằng 0. Danh sách các giao thức của máy chủ đến từ ứng dụng và thông thường không nên mong đợi nó có độ dài bằng 0. Trong trường hợp này, nếu hàm `SSL_select_next_proto` được gọi như dự kiến (với danh sách do khách hàng cung cấp được truyền vào tham số client/client_len), thì ứng dụng sẽ không bị lỗ hổng đối với vấn đề này. Nếu ứng dụng vô tình được cấu hình với danh sách máy chủ có độ dài bằng 0, và vô tình chuyển danh sách máy chủ có độ dài bằng 0 đó vào các tham số client/client_len, đồng thời thất bại trong việc xử lý đúng phản hồi "không trùng lặp" (vốn thường dẫn đến lỗi bắt tay handshake trong ALPN), thì nó sẽ dễ bị tổn thương trước vấn đề này.
Trong trường hợp NPN, giao thức cho phép khách hàng chọn cơ hội một giao thức khi không có sự trùng lặp. OpenSSL trả về giao thức khách hàng đầu tiên trong trường hợp không trùng lặp để hỗ trợ điều này. Danh sách các giao thức khách hàng đến từ ứng dụng và thông thường không nên mong đợi nó có độ dài bằng 0. Tuy nhiên, nếu hàm `SSL_select_next_proto` vô tình được gọi với client_len là 0 thì một con trỏ bộ nhớ không hợp lệ sẽ được trả về thay thế. Nếu ứng dụng sử dụng đầu ra này làm giao thức chọn cơ hội, thì sự mất tính bảo mật sẽ xảy ra.
Vấn đề này đã được đánh giá có mức độ nghiêm trọng Thấp vì các ứng dụng hầu như chỉ dễ bị tổn thương nếu chúng đang sử dụng NPN thay vì ALPN - nhưng NPN không được sử dụng rộng rãi. Vấn đề cũng yêu cầu một lỗi cấu hình hoặc lập trình của ứng dụng. Cuối cùng, vấn đề này thường không nằm trong tầm kiểm soát
If you want to get best quality of vulnerability data, you may have to visit VulDB.