Lỗi kiểm tra độ dài ND gây vòng lặp vô hạn trong slaacd và rad của OpenBSD

Trong OpenBSD đến và bao gồm 7.8, các daemon slaacd và rad gặp vòng lặp vô hạn khi nhận một tùy chọn Neighbor Discovery (ND) ICMPv6 được tạo thủ công (qua mạng cục bộ) có độ dài bằng 0, do có biểu thức "nd_opt_len * 8 - 2" nhưng không kiểm tra trước xem nd_opt_len có bằng 0 hay không.

Bản ghi chuẩn hóa xác định các triển khai OpenBSD sau là bị ảnh hưởng:

• OpenBSD từ 0 đến và bao gồm 7.8, theo kiểu phiên bản tùy biến của bản ghi.
• Thành phần liên quan là các daemon slaacd và rad; trạng thái mặc định bên ngoài phạm vi bị ảnh hưởng được ghi là unaffected.
• OpenBSD cung cấp bản sửa cho nhánh 7.7 trong errata 035_v6daemons và cho nhánh 7.8 trong errata 029_v6daemons.

Bằng chứng được kiểm tra không xác định một bản sửa nhánh cụ thể cho các bản phát hành cũ hơn 7.7, và không nên suy luận trạng thái của các nhánh song song hoặc mới hơn từ việc có bản sửa cho một nhánh khác.

Các daemon slaacd và rad tự phân tích các tùy chọn ICMPv6 Neighbor Discovery nhận được từ mạng cục bộ. Khi trường độ dài tùy chọn nd_opt_len bằng 0, mã thực hiện biểu thức nd_opt_len * 8 - 2 mà không kiểm tra giá trị 0 trước đó. Giá trị không hợp lệ này có thể khiến logic cập nhật độ dài và vị trí phân tích không tiến triển, dẫn đến vòng lặp vô hạn trong quá trình xử lý gói tin. Bản sửa trong sbin/slaacd/engine.c bổ sung kiểm tra trong parse_ra và debug_log_ra; bản sửa trong usr.sbin/rad/engine.c bổ sung kiểm tra trong parse_rs. Điều kiện khai thác là kẻ tấn công phải gửi được gói ND được tạo thủ công qua cùng mạng cục bộ hoặc mạng lân cận; bản ghi không cho thấy khả năng đọc dữ liệu, sửa đổi dữ liệu, thực thi mã hoặc leo thang đặc quyền. Lỗi thuộc nhóm kiểm tra không đúng giá trị số lượng đầu vào và biểu hiện thành vòng lặp không có lối thoát.

Lỗi có thể được kích hoạt từ mạng lân cận hoặc mạng cục bộ, không yêu cầu xác thực, không yêu cầu tương tác của người dùng và được đánh giá là có độ phức tạp thấp trong bản ghi chuẩn hóa. Trình kích hoạt là một tùy chọn ICMPv6 ND có trường độ dài bằng 0 được gửi đến daemon bị ảnh hưởng. Bản ghi chuẩn hóa không đánh dấu lỗi là đang bị khai thác và đặt trạng thái public exploit là false; tuy nhiên, trạng thái đó không chứng minh rằng chưa từng có hoạt động khai thác. Nghiên cứu cũng tìm thấy một trang GitHub tự nhận có proof of concept, nhưng trang đó không được coi là bằng chứng xác nhận exploit công khai trong mục này. Không có bằng chứng được xác nhận về khai thác từ Internet ngoài phạm vi mạng lân cận.

Tác động trực tiếp là làm daemon bị ảnh hưởng mắc trong vòng lặp vô hạn khi xử lý một tùy chọn ND không hợp lệ. Kết quả có thể là mất tính sẵn sàng của slaacd, rad hoặc chức năng mạng mà daemon đó đảm nhiệm, với phạm vi ban đầu bị giới hạn ở các hệ thống nhận được gói từ mạng lân cận. Điều kiện này không yêu cầu đặc quyền hay xác thực và không cần người dùng tương tác. Bản ghi không cho thấy thay đổi phạm vi đặc quyền, tiết lộ dữ liệu, sửa đổi dữ liệu, thực thi mã hoặc leo thang đặc quyền. Mức độ gián đoạn thực tế phụ thuộc vào daemon đang bật, interface nhận lưu lượng và khả năng khôi phục dịch vụ của hệ thống.

