Kiểm toán AI đối với FreeBSD

Kiểm toán FreeBSD bằng AI 15 lỗi kernel, bao gồm 3 lỗi RCE, 5 lỗi LPE và 1 lỗi thoát bhyve. Ngày 28/5/2026 10 1 Chia sẻ Kể từ khi chúng tôi bắt đầu chiến dịch tấn công Internet bằng AI, chúng tôi đã học được điều mà nhiều người trong số các bạn đã biết: Internet vận hành nhờ những người tình nguyện. Các dự án quan trọng đối với an ninh và văn hóa Internet được điều hành bởi những nhóm nhỏ, đôi khi chỉ là một người. OpenSSH, bảo vệ hầu hết mọi shell từ xa trên Internet, được duy trì bởi một nhóm nhỏ do một người Úc dẫn dắt (Chào Damien!). Chúng tôi cảm thấy mình nợ những người duy trì này một điều gì đó. Nếu không có Internet và phần mềm mã nguồn mở vận hành nó, chúng tôi sẽ không học được những gì đã học, không kết bạn được những người bạn đã kết, hoặc không có được sự nghiệp như ngày nay. Vì vậy, chúng tôi quyết định kết hợp các chuyên gia và AI của mình với các dự án mã nguồn mở cần sự giúp đỡ. FreeBSD là nơi chúng tôi bắt đầu. Cuối tháng 3, chúng tôi đã công bố lỗ hổng kernel từ xa đầu tiên của FreeBSD được hỗ trợ bởi AI. Đầu tháng này, chúng tôi đã báo cáo một CVE trong exeCVE. Chúng tôi cũng đã báo cáo 3 lỗi RCE trong một mô-đun ít được sử dụng. Thấy đội ngũ đang gặp khó khăn, chúng tôi nghĩ rằng mình nên cố gắng giúp đỡ nhiều hơn là chỉ thêm vào danh sách, và đã liên hệ với họ. Đội ngũ đã cho chúng tôi biết nên tập trung vào điều gì, và chúng tôi đã để AI hoạt động hết công suất. Trong vài tuần đầu tiên của công việc đó, cuộc kiểm toán đã phát hiện thêm nhiều lỗi: 5 lỗi leo thang đặc quyền cục bộ 1 lỗi thoát bhyve từ máy khách sang máy chủ một số lỗi tiết lộ bộ nhớ và DoS Tổng cộng, chúng tôi đã báo cáo 15 lỗi. Tất cả đều nằm trong kernel. Chúng tôi cũng đã chia sẻ kỹ năng kiểm toán mà chúng tôi đã sử dụng để tìm ra một số lỗi đó với đội ngũ. Bài viết này nói về cách chúng tôi đạt được điều đó. Những gì chúng tôi muốn đạt được Khi chúng tôi làm việc với đội ngũ FreeBSD, chúng tôi đã đồng ý về hai điều: Làm cho việc tìm lỗi trong FreeBSD trở nên khó khăn hơn. Giúp đội ngũ FreeBSD tìm, loại bỏ và ngăn chặn nhiều lỗi hơn sau khi chúng tôi không còn ở đây. Chúng tôi không cố gắng theo đuổi số lượng CVE hay số lượng lỗi. Chúng tôi chỉ muốn hữu ích cho những người điều hành dự án. Cách chúng tôi làm việc Các nhà bảo trì các dự án mã nguồn mở được sử dụng rộng rãi như FreeBSD đang phải đối mặt với vô số báo cáo, và sự chú ý của họ là nguồn tài nguyên đắt giá nhất trong toàn bộ hoạt động này. Quy tắc đầu tiên để trở nên hữu ích là không lãng phí nguồn tài nguyên đó. Một số điều chúng tôi đã thống nhất: Chỉ gửi các lỗi nghiêm trọng hoặc rất nghiêm trọng. Chúng tôi tập trung các báo cáo gửi đi vào những gì chúng tôi tin là các lỗ hổng nghiêm trọng hoặc rất nghiêm trọng. Đôi khi một lỗi mà chúng tôi cho là nghiêm trọng bị các nhà bảo trì hạ cấp sau khi kiểm tra kỹ hơn, và chúng tôi phần lớn tuân theo cách đánh giá của họ thay vì tranh cãi. Giữ báo cáo ngắn gọn. Mọi người đều thích một báo cáo ngắn gọn. Một dòng và một PoC (Proof of Concept - bằng chứng khái niệm) tốt hơn nhiều so với mười lăm trang phân tích dài dòng. Phần phân tích chuyên sâu có thể được gửi trong một báo cáo tiếp theo nếu có ai yêu cầu. Đề xuất các bản vá, nhưng không nhất quyết yêu cầu. Một số nhà bảo trì thích nhận các bản vá được đề xuất; một số khác thích tự viết bản sửa lỗi. Chúng tôi mặc định đính kèm một bản vá trong báo cáo, được ghi rõ là một đề xuất, để nhà bảo trì có thể sử dụng, sửa đổi hoặc bỏ qua mà không cần trao đổi qua lại. Dành thời gian với mọi người. Email và các phiếu theo dõi là cần thiết, nhưng một cuộc gọi video duy nhất ngay từ đầu có thể làm được nhiều điều cho mối quan hệ công việc hơn bất kỳ số lượng mẫu vấn đề được chuẩn bị kỹ lưỡng nào. Sau cuộc họp đầu tiên với nhóm FreeBSD, chúng tôi đã thiết lập một kênh liên lạc trực tiếp với họ, và nhiều lỗi mà chúng tôi đã báo cáo kể từ đó đã được khắc phục trong vài ngày. FreeBSD là sự hợp tác đầu tiên mà chúng tôi công khai viết về, nhưng không phải là duy nhất. Công việc tương tự đã được tiến hành với các dự án khác giúp duy trì hoạt động của Internet, và chúng tôi dự định chia sẻ thêm khi những nỗ lực đó trưởng thành. Warez Một bài đăng của MAD Bugs phải bao gồm một số bản phát hành warez, vì vậy hôm nay chúng tôi đang công bố các khai thác và bài viết cho ba trong số các LPE (Local Privilege Escalation - leo thang đặc quyền cục bộ): setcred (CVE-2026-45250): một lỗi sizeof một ký tự trong kern_setcred_copyin_supp_groups biến thành tràn bộ đệm ngăn xếp trong khung của user_setcred và sau đó là một shell root cục bộ. Chỉ FreeBSD 14.4 mới có thể bị khai thác, mặc dù cùng một lỗi nguồn có mặt trong 14.3 và 15.0. ptrace (CVE-2026-45253): ptrace(PT_SC_REMOTE) bỏ qua kiểm tra giới hạn trên số syscall được chuyển hướng, dẫn đến việc lập chỉ mục ngoài giới hạn vào bảng sysent mà chúng tôi liên kết thành LPE. procdesc (CVE-2026-45251): procdesc_free() giải phóng một cấu trúc procdesc với một pd_selinfo nhúng mà không làm trống các trình chờ thăm dò. Chúng tôi thu hồi khe cắm bằng các filedescent SCM_RIGHTS, kích hoạt hai TAILQ_REMOVEs cũ và có được các ghi con trỏ kernel tùy ý. Các khai thác và bài viết được viết bởi AI. Chúng tôi đã quyết định giữ nguyên văn bản AI, như một hiện vật lịch sử cho thấy nghiên cứu lỗ hổng AI trông như thế nào vào năm 2026. Mặt khác, các khai thác đều được chúng tôi xác minh và chúng hoạt động. Bằng cách công bố chúng, chúng tôi hy vọng nhiều người hơn có thể học hỏi từ các kỹ thuật này và mang lại nhiều sự giúp đỡ hơn cho FreeBSD. Các lỗi còn lại từ cuộc kiểm toán sẽ được phát hành khi nhóm FreeBSD phát hành các bản sửa lỗi. Đối với những độc giả tò mò, kho lưu trữ cũng chứa một vài khai thác bổ sung, chủ yếu được AI tạo ra từ các khuyến cáo công khai của FreeBSD được phát hành mà không có PoC hoạt động. Lời cảm ơn Gửi nhóm FreeBSD, vì đã hợp tác với chúng tôi và đã thực hiện công việc một cách nghiêm túc. Gửi OpenAI và Anthropic, vì các token. Và gửi tất cả các nhà bảo trì đã duy trì hoạt động của Internet với rất ít sự công nhận và rất ít nhân lực: xin cảm ơn. 10 1 Chia sẻ