- Chia sẻ trải nghiệm sử dụng mô hình OpenAI o3 để phát hiện một lỗ hổng 0-day từ xa (CVE-2025-37899) trong triển khai SMB của nhân Linux
- Trong quá trình benchmark năng lực phân tích của LLM trên mã ksmbd, tác giả đã so sánh hiệu năng của LLM dựa trên một lỗ hổng đã được tìm thấy thủ công trước đó
- Quá trình phát hiện lỗ hổng được thiết kế theo hướng xây dựng ngữ cảnh theo từng hàm và cung cấp prompt phù hợp để o3 có thể nhận diện vấn đề
- Kết quả thử nghiệm cho thấy o3 phát hiện lỗ hổng với độ chính xác cao hơn 2–3 lần so với các LLM trước đó, đồng thời tự động tìm ra một dạng lỗi use-after-free mới
- Các LLM, đặc biệt là những mô hình mới như o3, đang thể hiện mức độ linh hoạt và sáng tạo tương tự con người trong kiểm toán mã và nghiên cứu lỗ hổng, khiến giá trị ứng dụng thực tiễn ngày càng cao
Giới thiệu
Bài viết này giới thiệu cách sử dụng mô hình o3 của OpenAI để phát hiện một lỗ hổng 0-day từ xa trong triển khai SMB của nhân Linux (ksmbd). Thí nghiệm được thực hiện chỉ với API o3, không dùng framework hay công cụ bổ sung nào. ksmbd là máy chủ triển khai giao thức SMB3 trong nhân Linux, phụ trách chia sẻ tệp qua mạng. Từ một đợt kiểm toán lỗ hổng được thực hiện để tạm nghỉ khỏi công việc phát triển liên quan đến LLM, tác giả đã benchmark xem o3 thực sự tìm lỗi tốt đến mức nào. Ở đây, trọng tâm đặc biệt là lỗ hổng zero-day CVE-2025-37899 do o3 phát hiện.
Lỗ hổng này là một vấn đề use-after-free xảy ra trong quá trình xử lý lệnh SMB logoff. Việc nhận ra nó đòi hỏi phải hiểu các kết nối đồng thời tới máy chủ và cách nhiều luồng chia sẻ một đối tượng cụ thể. o3 đã phát hiện lỗ hổng bằng cách nắm bắt các vấn đề đồng thời và sai sót trong quản lý đối tượng trong đúng ngữ cảnh. Đây là trường hợp công khai đầu tiên cho thấy LLM phát hiện được loại lỗ hổng như vậy.
Thông điệp chính là o3 cho thấy năng lực phân tích mã và suy luận logic của LLM đã tiến thêm một bước lớn, và các nhà nghiên cứu lỗ hổng nhất định phải chú ý đến xu hướng này. LLM không thay thế chuyên gia, nhưng đã phát triển thành công cụ có thể nâng cao mạnh mẽ năng suất và hiệu quả của chuyên gia. Với các đoạn mã dưới 10.000 dòng, o3 có thể hỗ trợ thực chất trong việc phát hiện và xử lý phần lớn vấn đề.
Benchmark o3 bằng CVE-2025-37778
Bối cảnh và mục đích benchmark
Trước tiên, tác giả đánh giá khả năng phát hiện lỗ hổng của o3 dựa trên CVE-2025-37778, một lỗ hổng do chính tác giả tìm thấy thủ công trước đó (sau đây gọi là lỗ hổng xác thực kerberos). Đây là vấn đề use-after-free xảy ra trong quá trình xác thực phía client khi trạng thái phiên thỏa mãn một số điều kiện nhất định.
- Giải phóng đối tượng người dùng khỏi bộ nhớ khi trạng thái phiên là
SMB2_SESSION_VALID - Sau đó nếu xác thực thất bại, đối tượng người dùng không được khởi tạo lại, và vẫn có thể bị truy cập trong trạng thái đó, dẫn tới use-after-free
- Để hiểu toàn bộ đường đi liên quan cần lần theo khoảng 3.300 dòng mã, nên đây là một bài benchmark có độ khó vừa phải
Xây dựng ngữ cảnh phân tích
Trong thí nghiệm, tác giả xây dựng cẩn thận ngữ cảnh (vùng mã) được đưa cho LLM theo góc nhìn của một hệ thống phát hiện lỗ hổng tự động thực tế. Với từng đơn vị handler lệnh SMB, các hàm chính và hàm con được đưa vào tới độ sâu gọi hàm 3 cấp, để cung cấp toàn bộ phần mã có liên hệ logic (tổng cộng 3,3k LoC, khoảng 27k token). Để có kết quả đáng tin cậy, cũng cần đưa vào các hàm liên quan như phân tích dữ liệu, phân nhánh yêu cầu và ngắt kết nối.
Prompt cụ thể và tài liệu đầu vào được dùng có thể xem trong kho Github liên quan. LLM được cung cấp các điều kiện sau:
- Chỉ thị rõ ràng phải phát hiện lỗ hổng use-after-free
- Giải thích ngắn gọn cấu trúc cơ bản và threat model của ksmbd
- Dùng prompt định hướng để giảm false positive
Các truy vấn thực tế được chạy lặp lại bằng công cụ dòng lệnh llm để thu thập kết quả thử nghiệm (N=100).
Kết quả benchmark
- o3: trong 100 lần chạy, phát hiện lỗ hổng xác thực kerberos 8 lần, bỏ sót 66 lần, và báo cáo false positive 28 lần
- Claude Sonnet 3.7: chỉ phát hiện 3 lần
- Claude Sonnet 3.5: thất bại trong cả 100 lần
Kết quả là o3 đạt độ chính xác cao hơn 2–3 lần so với các LLM trước đó. Ngoài ra, đầu ra thực tế của o3 ngắn gọn như một báo cáo tóm tắt do nhà nghiên cứu bảo mật con người viết. Trong khi đó, kết quả của Sonnet 3.7 mang cảm giác gần với nhật ký thao tác tập trung vào quá trình, với cả ưu và nhược điểm.
Phát hiện 0-day thực tế bằng o3 (CVE-2025-37899)
Thử nghiệm trong môi trường nhập lượng mã lớn
Ngoài lỗ hổng kerberos, tác giả còn thử để o3 phát hiện lỗ hổng trên toàn bộ handler lệnh SMB. Toàn bộ phần handler cùng mã kết nối/ngắt kết nối, khoảng 9.000 dòng, được đưa vào; tổng cộng khoảng 12k LoC (khoảng 100.000 token) trong một lần nhập. Khi chạy lặp lại 100 lần, lỗ hổng xác thực kerberos chỉ được phát hiện đúng 1 lần, cho thấy hiệu năng suy giảm rõ rệt, nhưng mục tiêu chính là kiểm nghiệm khả năng ứng dụng LLM trên phạm vi mã rộng hơn.
Lỗ hổng mới được phát hiện trong thí nghiệm này
Trong quá trình đó, o3 đã phát hiện thêm một lỗi use-after-free mới ngoài lỗi xác thực kerberos. Đó là một vấn đề đồng thời trong handler logoff của phiên: trong trạng thái có hai kết nối đồng thời, hai luồng cùng chia sẻ/truy cập đối tượng user của phiên, và sau khi một luồng giải phóng đối tượng này thì luồng còn lại vẫn có thể tiếp tục tham chiếu tới nó.
Tóm tắt báo cáo lỗ hổng tự động của o3
- Hai worker thread phối hợp theo cách mà một bên thực hiện giải phóng phiên (
logoff) và giải phóng đối tượnguserkhỏi bộ nhớ, trong khi bên còn lại tiếp tục dùng đối tượnguserđó từ phiên hiện có - Nếu một đường đi khác dereference đối tượng ngay sau khi giải phóng (trước khi nó được khởi tạo về
NULL), sẽ xảy ra use-after-free kiểu kinh điển - Tùy vào timing, cũng có thể gây DoS do NULL dereference
- Có thể dẫn tới hỏng bộ nhớ nhân và thực thi mã tùy ý
Insight rút ra từ báo cáo tự động
Từ báo cáo tự động này, tác giả nhận ra cách sửa lỗ hổng xác thực kerberos trước đó (đặt giá trị NULL ngay sau khi giải phóng) không phải là giải pháp gốc rễ trong xử lý logoff. Nói cách khác, chỉ khi tính đến ràng buộc của phiên và vector tấn công giữa các luồng thì mới bảo đảm được an toàn. o3 cũng đã chứng minh rằng trong một số báo cáo, nó có thể nhìn ra điểm này và đề xuất một cách sửa mạnh hơn.
Kết luận
LLM, đặc biệt là các mô hình mới như o3, đang cho thấy hiệu năng gần với nhà nghiên cứu bảo mật con người hơn nhiều so với các kỹ thuật trước đây ở khía cạnh phân tích mã linh hoạt và sáng tạo. Trước đây điều này chủ yếu mới được nói đến như một khả năng về mặt lý thuyết, nhưng o3 là trường hợp đầu tiên đạt tới mức thực tế thật sự hữu ích trong ví dụ cụ thể. Dĩ nhiên o3 vẫn có thể tạo ra false positive và bỏ sót, nhưng khả năng tạo ra kết quả hữu dụng trong thực tế đã tăng đủ để việc đưa vào công việc thật trở nên có ý nghĩa. Đây là thời điểm mà các nhà nghiên cứu lỗ hổng và lập trình viên cần tìm cách kết hợp LLM vào quy trình làm việc của mình một cách hiệu quả.
1 bình luận
Ý kiến trên Hacker News
Tác giả cho biết họ quản lý dự án bằng cách tách riêng system prompt, thông tin nền, lệnh phụ trợ... thành các tệp
.promptriêng biệt rồi chạy chúng quallmĐiều này khiến tôi cảm thấy cách sử dụng LLM có tổ chức như vậy cho thấy nó cũng cần tư duy thiết kế cẩn thận và điều chỉnh cân bằng đặc tả tỉ mỉ như những công cụ kỹ thuật khác
Có thể xem dự án liên quan tại đây
Điều thú vị là tác giả cũng thẳng thắn nói về phần đó rằng “thực ra toàn bộ system prompt của tôi đều dựa trên suy đoán, khá xa với khoa học hay kỹ thuật”, nghe khá buồn cười
Có nhiều cách viết prompt khác nhau, nhưng lại không có tiêu chuẩn nào đủ rõ ràng để thực sự đánh giá hay so sánh, nên cảm giác giống như đang đọc thần chú ứng biến
Ví dụ như các chỉ dẫn kiểu “bạn là chuyên gia tìm lỗ hổng”, “chỉ báo cho tôi lỗ hổng thật chứ không phải giả”, hay việc phân tách bằng các thẻ HTML tùy ý mà người ta đoán rằng mô hình sẽ phản hồi tốt hơn
Khó hiểu yếu tố kỹ thuật thực sự nằm ở đâu
Việc mang các nguyên tắc kỹ thuật vào để cố kiểm soát một hệ thống vốn bất ổn và khó dự đoán về bản chất nghe khá thú vị
Có lẽ những prompt này nên được gọi là “gợi ý” thì đúng hơn
Mọi LLM hiện nay dường như đều có mục tiêu nội tại là phải đưa ra câu trả lời bằng mọi giá, bất kể đúng hay không, nên ngay cả khi prompt mâu thuẫn, chúng vẫn thường bỏ qua prompt
Bài viết có nhắc đến tỉ lệ tín hiệu trên nhiễu khoảng 1:50, nhưng tôi nghĩ tác giả hiểu rất rõ codebase nên mới có thể chọn lọc được các tín hiệu có ý nghĩa
Phần này, tức là tự động hóa việc phân biệt tín hiệu có ý nghĩa, mới là yếu tố có thể tạo ra bước đột phá thực sự khi ứng dụng LLM, nên tôi sẽ tiếp tục theo dõi sát xu hướng này
Chúng tôi đang phát triển một hệ thống để cải thiện vấn đề tỉ lệ tín hiệu trên nhiễu này, đồng thời cũng đang trực tiếp benchmark các software agent đang nổi hiện nay
Độ dao động của kết quả rất lớn, và chúng tôi dự định công bố toàn bộ kết quả thử nghiệm tại một hội nghị sắp tới
Có lẽ sẽ giúp nhìn thấy bức tranh cập nhật nhất của ngành trong một lần
Vài ngày trước tôi chợt nghĩ liệu có thể tận dụng toàn bộ lịch sử trong Linux kernel như mọi thay đổi git, mailing list... để phát triển một mô hình fine-tune hay không
Một LLM như vậy có thể trở thành phiên bản tổng hợp gần hơn với trực giác của các lập trình viên đã thật sự làm việc với mã trong thời gian dài
Chỉ riêng high-context cũng đã bao phủ được rất nhiều, và có những codebase mà riêng phần mã đã vượt quá 200.000 token nên tôi nghĩ vẫn có tiềm năng
Tỉ lệ 1:50 là một tỉ lệ phát hiện rất tốt trong kiểu bài toán “mò kim đáy bể”
Nếu LLM có thể tự viết cả harness và bài test proof of concept để chứng minh từng phỏng đoán về lỗ hổng, thì tỉ lệ tín hiệu trên nhiễu có lẽ sẽ được cải thiện mạnh
Nhưng tiếc là hiện tại mức tự động hóa như vậy vẫn khá tốn kém
Điều ấn tượng nhất với tôi là chính tác giả đã lặp lại việc tìm kiếm lỗ hổng 100 lần cho từng mô hình LLM khác nhau
Mức đầu tư tài nguyên như vậy cao hơn rất nhiều so với hầu hết các bài toán tôi từng xử lý bằng LLM, nên giờ tôi cũng bắt đầu nghĩ có lẽ nên thử giao cho mô hình kiểu “lặp vô não” một lần xem sao
Rốt cuộc kết luận vẫn là cần rất nhiều tiền
Lỗ hổng zero-day có thể bán được với giá rất cao, và cũng có thể kiếm tiền qua bug bounty
Chi phí dùng LLM là rất nhỏ nếu so với những khoản thưởng đó
Một môi trường an ninh mạng trong tương lai, nơi chi phí suy luận gần như bằng 0, có lẽ sẽ hoàn toàn khác
Chạy 100 lần cho mỗi mô hình cũng đồng nghĩa với mức tiêu thụ năng lượng không nhỏ
Khi một lỗ hổng thường thấy trong mã C được tìm ra bằng cách đốt nhiều tài nguyên đến vậy, ý nghĩa của nó dường như bị giảm đi, còn thứ nổi bật hơn lại là sự lãng phí và xa xỉ
Trong bối cảnh khủng hoảng khí hậu toàn cầu hiện nay, tôi thật sự lo ngại khi thấy chúng ta tiếp tục đốt tài nguyên vào những việc ít giá trị như thời thập niên 1950
Vì Claude không được cung cấp scratchpad (không gian ghi chép suy nghĩ trung gian) riêng, nên có vẻ đầu ra đã bị trộn lẫn giữa luồng suy nghĩ và báo cáo kết quả
Tôi muốn thử xem Claude sẽ thay đổi đến mức nào nếu được chính thức cho phép một không gian để sắp xếp suy nghĩ
Trong khi o3 chắt lọc và truyền đạt phần cốt lõi theo kiểu giống một bug report do con người viết, thì kết quả từ Sonnet 3.7 lại có cảm giác vẫn còn lưu lại dòng suy nghĩ trong đầu hoặc nhật ký công việc, theo đúng mạch đó
Tôi đã trực tiếp dùng cả o3, 3.7 và Gemini 2.5 pro, và cảm giác là o3 ở một đẳng cấp không thể so sánh
Điểm benchmark có thể không chênh lệch quá lớn, nhưng với các tác vụ phức tạp thì ý nghĩa của khoảng cách này tăng lên nhiều
Tôi thắc mắc vì sao công bố từ tháng 11 năm ngoái mà chỉ mới phát hành cách đây khoảng một tháng thôi (có lẽ là vì cần bảo đảm an toàn), và cũng đang rất mong o4
Tôi tò mò không biết có ai có thể gợi ý các trường hợp ứng dụng, bài báo hay liên kết liên quan đến việc dùng “scratchpad” trong nghiên cứu không
Tôi thích đoạn tóm lược cực kỳ đúng bản chất của quá trình prompt engineering này
Đặc biệt là đoạn kiểu như: “Tôi đã cố hết sức hướng dẫn để không đánh dấu nhầm các lỗ hổng sai thành false positive, nhưng thật ra tôi không có cách nào biết việc đó có giúp ích hay không, chỉ đơn giản là hy vọng nó có ích; tôi vẫn chưa đánh giá đủ để biết điều này có hiệu quả không, nên đây không phải khoa học cũng chẳng phải kỹ thuật; khi nào đánh giá xong tôi sẽ chia sẻ sau” quá giống với cách tôi phát triển prompt
Tôi nghĩ đây có lẽ là một trong những trường hợp sử dụng phù hợp nhất cho LLM: tự động phát hiện lỗ hổng
Về lý thuyết, có thể tự động hóa toàn bộ quy trình, dùng LLM như một fuzzer cực kỳ phát triển, liên tục chạy mục tiêu trong VM, và khi phát hiện dấu hiệu bất thường thì suy ra khả năng có lỗ hổng thật
(Nhắc lại rằng phần lớn exploit giai đoạn đầu thường bắt đầu bằng việc làm máy sập hoặc gây crash rồi mới được cải tiến tiếp)
Một mặt, cách dùng LLM như vậy trông rất hiệu quả, nhưng mặt khác cũng đi kèm hàm ý rằng “việc chúng ta có thể làm các bài test kiểu này không có nghĩa là đã phát hiện ra điều gì đặc biệt mới mẻ hay mang tính quyết định”
Tôi để lại liên kết YouTube tới bài trình bày của mình về chủ đề nhắm mục tiêu tự động hóa lỗi zk (liên quan đến zero-knowledge proof)
Có thể hiểu các tham số bổ sung kia chỉ để phục vụ việc theo dõi liên kết
Tôi thật lòng hy vọng chuyện này không diễn biến như chuỗi sự cố liên tiếp của curl
Có thể tham khảo ngữ cảnh liên quan trong bài viết của Daniel Stenberg
Theo tôi biết thì ksmbd là máy chủ SMB trong kernel, nhắm đến việc nhẹ hơn và hiệu năng cao hơn so với máy chủ Samba truyền thống
Q1: Tôi tò mò không biết thực tế ai đang dùng ksmbd trong môi trường production
Q2: Và họ dùng vì lý do gì
Có ai biết liệu cái này có hỗ trợ ACL native như trên Windows không?
(Đó từng là lý do cuối cùng khiến tôi tiếp tục dùng Solaris, và tôi hiểu là nó được hỗ trợ qua ZFS)
Samba vẫn mang cấu trúc lạc hậu, như việc bị kẹt trong đồng bộ UID/GID và mô hình bảo mật kiểu Unix
Máy chủ SMB trong kernel cũng từng dính lỗ hổng remote root nghiêm trọng trên Windows, nên cần cân nhắc rõ trade-off
Nguyên nhân là vấn đề giấy phép
Samba là GPLv3, còn Linux chỉ có thể dùng GPLv2
Tôi đoán người ta dùng đơn giản vì nó nhẹ và hiệu năng cao
Tôi nghĩ lý do cũng tương tự như việc dùng kmod-trelay thay cho relayd
Tôi nghĩ bài toán lớn nhất trước mắt của LLM về mặt Alignment Problem lại đang lộ rõ chính ở kiểu tự động hóa lỗ hổng này
Gần đây tôi đã gần như không tốn công mà dùng LLM để tìm ra một lỗ hổng bảo mật thật sự nghiêm trọng trong một máy chủ ngách mà tôi thỉnh thoảng dùng
Nếu thị trường này được tự động hóa, thì rất nhiều phần mềm “đuôi dài” trước đây không đáng để tấn công thủ công có thể sẽ đồng loạt lộ ra các vấn đề nghiêm trọng
Ngược lại, chính nhờ tiến bộ công nghệ như vậy mà chúng ta cũng có thể tự động phân tích codebase của chính mình dưới “góc nhìn đối kháng”
Những lỗ hổng lẽ ra sẽ bị nhà nghiên cứu tìm ra rồi bị khai thác thì nay có cơ hội được vá trước một cách chủ động
Vì vậy gọi đây là vấn đề alignment có lẽ không thật sự phù hợp
Kẻ tấn công có thể tự động hóa việc phát hiện lỗ hổng, nhưng bên phòng thủ cũng có thể có năng lực tương tự
Cũng có thể tích hợp tự động hóa phòng thủ vào quy trình phê duyệt commit hoặc mỗi lần build