Vượt giới hạn flow control HTTP/2 do hoàn trả hai lần trong Go standard library net/http

Máy chủ HTTP/2 có thể hoàn trả flow control ở cấp kết nối hai lần cho cùng một dữ liệu: một lần khi client reset một stream (hoàn trả phần dữ liệu đã gửi nhưng chưa được đọc của stream), và một lần nữa khi request handler đọc dữ liệu đã được buffer. Client độc hại có thể khai thác điều này để vượt qua giới hạn flow control ở cấp kết nối đã cấu hình (MaxReceiveBufferPerConnection). Tổng dữ liệu được buffer vẫn bị giới hạn bởi giới hạn số stream đồng thời và flow control ở cấp stream.

• net/http thuộc Go standard library: bị ảnh hưởng với dải semver từ 0 đến trước 1.26.9. Bản sửa cho nhánh này được phát hành trong 1.26.9. • net/http/internal/http2 thuộc Go standard library: bị ảnh hưởng từ 1.27.0-0 đến trước 1.27.2. Bản sửa cho nhánh này được phát hành trong 1.27.2. • golang.org/x/net/http2: bị ảnh hưởng với dải semver từ 0 đến trước 0.60.0. Bản sửa tương ứng là v0.60.0.

Các mục trên có default_status là unaffected trong bản ghi. Trạng thái của những nhánh song song hoặc nhánh không được liệt kê không nên được suy ra chỉ từ việc một nhánh khác đã có bản sửa.

Go standard library net/http, net/http/internal/http2 và golang.org/x/net/http2 quản lý flow control ở cấp kết nối và cấp stream cho HTTP/2. Khi client reset một stream, server hoàn trả credit flow control ở cấp kết nối cho phần dữ liệu đã gửi nhưng chưa được đọc. Nếu request handler sau đó đọc phần dữ liệu đã buffer, cùng lượng dữ liệu có thể được hoàn trả lần thứ hai. Đây là biểu hiện của CWE-675, trong đó một tài nguyên bị thao tác nhiều lần trong một ngữ cảnh vốn chỉ cho phép một lần xử lý.

Khai thác yêu cầu client độc hại kết nối đến HTTP/2 server, tạo tình huống stream bị reset trong khi dữ liệu vẫn được buffer để handler đọc. Việc hoàn trả hai lần có thể vượt qua giới hạn MaxReceiveBufferPerConnection. Tổng dữ liệu được buffer vẫn bị giới hạn bởi concurrent stream limit và stream-level flow control, vì vậy bằng chứng hiện có không cho thấy việc sử dụng bộ nhớ là không bị giới hạn. Go đã thay đổi hành vi để chỉ hoàn trả flow control của stream bị reset sau khi request handler hoàn tất.

Lỗi có thể bị khai thác qua mạng bởi client HTTP/2 độc hại và không yêu cầu quyền truy cập đặc biệt hoặc tương tác của người dùng. Điều kiện khai thác là server phải cung cấp HTTP/2 và xử lý dữ liệu stream theo đường đi trong đó client reset stream trước khi handler đọc hết dữ liệu đã buffer. Bản ghi mô tả độ phức tạp khai thác là thấp, nhưng tổng tác động vẫn bị giới hạn bởi concurrent stream limit và stream-level flow control. Bản ghi cung cấp đặt public_exploit là false và known_exploited là null; các trạng thái này không chứng minh rằng việc khai thác là không thể xảy ra.

Kết quả kỹ thuật chính là bộ đếm credit flow control ở cấp kết nối bị tăng sai cho cùng một dữ liệu, cho phép client vượt qua ngưỡng MaxReceiveBufferPerConnection. Điều này có thể làm server giữ lại nhiều dữ liệu hơn dự kiến, gây áp lực bộ nhớ, giảm khả năng xử lý request hoặc dẫn đến gián đoạn dịch vụ. Lỗi không yêu cầu quyền đặc biệt và tác động được thực hiện trên dịch vụ HTTP/2 đang xử lý kết nối của attacker. Concurrent stream limit và stream-level flow control vẫn giới hạn tổng dữ liệu được buffer, do đó bằng chứng hiện có không hỗ trợ kết luận rằng một kết nối đơn lẻ có thể tạo mức tiêu thụ tài nguyên không giới hạn. Bản ghi không thiết lập tác động vượt ra ngoài server hoặc việc tiết lộ, sửa đổi dữ liệu.

• Tài nguyên và khả dụng: Server HTTP/2 có thể buffer nhiều dữ liệu hơn mức connection-level flow control dự kiến, làm tăng mức sử dụng bộ nhớ và nguy cơ suy giảm hiệu năng hoặc từ chối dịch vụ. • Phạm vi tiếp xúc: Các dịch vụ nhận kết nối HTTP/2 từ client không tin cậy cần được ưu tiên kiểm tra, đặc biệt khi handler đọc request body sau các sự kiện reset stream. • Giới hạn tác động: Concurrent stream limit và stream-level flow control vẫn giới hạn tổng dữ liệu được buffer, nên bằng chứng hiện có không cho thấy mức tiêu thụ tài nguyên là vô hạn. • Dữ liệu và quyền: Bằng chứng cung cấp tập trung vào việc bypass giới hạn tài nguyên; không mô tả việc tiết lộ dữ liệu hoặc thay đổi dữ liệu.

1. Nâng Go standard library của nhánh 1.26 lên 1.26.9, hoặc của nhánh 1.27 lên 1.27.2, sau đó build và triển khai lại các dịch vụ HTTP/2 liên quan.
2. Nếu ứng dụng phụ thuộc trực tiếp vào golang.org/x/net/http2, cập nhật dependency lên v0.60.0.
3. Kiểm tra cả dependency trực tiếp và dependency được bundle trong binary hoặc container. Chỉ thay đổi module trong source mà không rebuild và restart dịch vụ không xác nhận được bản sửa đã có hiệu lực.
4. Xác minh riêng từng nhánh triển khai với các ranh giới trong affected_summary; không mở rộng kết luận của một bản sửa sang nhánh khác nếu chưa có bằng chứng.
5. Bản ghi không cung cấp workaround độc lập đã được xác nhận. Các giới hạn stream hiện có chỉ làm giảm phạm vi tác động còn lại và không thay thế cho việc cập nhật bản sửa.

1. Kiểm kê các binary và dịch vụ Go đang chạy HTTP/2 server, đồng thời xác định chúng sử dụng net/http, net/http/internal/http2 hay module golang.org/x/net/http2 nào.
2. Đối chiếu phiên bản runtime, module dependency và image build với các nhánh bị ảnh hưởng và các bản sửa lỗi được liệt kê trong affected_summary.
3. Rà soát các handler có đọc request body hoặc dữ liệu stream sau khi client đã reset stream, vì đây là điều kiện liên quan trực tiếp đến cơ chế lỗi.
4. Kiểm tra telemetry HTTP/2 hiện có, nếu được ghi nhận, để tìm các đợt stream reset bất thường đi kèm với mức tăng bộ nhớ hoặc số lượng request body đang buffer. Đây là biện pháp theo dõi phòng ngừa, không phải IOC đã được xác nhận.
5. Không thấy các mẫu trên không chứng minh hệ thống an toàn; xác minh phiên bản triển khai vẫn là kiểm tra quyết định.