Một gói tin độc hại từ mạng lân cận có thể làm daemon xử lý ND ngừng tiến triển và không tiếp tục xử lý bình thường các gói tin liên quan. Điều này có khả năng làm gián đoạn các chức năng IPv6 do slaacd cung cấp, hoặc làm suy giảm dịch vụ quảng bá Router Advertisement do rad cung cấp. Hệ quả vận hành có thể gồm mất hoặc chậm cấu hình địa chỉ IPv6, gián đoạn kết nối IPv6 hoặc cần can thiệp để khôi phục daemon. Bằng chứng hiện có chỉ hỗ trợ tác động đến tính sẵn sàng; không có bằng chứng cho thấy lỗi làm lộ dữ liệu, sửa đổi dữ liệu hoặc chiếm quyền hệ thống.

1. Áp dụng bản sửa chính thức của OpenBSD cho đúng nhánh đang sử dụng: errata 035_v6daemons cho OpenBSD 7.7 hoặc errata 029_v6daemons cho OpenBSD 7.8. Các bản sửa này bổ sung kiểm tra độ dài bằng 0 trước khi thực hiện phép tính độ dài tùy chọn.
2. Nếu áp dụng source patch, rebuild và cài đặt lại cả slaacd và rad sau khi patch sbin/slaacd/engine.c và usr.sbin/rad/engine.c. Chỉ áp dụng patch là chưa đủ nếu binary đang chạy chưa được xây dựng và cài đặt lại.
3. Với các bản phát hành cũ hơn 7.7, lấy bản sửa tương ứng từ OpenBSD hoặc nhánh stable của nhà cung cấp; bằng chứng được kiểm tra ở đây không cung cấp số errata cố định cho các nhánh đó.
4. Trong thời gian chờ cập nhật, giảm khả năng các thiết bị không tin cậy gửi lưu lượng ICMPv6 ND đến các interface xử lý slaacd hoặc rad nếu kiến trúc mạng cho phép. Đây là biện pháp giảm phơi nhiễm mang tính phòng ngừa, không phải một workaround cụ thể được OpenBSD xác nhận.
5. Sau cập nhật, xác minh binary của cả hai daemon đã được thay thế, dịch vụ hoạt động bình thường và các interface tiếp tục xử lý Router Advertisement hoặc Router Solicitation theo thiết kế.

1. Kiểm kê các máy OpenBSD đang chạy hoặc bật slaacd và rad, đặc biệt trên các interface nhận Router Advertisement hoặc Router Solicitation từ mạng không hoàn toàn tin cậy.
2. Xác nhận bản vá nhánh tương ứng đã được áp dụng và các binary slaacd và rad đã được rebuild, cài đặt theo hướng dẫn của OpenBSD.
3. Nếu xây dựng từ source, kiểm tra sbin/slaacd/engine.c để xác nhận parse_ra và debug_log_ra xử lý nd_opt_len == 0 trước phép tính nd_opt_len * 8 - 2, đồng thời kiểm tra usr.sbin/rad/engine.c trong parse_rs.
4. Rà soát packet capture hoặc thiết bị giám sát trên mạng cục bộ để tìm ICMPv6 Neighbor Discovery có tùy chọn với trường độ dài bằng 0. Đây là dấu hiệu liên quan trực tiếp đến điều kiện lỗi, không phải IOC được OpenBSD công bố.
5. Theo dõi việc daemon bị treo, tiêu thụ CPU bất thường hoặc ngừng xử lý các hoạt động ND sau khi nhận gói bất thường. Việc không thấy các dấu hiệu này không chứng minh hệ thống đã an toàn.