Chèn header CRLF trong Netty HttpProxyHandler có thể thay đổi HTTP CONNECT request

Netty là một framework mạng bất đồng bộ, hướng sự kiện cho các ứng dụng mạng. Trước 4.2.13.Final và 4.1.133.Final, HttpProxyHandler của Netty tạo các yêu cầu HTTP CONNECT với việc kiểm tra header bị vô hiệu hóa rõ ràng. Phương thức newInitialMessage() tạo các header bằng DefaultHttpHeadersFactory.headersFactory().withValidation(false), sau đó thêm outboundHeaders do người dùng cung cấp mà không kiểm tra CRLF. Điều này cho phép kẻ tấn công có thể tác động đến các header gửi đi chèn các header HTTP tùy ý vào yêu cầu CONNECT được gửi tới máy chủ proxy. Lỗ hổng này được khắc phục trong 4.2.13.Final và 4.1.133.Final.

• io.netty:netty-handler-proxy trong nhánh 4.2 bị ảnh hưởng với >= 4.2.0.Alpha1, < 4.2.13.Final; advisory xác định 4.2.13.Final là bản đã sửa.
• io.netty:netty-handler-proxy trong nhánh 4.1 bị ảnh hưởng với < 4.1.133.Final; advisory xác định 4.1.133.Final là bản đã sửa.
• Đây là các ranh giới của upstream. Bản phân phối downstream có thể backport bản sửa, vì vậy cần đánh giá từng sản phẩm theo advisory hoặc erratum của vendor thay vì chỉ dựa vào chuỗi version của package. Các nhánh hoặc sản phẩm ngoài các ranh giới nêu trên chưa được phân loại trong mục này.

Lỗi nằm ở io.netty.handler.proxy.HttpProxyHandler, cụ thể là newInitialMessage(). Implementation tạo CONNECT request bằng DefaultHttpHeadersFactory.headersFactory().withValidation(false) rồi thêm outboundHeaders do ứng dụng cung cấp mà không kiểm tra CRLF. Nếu kẻ tấn công tác động được đến một giá trị header, các chuỗi CRLF có thể kết thúc dòng header ban đầu và chèn thêm HTTP header vào CONNECT request sau khi serialize. Vì vậy, đường tấn công đi từ input do ứng dụng kiểm soát sang request gửi tới proxy, không đòi hỏi kẻ tấn công kiểm soát internals của Netty. Bằng chứng từ các nguồn authoritative chưa xác định một entry point chung cho mọi ứng dụng, hành vi chính xác của từng proxy sau khi nhận header bị chèn, hoặc tác động vượt ra ngoài CONNECT exchange bị ảnh hưởng.

Việc khai thác có thể thực hiện từ xa khi ứng dụng có một luồng cho phép dữ liệu do kẻ tấn công kiểm soát ảnh hưởng đến outboundHeaders; theo đặc tính tấn công được cung cấp, không cần một privilege riêng trong Netty. Không xác định yêu cầu người dùng tương tác, nhưng ứng dụng phải thực sự sử dụng HttpProxyHandler và gửi CONNECT request qua proxy. Bản ghi được cung cấp đánh dấu public exploit là có, và advisory của Netty chứa tài liệu proof of concept. Bằng chứng đã xem không ghi nhận việc khai thác ngoài thực tế, campaign, hoặc nạn nhân cụ thể.

• Kết quả kỹ thuật trực tiếp là chèn HTTP header tùy ý vào proxy CONNECT request.
• Proxy có thể coi các header bị chèn là metadata hợp lệ, từ đó thay đổi quyết định về authorization, routing hoặc kiểm soát bảo mật khác.
• Red Hat nêu khả năng bypass kiểm soát bảo mật của proxy và các tấn công kiểu cache poisoning, nhưng đây là tác động phụ thuộc deployment, không phải kết quả chắc chắn.
• Bằng chứng đã xem không xác nhận code execution, rò rỉ dữ liệu trực tiếp hoặc gián đoạn dịch vụ chỉ từ lỗi này.

Khai thác thành công có thể làm thay đổi các header mà proxy nhận được trong quá trình thiết lập tunnel. Tùy policy của proxy và giá trị bị chèn, điều này có thể gây ra hành vi định tuyến hoặc xác thực bất thường, vượt cơ chế kiểm soát bảo mật của proxy, hoặc tạo ra các tác động kiểu cache poisoning. Bằng chứng hiện có xác nhận việc thao túng request/header, nhưng không khẳng định proxy hay ứng dụng chắc chắn bị chiếm quyền. Những deployment không cho phép kẻ tấn công tác động đến proxy header gửi đi chưa được chứng minh là có thể khai thác bằng lỗi này.

1. Nâng cấp io.netty:netty-handler-proxy lên 4.2.13.Final nếu dùng nhánh 4.2, hoặc 4.1.133.Final nếu dùng nhánh 4.1. Không dùng bản sửa của một nhánh để suy ra nhánh khác hoặc downstream build đã an toàn.
2. Nếu chưa thể nâng cấp ngay, phải kiểm tra nghiêm ngặt mọi giá trị do người dùng kiểm soát trước khi đưa vào outboundHeaders, đặc biệt để loại bỏ CRLF trước khi dữ liệu tới HttpProxyHandler. Nếu duy trì fork riêng, hãy bật lại header validation cho code path này hoặc validate từng outbound header trước khi thêm vào request.
3. Nếu chưa thể triển khai sanitization đầy đủ, hạn chế network access tới ứng dụng sử dụng HttpProxyHandler như một biện pháp defense in depth.
4. Kiểm tra lại dependency transitive và shaded, sau đó test proxy authentication và CONNECT behavior sau khi thay đổi. Với bản phân phối của vendor, áp dụng erratum tương ứng và xác minh component thực tế được đóng gói, vì bản sửa có thể được backport.

1. Lập inventory các dependency Maven trực tiếp, transitive và shaded có chứa io.netty:netty-handler-proxy, rồi đối chiếu component thực tế với hai ranh giới nhánh bị ảnh hưởng.
2. Tìm HttpProxyHandler, newInitialMessage(), outboundHeaders và withValidation(false) trong code và configuration. Truy vết xem request data, tenant data, proxy metadata hoặc user metadata có thể đi tới các giá trị này hay không.
3. Review cơ chế header validation hoặc sanitization của ứng dụng trước khi proxy request được serialize. Chỉ sự hiện diện của dependency không chứng minh code path dễ bị khai thác đang reachable.
4. Ở phía proxy, xem xét CONNECT request có header bất thường, trùng lặp hoặc mới xuất hiện, cùng các parsing anomaly liên quan CRLF. Đây chỉ là monitoring phòng ngừa, không phải IOC đã được xác nhận.
5. Sau khi remediation, xác minh artifact đã resolve hoặc erratum của vendor trong image/runtime đang deploy. Không thấy log proxy đáng ngờ không chứng minh deployment an toàn.