F5 BIG-IP và BIG-IP Next tăng sử dụng bộ nhớ qua HTTP/2 có thể gây từ chối dịch vụ

Khi một HTTP/2 profile được cấu hình trên virtual server, các request chưa được tiết lộ có thể làm tăng mức sử dụng tài nguyên bộ nhớ.

Impact: Hiệu năng hệ thống có thể suy giảm cho tới khi tiến trình TMM bị buộc restart hoặc được restart thủ công. Lỗ hổng này cho phép attacker từ xa, không cần xác thực, gây suy giảm dịch vụ và có thể dẫn tới denial-of-service (DoS) trên hệ thống BIG-IP. Không có control plane exposure; đây chỉ là vấn đề thuộc data plane.

Note: Các phiên bản phần mềm đã đạt End of Technical Support (EoTS) không được đánh giá.

Bản ghi đánh dấu các triển khai sau là affected và có default_status là unknown:

• F5 BIG-IP, module All Modules: 21.1.0 với lessThan: 21.1.0.1; 21.0.0 với lessThan: 21.0.0.3; 17.5.0 với lessThan: 17.5.1.8; 17.1.0 với lessThan: 17.1.3.4.
• F5 BIG-IP Next for Kubernetes, component TMM: 2.3.0 với lessThan: 2.3.2; 2.0.0 với lessThan: 2.2.3.
• F5 BIG-IP Next SPK, component TMM: 1.9.0 với lessThan: *; 1.7.0 với lessThan: 1.7.18.
• F5 BIG-IP Next CNF, component TMM: 2.3.0 với lessThan: 2.3.2; 2.0.0 với lessThan: 2.2.3; 1.1.0 với lessThan: 1.4.3.

Phần mềm đã đạt End of Technical Support, hoặc EoTS, không được đánh giá. Do đó, trạng thái của các nhánh EoTS không được xác lập bởi bản ghi này.

F5 BIG-IP, BIG-IP Next for Kubernetes, BIG-IP Next SPK và BIG-IP Next CNF có lỗi quản lý tài nguyên khi một virtual server được cấu hình với HTTP/2 profile. Các request chưa được tiết lộ có thể làm tăng mức sử dụng bộ nhớ. Đây là lỗi thuộc CWE-770, trong đó tài nguyên có thể được cấp phát mà không có giới hạn hoặc cơ chế throttling phù hợp.

• Điều kiện khai thác là request phải đi tới dịch vụ có virtual server sử dụng HTTP/2 profile.
• Với BIG-IP, phạm vi affected được ghi nhận là All Modules; với các sản phẩm BIG-IP Next, component được nêu là TMM.
• Mức sử dụng bộ nhớ tăng có thể làm suy giảm hiệu năng hệ thống cho tới khi tiến trình TMM bị buộc restart hoặc được restart thủ công.

Nguồn công khai không mô tả chuỗi request cụ thể, đường đi cấp phát bộ nhớ hoặc chi tiết triển khai gây ra lỗi. Lỗi chỉ ảnh hưởng data plane theo mô tả hiện có, không cho thấy control plane bị phơi nhiễm.

Lỗ hổng có thể bị khai thác từ xa qua mạng bởi attacker không cần xác thực và không cần user interaction. Các thuộc tính khai thác được cung cấp cho thấy attack complexity thấp, nhưng loại request cụ thể cần gửi không được tiết lộ.

Bản ghi được cung cấp đánh dấu public_exploit là false. Trường known_exploited không có dữ liệu, vì vậy không thể kết luận rằng chưa từng có khai thác trong thực tế. Phần đánh giá exploitation được ghi nhận trong dữ liệu CISA ADP là none tại thời điểm đánh giá đó, nhưng kết quả này không thay thế việc kiểm tra telemetry nội bộ.

