HollowByte là một lỗi đáng chú ý trong OpenSSL vì nó không cần mã khai thác phức tạp, không cần xác thực và cũng không có mã CVE để các hệ thống quét lỗ hổng dễ dàng nhận diện. Theo The Hacker News, nhóm Okta Red Team cho biết chỉ một phần đầu gói TLS rất nhỏ cũng có thể khiến máy chủ OpenSSL chưa vá cấp phát bộ nhớ rồi chờ phần dữ liệu không bao giờ tới.
HollowByte hoạt động như thế nào
Trong quá trình bắt tay TLS, thông điệp có phần tiêu đề khai báo độ dài phần thân. Với các phiên bản OpenSSL bị ảnh hưởng, thư viện có thể tin vào độ dài do phía bên kia khai báo và mở rộng bộ đệm nhận trước khi phần thân thực sự được gửi đầy đủ.
Điểm nguy hiểm nằm ở chỗ kẻ tấn công không cần hoàn tất phiên TLS. Chỉ cần gửi phần đầu đủ để máy chủ chuẩn bị bộ nhớ, sau đó giữ hoặc ngắt kết nối, tiến trình phục vụ TLS vẫn có thể đã trải qua một vòng cấp phát bộ nhớ không cần thiết. Khi thao tác này được lặp lại trên nhiều kết nối, lượng bộ nhớ thường trú của tiến trình tăng lên và dịch vụ có nguy cơ bị hệ điều hành kết thúc vì cạn RAM.
Vì sao 11 byte lại đáng ngại
Con số 11 byte tạo cảm giác nhỏ đến mức khó tin, nhưng bản chất của tấn công từ chối dịch vụ không phải lúc nào cũng nằm ở dung lượng dữ liệu gửi vào. Rủi ro xuất hiện khi đầu vào nhỏ kích hoạt phản ứng tốn tài nguyên ở phía máy chủ. Đây là mô hình quen thuộc của nhiều cuộc tấn công kiểu cạn kiệt kết nối hoặc cạn kiệt bộ nhớ.
The Hacker News dẫn phân tích của Okta cho biết trên một số hệ thống dùng glibc, bộ nhớ đã được giải phóng bởi OpenSSL không nhất thiết được trả ngay về hệ điều hành. Khi kích thước cấp phát thay đổi liên tục, heap có thể bị phân mảnh, khiến dung lượng RSS của tiến trình tăng và duy trì ở mức cao ngay cả sau khi kết nối độc hại đã biến mất.
Điểm khó: Không có CVE để bám theo
OpenSSL đã đưa bản sửa vào các bản phát hành ngày 09/06, gồm OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 và 3.0.21. Tuy nhiên, lỗi này được xử lý như một thay đổi sửa lỗi hoặc gia cố, không có CVE, không có advisory riêng và không được nhấn mạnh trong changelog theo cách quen thuộc với đội vận hành.
Điều đó khiến quản trị viên gặp khó hơn bình thường. Nhiều quy trình quản lý lỗ hổng dựa vào CVE, OVAL feed hoặc cảnh báo từ nhà phân phối hệ điều hành. Khi không có mã định danh rõ ràng, việc xác định một máy chủ đã nhận bản vá HollowByte hay chưa cần kiểm tra sâu hơn vào phiên bản gói, changelog downstream hoặc phản hồi từ maintainer.
Những hệ thống nào cần chú ý
Các dịch vụ dùng OpenSSL để xử lý TLS ở lớp máy chủ đều nên được rà soát, đặc biệt là reverse proxy, web server, API gateway, dịch vụ nội bộ có tiếp xúc Internet và hệ thống có mật độ kết nối cao. NGINX là một ví dụ được nhắc trong thử nghiệm của Okta, nhưng bài học rộng hơn là mọi tiến trình liên kết với thư viện OpenSSL cũ đều cần được kiểm tra.
Với các bản phân phối Linux có chính sách backport, số phiên bản hiển thị có thể không thay đổi dù bản vá đã được đưa vào. Vì vậy, chỉ nhìn chuỗi phiên bản OpenSSL đôi khi chưa đủ. Đội vận hành nên kiểm tra changelog của gói, advisory của nhà phân phối hoặc xác nhận bản vá tương ứng với pull request upstream đã được áp dụng.
Nên xử lý thế nào trong thực tế
Ưu tiên đầu tiên là cập nhật OpenSSL lên nhánh đã vá hoặc cài gói từ nhà phân phối đã backport bản sửa, sau đó khởi động lại các dịch vụ đang nạp thư viện cũ. Việc nâng cấp thư viện nhưng không restart tiến trình thường khiến dịch vụ tiếp tục chạy với bản OpenSSL chưa vá trong bộ nhớ.
Doanh nghiệp cũng nên theo dõi bất thường về RSS, số lượng kết nối TLS treo, lỗi OOM kill, áp lực swap và mức tiêu thụ bộ nhớ của các tiến trình proxy. Giới hạn kết nối vẫn hữu ích, nhưng theo phân tích được công bố, chỉ giới hạn số kết nối có thể chưa đủ nếu mỗi kết nối để lại hậu quả phân mảnh bộ nhớ khó thu hồi.
Bài học cho quản trị rủi ro
HollowByte nhắc lại một điểm quan trọng: không phải mọi rủi ro đáng xử lý đều xuất hiện với nhãn CVE nổi bật. Một thay đổi được xem là hardening vẫn có thể tạo khác biệt lớn trong vận hành nếu nó chặn được kiểu tiêu hao tài nguyên thực tế.
Với đội bảo mật, cách tiếp cận phù hợp là kết hợp quản lý CVE với theo dõi release note, changelog, thông tin từ nhóm nghiên cứu và kiểm thử hành vi dịch vụ. Với đội hạ tầng, bài học trực tiếp hơn là mọi bản vá thư viện nền tảng như OpenSSL cần đi kèm kế hoạch restart có kiểm soát, giám sát sau triển khai và xác nhận rằng tiến trình đang chạy đã nạp đúng phiên bản mới.
VNCyberS tổng hợp từ The Hacker News, Okta Red Team và OpenSSL
Tiếng Việt
English