Lũ `CONTINUATION` HTTP/2: Chi tiết kỹ thuật

Lỗ hổng Flood CONTINUATION của HTTP/2: chi tiết kỹ thuật

• Flood CONTINUATION là một nhóm lỗ hổng được phát hiện trong nhiều triển khai giao thức HTTP/2, đặt ra mối đe dọa nghiêm trọng hơn cả cuộc tấn công Rapid Reset.
• Hậu quả của cuộc tấn công rất đa dạng, từ làm sập máy chủ đến suy giảm hiệu năng, và các yêu cầu tấn công không xuất hiện trong nhật ký truy cập HTTP.

Lời mở đầu

• Vào tháng 10 năm 2023, tác giả biết đến cuộc tấn công HTTP/2 Rapid Reset và quyết định bắt đầu nghiên cứu HTTP/2 từ góc độ phân tích bảo mật.

Giới thiệu ngắn gọn về HTTP/2

• Khác biệt chính giữa HTTP/1.1 và HTTP/2 là giao thức sau là giao thức nhị phân, trong đó client và server trao đổi frame thay vì các dòng văn bản.
• Cần giải thích về frame HEADERS và frame CONTINUATION.

Frame HEADERS

• Frame HEADERS được dùng để truyền các header HTTP của request và response, đồng thời nén dữ liệu header bằng thuật toán mã hóa HPACK.
• Frame có thể được đặt các cờ như END_HEADERS và END_STREAM.

Frame CONTINUATION

• Frame CONTINUATION rất giống với frame HEADERS, nhưng chỉ có cờ END_HEADERS; khi cờ này được đặt, điều đó có nghĩa là luồng header đã kết thúc.

Lỗ hổng Flood CONTINUATION

• Nếu client bắt đầu một luồng HTTP/2 mới rồi gửi các frame HEADERS và CONTINUATION nhưng không bao giờ đặt cờ END_HEADERS, server sẽ phải phân tích và lưu trong bộ nhớ một luồng header vô hạn.
• Trong HTTP/1.1, giới hạn kích thước header và timeout cho request/header bảo vệ khỏi header vô hạn, nhưng trên nhiều máy chủ HTTP/2, các biện pháp bảo vệ này bị thiếu hoặc được triển khai sai.

Tiêu tốn CPU: trường hợp Golang

• Golang là một ví dụ về việc tiêu tốn CPU do Flood CONTINUATION, khi nó sử dụng một lớp trừu tượng tên là http2MetaHeadersFrame để xử lý các frame HEADERS và CONTINUATION.
• Bộ giải mã HPACK được cấu hình để ngừng phát ra header khi chạm tới giới hạn kích thước header, nhưng nếu không có cờ END_HEADERS, hàm sẽ không trả về mà tiếp tục giải mã header.

Cạn kiệt bộ nhớ

• Cạn kiệt bộ nhớ là một trong những trường hợp nghiêm trọng nhất, vì có những triển khai không giới hạn kích thước danh sách header được xây dựng bằng các frame CONTINUATION.
• Với các triển khai không có timeout cho header, chỉ một kết nối HTTP/2 đơn lẻ cũng có thể làm sập server.

Có thể đạt được va chạm assertion: Node.js (trường hợp đặc biệt)

• Node.js xử lý đúng luồng vô hạn của các frame CONTINUATION, nhưng lại phát sinh lỗi race condition khi kết nối bị ngắt giữa chừng trong lúc đang xử lý luồng header.
• Node.js theo dõi việc cấp phát bộ nhớ trong destructor của Http2Session, và khi kết nối bị ngắt, giá trị current_nghttp2_memory_ được cập nhật đồng thời, có thể dẫn đến crash.

So sánh với các lỗ hổng HTTP/2 trước đây

• Trước đây đã có nhiều lỗ hổng HTTP/2 được báo cáo, và Flood CONTINUATION hoạt động theo cách khác với các lỗ hổng trước đó.
• Flood CONTINUATION không gửi các header rỗng, mà thay vào đó gửi rất nhiều header tùy ý cho đến giới hạn kích thước frame do server thiết lập.

Ghi chú cuối cùng