• Request HTTP/2 được xử lý bởi virtual server có cấu hình liên quan có thể làm tăng mức sử dụng bộ nhớ trong data plane.
• Hậu quả kỹ thuật được mô tả là suy giảm hiệu năng hệ thống cho tới khi tiến trình TMM bị buộc restart hoặc được restart thủ công.
• Attacker không cần xác thực và không cần tương tác người dùng; tác động chính là mất tính sẵn sàng, có thể dẫn tới denial of service trên BIG-IP.
• Bản ghi không mô tả việc đọc dữ liệu, sửa dữ liệu hoặc truy cập control plane. Chuỗi request và giới hạn thực tế của mức tiêu thụ bộ nhớ vẫn chưa được công khai.

• Các dịch vụ được cung cấp qua virtual server có HTTP/2 profile có thể bị suy giảm hiệu năng hoặc gián đoạn khi mức sử dụng bộ nhớ tăng.
• Tình trạng có thể kéo dài tới khi tiến trình TMM được buộc restart hoặc restart thủ công, tạo ra nhu cầu can thiệp vận hành và nguy cơ gián đoạn lưu lượng.
• Tác động được mô tả là availability và denial of service trên hệ thống BIG-IP; không có tác động confidentiality hoặc integrity nào được ghi nhận trong bản ghi.
• Không có control plane exposure theo mô tả hiện có, nên bằng chứng cung cấp không cho thấy việc chiếm quyền quản trị hoặc xâm phạm management plane.

1. Áp dụng bản sửa theo từng nhánh BIG-IP: chuyển 21.1.0 sang 21.1.0.1, 21.0.0 sang 21.0.0.3, 17.5.0 sang 17.5.1.8, và 17.1.0 sang 17.1.3.4.
2. Cập nhật BIG-IP Next for Kubernetes: chuyển 2.3.0 sang 2.3.2 hoặc chuyển nhánh 2.0.0 sang 2.2.3, theo nhánh đang triển khai.
3. Cập nhật BIG-IP Next CNF: chuyển 2.3.0 sang 2.3.2, 2.0.0 sang 2.2.3, hoặc 1.1.0 sang 1.4.3, theo nhánh đang triển khai.
4. Cập nhật BIG-IP Next SPK: chuyển 1.7.0 sang 1.7.18. Với mục 1.9.0 có lessThan: *, bản ghi không cung cấp ranh giới fixed cụ thể; cần lấy hướng dẫn release đã sửa từ F5 trước khi xác nhận nhánh này đã được khắc phục.
5. Bản ghi cho biết có patch, nhưng không cung cấp workaround của vendor. Không nên coi việc restart TMM là remediation; đó chỉ là hành động khôi phục dịch vụ sau khi xảy ra suy giảm.
6. Sau khi cập nhật, xác minh lại inventory, các virtual server có HTTP/2 profile và trạng thái TMM trên từng nhánh. Các phiên bản EoTS không được đánh giá, nên không nên suy ra trạng thái an toàn cho chúng.

1. Lập inventory các triển khai F5 BIG-IP và BIG-IP Next, xác định sản phẩm, nhánh release và component TMM đang sử dụng.
2. Kiểm tra các virtual server có cấu hình HTTP/2 profile, vì đây là điều kiện được mô tả trực tiếp trong bản ghi.
3. Theo dõi mức sử dụng bộ nhớ, suy giảm hiệu năng và các lần TMM restart hoặc phải restart thủ công trên các hệ thống có cấu hình liên quan.
4. Đối chiếu các phiên bản đang chạy với các ranh giới affected và bản sửa lỗi trong phần affected_summary, đồng thời ưu tiên kiểm tra các nhánh có default status unknown.

Bản ghi không cung cấp IOC, mẫu request, log signature hoặc event cụ thể. Việc không thấy dấu hiệu trong log không chứng minh hệ thống an toàn; giám sát bộ nhớ và hành vi restart chỉ là biện pháp phát hiện và cảnh báo bổ sung.