Một lỗ hổng OpenSSL mới được công bố, có tên gọi “HollowByte”, cho phép kẻ tấn công từ xa không cần xác thực gây ra điều kiện tấn công từ chối dịch vụ (DoS) chỉ với một payload độc hại nhỏ 11 byte.
Lỗ hổng này được phát hiện bởi Okta Red Team. Nó khai thác cách OpenSSL cấp phát bộ nhớ trước trong quá trình bắt tay TLS, buộc các máy chủ phải dự trữ các khối bộ nhớ lớn trước khi bất kỳ xác thực nào xảy ra.
Cơ chế khai thác và nguy cơ bảo mật của HollowByte
Mỗi quá trình bắt tay TLS bắt đầu bằng thông điệp ClientHello, được đóng gói trong một bản ghi mang header 4 byte khai báo kích thước của phần thân thông điệp đến.
Trong các phiên bản OpenSSL cũ hơn, thư viện cấp phát một bộ đệm nhận dựa hoàn toàn vào độ dài được khai báo bởi kẻ tấn công trước khi dữ liệu thực tế đến.
Khi một payload 11 byte được tạo đặc biệt đến, máy trạng thái TLS sẽ đọc header và kích hoạt chuỗi cấp phát không được xác thực sau:
ssl/record/rec_layer_s3.c:s3_read_bytes()
ssl/record/record.c:ssl_get_new_buffer()
ssl/record/record.c:ssl_alloc_buffer()
crypto/mem.c:CRYPTO_malloc()
crypto/mem.c:CRYPTO_realloc_clean()
crypto/mem.c:malloc()
Vì không có xác thực nào xảy ra ở giai đoạn này, một gói tin độc hại duy nhất có thể buộc malloc() cấp phát tới 131 KB dựa hoàn toàn vào tuyên bố của kẻ tấn công.
Luồng worker sau đó bị chặn vô thời hạn, chờ đợi dữ liệu không bao giờ đến.
Vấn đề phân mảnh bộ nhớ và tác động lâu dài
Các cuộc tấn công từ chối dịch vụ truyền thống như Slowloris dựa vào việc giữ các kết nối mở để làm cạn kiệt luồng máy chủ.
HollowByte làm trầm trọng thêm vấn đề này bằng một sự cố phân mảnh bộ nhớ bắt nguồn từ cách glibc quản lý bộ nhớ đã giải phóng.
Khi một kết nối tấn công bị ngắt, OpenSSL giải phóng bộ đệm, nhưng glibc không ngay lập tức trả lại các cấp phát nhỏ đến trung bình cho hệ điều hành; nó giữ lại chúng để có thể sử dụng lại.
Bằng cách khởi động các đợt kết nối với kích thước được khai báo ngẫu nhiên, kẻ tấn công ngăn trình cấp phát sử dụng lại các khối đã giải phóng này.
Điều này khiến kích thước bộ nhớ thực tế (RSS) của máy chủ tăng liên tục và vĩnh viễn, ngay cả sau khi kẻ tấn công ngắt kết nối.
Biện pháp khắc phục duy nhất là chấm dứt quy trình bị ảnh hưởng.
Phạm vi ảnh hưởng rộng lớn của lỗ hổng OpenSSL
Okta Red Team đã thực hiện kiểm thử trên các phiên bản OpenSSL chưa được vá chạy NGINX và tiết lộ những hậu quả nghiêm trọng.
Do OpenSSL là nền tảng của một phần lớn cơ sở hạ tầng internet, phạm vi ảnh hưởng của lỗ hổng OpenSSL này mở rộng đến các máy chủ web như Apache và NGINX.
Nó cũng ảnh hưởng đến các môi trường runtime ngôn ngữ bao gồm Node.js, Python, Ruby và PHP, cũng như các cơ sở dữ liệu như MySQL và PostgreSQL.
Điều này nhấn mạnh tầm quan trọng của việc giải quyết mọi lỗ hổng OpenSSL một cách kịp thời.
Giải pháp và cập nhật bản vá bảo mật
OpenSSL đã giải quyết vấn đề bằng cách chuyển sang tăng trưởng bộ đệm theo từng bước.
Giải pháp này đã được hợp nhất thông qua các pull request #30792, #30793 và #30794 trên GitHub của OpenSSL.
Thay vì tin tưởng hoàn toàn vào tuyên bố của header, OpenSSL hiện chỉ mở rộng bộ đệm khi các byte thực sự đến trên đường truyền.
Điều này có nghĩa là một yêu cầu rỗng sẽ không gây tốn kém gì cho máy chủ.
Bản sửa lỗi đã được tích hợp một cách lặng lẽ vào OpenSSL v4.0.1.
Các bản vá lỗi cũng được backport một cách lặng lẽ cho các phiên bản 3.6.3, 3.5.7, 3.4.6 và 3.0.21. Có thể tìm thấy chi tiết tại nguồn chính thức của OpenSSL: OpenSSL Source.
Tầm quan trọng của việc áp dụng bản vá dù không có CVE
Đáng chú ý, OpenSSL đã coi đây là một cải tiến tăng cường an ninh hơn là ban hành một cảnh báo CVE chính thức.
Đây là một mô hình đã được thấy trong các tiết lộ OpenSSL gần đây khác, nơi các vấn đề liên quan đến DoS được giải quyết mà không có chỉ định CVE cấp cao.
Vì HollowByte nhận được xử lý vá lỗi thầm lặng thay vì một CVE, nhiều tổ chức có thể không gắn cờ nó thông qua việc quét lỗ hổng OpenSSL tiêu chuẩn.
Tuy nhiên, do sự phổ biến của OpenSSL trên các máy chủ web, môi trường runtime và cơ sở dữ liệu, các nhóm bảo mật nên coi đây là một bản vá bảo mật ưu tiên, bất kể tình trạng CVE.
Việc không có CVE không làm giảm thiểu nguy cơ bảo mật mà lỗ hổng này gây ra.
Việc cập nhật kịp thời các phiên bản OpenSSL lên các phiên bản đã vá lỗi là điều tối quan trọng để bảo vệ hệ thống khỏi các tấn công từ chối dịch vụ tiềm ẩn và duy trì an toàn thông tin.