• Lưu lượng HTTP/2 chiếm khoảng 60% toàn bộ lưu lượng HTTP do con người tạo ra, và xét tới tầm quan trọng của các dự án bị ảnh hưởng, một phần đáng kể của Internet đã bị tác động bởi một lỗ hổng có thể bị khai thác dễ dàng.
• Nếu lỗ hổng này đã bị khai thác ngoài thực tế, các quản trị viên máy chủ hẳn sẽ rất khó debug nếu không có kiến thức phù hợp về HTTP/2.

Ý kiến của GN⁺

• Lỗ hổng này có thể làm suy giảm nghiêm trọng tính sẵn sàng của server, đặc biệt vì nó không được ghi lại trong log nên rất khó theo dõi và ứng phó.
• Quản trị viên máy chủ cần thường xuyên áp dụng các bản cập nhật bảo mật và sử dụng công cụ phân tích lưu lượng để phát hiện các mẫu bất thường.
• Những lỗ hổng như vậy là lời cảnh báo cho cộng đồng an ninh mạng, đồng thời nhấn mạnh tầm quan trọng của việc thiết kế và triển khai giao thức an toàn hơn.
• Ở góc nhìn phản biện, lỗ hổng này phơi bày khiếm khuyết thiết kế nền tảng của một giao thức được sử dụng rộng rãi, từ đó đặt ra vấn đề về độ tin cậy của hạ tầng cơ bản của Internet.
• Nếu không phải là chuyên gia có kiến thức trong lĩnh vực liên quan, việc hiểu và ứng phó với các lỗ hổng phức tạp như thế này có thể sẽ khó khăn, vì vậy cần nâng cao giáo dục và nhận thức về bảo mật.

[GN⁺]

Ý kiến trên Hacker News

• Vấn đề này gần đây đã được khắc phục trong Bandit

  • Trải nghiệm cá nhân cho biết cùng một vấn đề đã được xử lý trong Bandit cách đây một tháng.
  • Cung cấp vị trí mã cụ thể thông qua liên kết.
  • Từ góc nhìn của người triển khai, vấn đề này rất rõ ràng, và từng nghĩ rằng các implementation khác cũng đã có biện pháp phòng vệ.
  • Tuy nhiên, sau khi kiểm tra hàng chục implementation, ngay cả các máy chủ HTTP/2 lớn cũng không có cơ chế bảo vệ này hoặc triển khai sai.

• Chỉ trích văn hóa phát triển

  • Chỉ ra rằng vấn đề nằm ở văn hóa khi các lập trình viên đã quá quen với việc mọi thứ tự động mở rộng động, nên không nghĩ đến việc một thứ có thể lớn đến mức nào.
  • Vấn đề này không chỉ giới hạn ở HTTP/2, nhưng độ phức tạp của HTTP/2 có thể khiến nó tệ hơn.
  • Trong thời HTTP/1.x trước đây, khi dùng các ngôn ngữ như C, người ta phải liên tục chú ý quản lý độ dài buffer, và không có chuyện mở rộng cấp phát header request vô hạn.

• Danh sách máy chủ/reverse proxy không bị ảnh hưởng

  • Danh sách web server và reverse proxy không bị ảnh hưởng đã được nhắc đến trong bài viết trước.
  • Nginx, Jetty, HAProxy, NetScaler, Varnish không bị ảnh hưởng.

• Suy nghĩ về độ an toàn của HTTP/1.1

  • Đề cập rằng trang của chúng tôi đã được chú ý suốt cả ngày.
  • Đặt câu hỏi liệu với lưu lượng thấp, việc dùng HTTP/1.1 có an toàn hơn không.

• Lời khen dành cho tác giả

  • Khen tác giả vì tiếp cận vấn đề với góc nhìn rộng, báo cáo có trách nhiệm những gì đã phát hiện, và chia sẻ theo cách dễ đọc.

• Nhắc đến Slowloris v2

  • Đùa rằng nếu gây ra vấn đề này một cách chậm rãi thì có thể gọi nó là 'slowloris v2'.

• Nhắc đến lỗi chính tả

  • Thấy thú vị với lỗi chính tả 'serveral retries'.

• Góc nhìn phê phán về HTTP/2

  • Chỉ trích việc HTTP/2 bị đẩy vào vai trò tầng truyền tải cho các "nâng cấp" đối với giao thức tầng ứng dụng.