OpenBSD LibreSSL ocspcheck cạn kiệt bộ nhớ do phản hồi HTTP OCSP không giới hạn

LibreSSL ocspcheck chứa lỗ hổng cạn kiệt bộ nhớ cho đến và bao gồm 4.4.0, cho phép các OCSP responder độc hại làm cạn kiệt bộ nhớ bằng cách gửi các phản hồi HTTP không giới hạn. Kẻ tấn công kiểm soát responder hoặc chặn lưu lượng OCSP AIA qua HTTP không mã hóa có thể truyền vô hạn phần header hoặc body tới http_head_read() và http_body_read(), khiến các lần kiểm tra trạng thái chứng chỉ bị từ chối.

• OpenBSD LibreSSL: phạm vi được xác nhận là từ 0 đến và bao gồm 4.4.0 theo kiểu phiên bản semver. Thành phần chịu ảnh hưởng là ocspcheck và phần đọc phản hồi HTTP của nó.
• Bản ghi đặt trạng thái mặc định là unaffected bên ngoài phạm vi affected đã nêu.
• Bản ghi không xác định tình trạng của các nhánh song song hoặc các bản phát hành sau phạm vi này; không nên suy luận rằng mọi bản phát hành mới hơn đều đã được sửa.

Lỗ hổng nằm trong thành phần xử lý phản hồi HTTP của ocspcheck, cụ thể là các hàm http_head_read() và http_body_read(). Khi đọc header, chương trình liên tục mở rộng bộ đệm cho đến khi nhận được dấu kết thúc header, nhưng phiên bản bị ảnh hưởng không giới hạn kích thước header. Khi đọc body, chương trình tiếp tục mở rộng bộ đệm theo dữ liệu nhận được, vì vậy một responder có thể truyền dữ liệu không kết thúc để buộc tiến trình cấp phát ngày càng nhiều bộ nhớ. Điều kiện khai thác là ocspcheck phải thực hiện kết nối tới OCSP responder qua mạng, và kẻ tấn công phải kiểm soát responder hoặc chặn được lưu lượng OCSP AIA qua HTTP không mã hóa. Đây là lỗi CWE-770, với hậu quả được xác nhận là cạn kiệt bộ nhớ và làm gián đoạn kiểm tra trạng thái chứng chỉ. Bằng chứng hiện có không xác định chi tiết hành vi của mọi môi trường sau khi cấp phát bộ nhớ thất bại.

• Khả năng tiếp cận: Khai thác từ xa qua mạng khi hệ thống thực hiện truy vấn OCSP.
• Điều kiện: Kẻ tấn công cần kiểm soát OCSP responder hoặc chặn lưu lượng OCSP AIA sử dụng HTTP không mã hóa. Bản ghi cho biết không yêu cầu quyền xác thực hoặc tương tác người dùng.
• Trạng thái khai thác: Bản ghi đánh dấu không có public exploit và không đánh dấu lỗ hổng là đã bị khai thác; các tài liệu đã kiểm tra không mô tả một chiến dịch hoặc exploit cụ thể.
• Giới hạn: Việc không có exploit công khai được ghi nhận không chứng minh rằng lỗ hổng chưa từng bị khai thác.

• Kết quả kỹ thuật được xác nhận là tiến trình ocspcheck có thể tiêu thụ bộ nhớ không giới hạn khi nhận header hoặc body HTTP không kết thúc.
• Điều này có thể làm cạn kiệt bộ nhớ của tiến trình hoặc hệ thống, khiến các lần kiểm tra trạng thái chứng chỉ bị từ chối hoặc thất bại.
• Bản ghi không cho thấy ảnh hưởng đến tính bí mật hoặc tính toàn vẹn; tác động chính nằm ở availability của certificate status checks.
• Nếu tiến trình dùng chung tài nguyên với workload khác, áp lực bộ nhớ có thể ảnh hưởng đến các workload đó, nhưng đây là hệ quả có thể xảy ra chứ không phải một tác động độc lập đã được xác nhận.

• Các quy trình phụ thuộc vào certificate status checks có thể bị treo, thất bại hoặc trả về lỗi khi ocspcheck bị buộc cấp phát bộ nhớ liên tục.
• Mức tiêu thụ bộ nhớ tăng có thể gây áp lực lên tài nguyên của máy chủ hoặc workload chạy cùng hệ thống, nhưng bằng chứng hiện có không xác nhận một ảnh hưởng rộng hơn ngoài tình trạng suy giảm tính sẵn sàng.
• Lỗ hổng được mô tả là ảnh hưởng đến availability; không có bằng chứng trong bản ghi cho thấy kẻ tấn công đọc được dữ liệu hoặc sửa đổi dữ liệu.
• Các hệ thống kiểm tra OCSP qua mạng cần được ưu tiên xử lý, nhất là khi đường truyền sử dụng HTTP không mã hóa và có thể bị chặn.

1. Cập nhật LibreSSL bằng bản phát hành hoặc bản build của nhà cung cấp có chứa cả hai thay đổi upstream giới hạn kích thước HTTP response. Bản ghi xác nhận có patch nhưng không cung cấp một exact fixed release, vì vậy không nên tự động coi một bản phát hành cụ thể là an toàn nếu chưa xác minh.
2. Nếu phải tự build hoặc backport, xác nhận mã nguồn đã giới hạn header HTTP ở mức 64 KB và từ chối body OCSP lớn hơn 20 KB. Hai giới hạn này tương ứng với các thay đổi upstream cho ocspcheck.
3. Ưu tiên cập nhật các hệ thống thực hiện certificate status checks qua các responder có thể bị truy cập hoặc tác động từ mạng.
4. Trong thời gian chờ cập nhật, nếu kiến trúc triển khai cho phép, tránh truy vấn OCSP AIA qua HTTP không mã hóa. Đây chỉ là biện pháp giảm rủi ro một phần và không loại bỏ nguy cơ từ một responder độc hại.
5. Sau khi cập nhật, kiểm thử lại các luồng kiểm tra OCSP và theo dõi mức sử dụng bộ nhớ trong các lần truy vấn responder.

1. Kiểm kê các hệ thống cài LibreSSL và xác định nơi triển khai hoặc gọi ocspcheck; đối chiếu phiên bản với phạm vi bị ảnh hưởng trong phần affected_summary.
2. Xác định các luồng xác thực chứng chỉ lấy địa chỉ OCSP từ AIA, đặc biệt các luồng sử dụng HTTP không mã hóa.
3. Rà soát telemetry mạng của máy chạy ocspcheck để tìm các kết nối tới OCSP responder có thời gian kéo dài bất thường hoặc phản hồi tăng liên tục. Đây là biện pháp giám sát phòng ngừa, không phải IOC đã được xác nhận.
4. Theo dõi mức sử dụng bộ nhớ của tiến trình hoặc workload thực hiện kiểm tra OCSP trong khi truy vấn responder. Mức tăng bộ nhớ bất thường có thể hỗ trợ phát hiện, nhưng không phải dấu hiệu duy nhất của lỗ hổng.
5. Tài liệu hiện có không cung cấp log signature hoặc IOC cụ thể; không nên coi việc không có log bất thường là bằng chứng hệ thống an toàn.