Nghiên cứu bảo mật từng đòi hỏi điều tra riêng, kéo dài cho từng phát hiện; nay ngày càng có thể triển khai thành một quy trình có hệ thống. Tài liệu này trình bày một trong những nỗ lực của chúng tôi trong lĩnh vực đó.
Việc phát hiện lỗ hổng ngày càng dễ mở rộng quy mô, nhưng xác định thứ tự ưu tiên và xác thực vẫn là những nút thắt trong vận hành. Chúng tôi xây dựng một hệ thống thử nghiệm để tìm lỗi bảo mật trong nhân Linux, trong môi trường nghiên cứu có kiểm soát. Hệ thống thử nghiệm đã xác định và phân tích 2.308 lỗ hổng tiềm năng trong nhân Linux, tái hiện động 1.724 lỗ hổng và tạo 948 mã khai thác leo thang đặc quyền cục bộ (LPE), có thể cho phép người dùng cục bộ không có đặc quyền giành quyền root.
Chúng tôi dùng bằng chứng này để ưu tiên các lỗ hổng cần báo cáo và phát triển bản vá đề xuất để nhà bảo trì xem xét. Theo hướng dẫn của cộng đồng nhân Linux, chúng tôi bắt đầu từ các lỗ hổng nghiêm trọng và đang hợp tác với các đối tác Patch the Planet để tiếp tục gửi báo cáo và bản vá.
Vào tháng 6, trong khuôn khổ sáng kiến Patch the Planet, chúng tôi chia sẻ rằng GPT‑5.5 Cyber đã xác định các lỗ hổng trong nhân Linux và phát triển 24 mã khai thác leo thang đặc quyền cục bộ để xác thực và báo cáo các lỗ hổng đó. Chúng tôi mở rộng công việc đó thành một quy trình vận hành bằng mô hình an ninh mạng sắp ra mắt, bao gồm phát hiện lỗ hổng, xác thực động, đánh giá khả năng khai thác và tạo bản vá. Khi quy trình hoàn tất, các nhà nghiên cứu xem xét đầu ra và báo cáo những lỗ hổng tìm được kèm theo bản vá.
Tóm tắt
Phương pháp
Về tổng thể, quy trình của chúng tôi hoạt động như sau: trước tiên, xác định các phần liên quan đến bảo mật trong nhân Linux; quét tĩnh những mục tiêu kiểm tra đó để tìm lỗ hổng tiềm năng; tái hiện động các phát hiện trong môi trường cô lập; tạo mã khai thác minh chứng (PoC) để chứng minh khả năng khai thác; tạo bản vá; cuối cùng, một nhà nghiên cứu bảo mật sẽ xem xét kết quả.
Đầu ra của quy trình gồm bản phân tích nguyên nhân gốc rễ, mã minh chứng tối giản gây sự cố, bản vá đề xuất và mã khai thác hoàn chỉnh để hỗ trợ các nhà nghiên cứu đánh giá mức độ nghiêm trọng của lỗ hổng và đưa bản sửa lỗi vào dự án gốc.
Kết quả
Trong một lần chạy vào giữa tháng 10 năm 2026, quy trình dùng mô hình an ninh mạng sắp ra mắt của chúng tôi đã tái hiện động 1.724 lỗ hổng, tạo PoC cho 291 lỗ hổng rò rỉ thông tin và tạo 948 mã khai thác leo thang đặc quyền cục bộ hoạt động được (LPE) trên một bản phân phối Linux phổ biến. Tổng chi phí của lần chạy là 1.213.430 USD dưới dạng credit API, tương đương 1.279 USD cho mỗi mã khai thác LPE.
Các máy ảo mục tiêu chạy hệ điều hành máy tính để bàn tiêu chuẩn, không bị cố ý làm yếu đi, theo cùng mô hình mối đe dọa được dùng trong các cuộc thi an ninh mạng (ví dụ: Pwn2Own(mở trong cửa sổ mới), TyphoonPWN(mở trong cửa sổ mới)). Trước đây, Pwn2Own và TyphoonPWN từng trao thưởng lần lượt 20.000 USD và 70.000 USD cho mã khai thác LPE trong nhân Linux. Áp dụng các mức thưởng trước đây đó cho 948 mã khai thác cho ra giá trị giả định 18,9–66,3 triệu USD, gấp khoảng 16 đến 55 lần chi phí quy trình của chúng tôi.
Trên môi trường kernelCTF(mở trong cửa sổ mới) đã được điều chỉnh, sử dụng phiên bản nhân Linux có bề mặt tấn công thu hẹp, quy trình của chúng tôi thu được 25 PoC rò rỉ thông tin và 21 mã khai thác LPE. Để so sánh, tính đến thời điểm viết bài, kernelCTF đã chấp nhận 26 mã khai thác LPE 0-day được xác nhận trong năm 2026.
Đợt nghiên cứu này tốn khoảng 32.936 USD dưới dạng credit API. Nếu 21 lỗ hổng được chương trình chấp nhận, tổng tiền thưởng sẽ vào khoảng 1,5 triệu USD, gấp khoảng 45 lần chi phí quét.
Theo hiểu biết của chúng tôi, các tác nhân trong quy trình này đã phát hiện và sử dụng ít nhất 10 kỹ thuật khai thác Linux mới.
Nhận định
Các nhà bảo trì Linux và cộng đồng bảo mật đang nỗ lực nhanh chóng phát hiện và khắc phục lỗ hổng. Trong 10 ngày quét, chúng tôi ghi nhận hơn 100 lỗ hổng LPE trong Linux đã được vá hoặc có bản vá chờ tích hợp từ những người đóng góp khác, cùng khoảng 300 lỗ hổng khác đang được thảo luận công khai.
Với tốc độ phát hiện lỗ hổng của các mô hình tiên phong, chúng tôi tin rằng việc tạo bản vá tự động là thiết yếu để bảo vệ phần mềm đủ nhanh và rút ngắn khoảng thời gian lỗ hổng có thể bị khai thác. Chúng tôi tin rằng qua nhiều vòng cải tiến dưới sự hướng dẫn của chuyên gia, các bản vá do AI tạo có thể đúng về chức năng, phù hợp với phong cách viết mã hiện có và chống chịu được các biến thể tấn công. Đây là một hướng quan trọng cần tiếp tục nghiên cứu.
Các mô hình mạnh hơn có thể phát hiện lỗ hổng mới trong mã hiện có, thường bao gồm cả những lỗ hổng đã tồn tại lâu hơn và khó nhận diện hơn. Quy trình phân tích dùng mô hình an ninh mạng mới hơn của chúng tôi vào giữa tháng 10 đã phát hiện số lỗ hổng LPE mới nhiều gấp >5 lần so với lần chạy GPT‑5.6 Sol vào tháng 7, dù đã có ba tháng tăng cường bảo mật giữa hai lần quét.
Các dự án phần mềm lớn, phức tạp có thể cần nhiều vòng quét và khắc phục lỗ hổng để xử lý triệt để các lỗi tiềm ẩn. Lý tưởng nhất là lặp lại quy trình này với mỗi thế hệ mô hình tiên phong tiếp theo. Điều này áp dụng cho cả phần mềm độc quyền lẫn phần mềm nguồn mở.
Trong ngắn và trung hạn, với một bên tấn công có nguồn lực dồi dào, việc có tài khoản đặc quyền thấp trên hệ điều hành chưa cập nhật các bản vá mới nhất nên được xem là về thực chất tương đương với có quyền root. Phòng thủ nhiều lớp, sử dụng sandbox và các phương thức cô lập như Firecracker và gVisor là những biện pháp quan trọng để giới hạn phạm vi thiệt hại khi lỗ hổng bị khai thác.
Chúng tôi tin rằng trong vài năm tới, nếu một dự án phần mềm có lỗ hổng, các mô hình tiên phong nhiều khả năng sẽ phát hiện được các lỗ hổng đó; ngay cả mô hình kém mạnh hơn cũng có thể phát triển mã khai thác sau khi lỗ hổng được công bố. Trong một thế giới không còn lỗ hổng chưa được biết đến, việc xây dựng và duy trì phần mềm có mức bảo đảm an toàn cao sẽ vô cùng quan trọng, nhất là phần mềm cốt lõi như hệ điều hành, trình duyệt, thư viện phân tích hình ảnh, ngăn xếp TCP/IP và nhiều thành phần khác. Bên cạnh việc tìm và sửa lỗ hổng hiện có, đầu tư huấn luyện mô hình mặc định viết mã an toàn, thu hẹp bề mặt tấn công bằng cách loại bỏ tính năng không cần thiết và kiểm chứng hình thức là những hướng nghiên cứu đầy hứa hẹn để mở rộng hiệu quả công tác bảo mật phần mềm.
Nhân Linux là nền tảng của thiết bị Android, hạ tầng đám mây, siêu máy tính và các hệ thống khác được hàng tỷ người sử dụng. Với hơn 40 triệu dòng mã, nhân Linux có bề mặt tấn công rộng thông qua lời gọi hệ thống, chức năng mạng, hệ thống tệp và trình điều khiển thiết bị. Chúng tôi chọn Linux để nghiên cứu mức độ hiệu quả của các mô hình tiên phong trong việc tìm lỗ hổng và chứng minh tác động bảo mật của chúng trên một cơ sở mã có quy mô và tầm quan trọng như vậy.
Giai đoạn phát hiện lỗ hổng ban đầu tìm ra hàng nghìn phát hiện tiềm năng, quá nhiều để các nhà nghiên cứu bảo mật rà soát và phân loại thủ công. Thách thức vận hành của quy trình phát hiện lỗ hổng không nằm ở việc phát hiện, mà ở việc xác định phát hiện nào có thể tái hiện, chúng vượt qua ranh giới bảo mật nào và phát hiện nào cần nhà bảo trì chú ý sớm nhất.
Sứ mệnh của nhóm An ninh mạng tại OpenAI là góp phần bảo vệ những phần mềm mà thế giới đang dựa vào. Chúng tôi báo cáo chi phí API cho từng giai đoạn để giúp các nhà nghiên cứu đánh giá nguồn lực cần thiết nhằm tái lập và mở rộng công việc này. Các chi phí này phản ánh mô hình, cấu hình mục tiêu và quy trình được dùng trong lần đánh giá này. Mục tiêu rộng hơn của chúng tôi là giúp bên phòng thủ tìm và sửa lỗ hổng, thu hẹp cơ hội của kẻ tấn công và nâng chi phí khai thác phần mềm của chúng.
Cuối cùng, xin lưu ý rằng nghiên cứu này tập trung vào phương pháp và đo lường năng lực mô hình, chứ không phải chi phí. Chúng tôi kỳ vọng việc đầu tư kỹ thuật đầy đủ cho hệ thống điều khiển có thể giảm đáng kể chi phí ở từng giai đoạn; vì vậy, chi phí chúng tôi báo cáo nên được xem là mức trần.
Hệ thống nghiên cứu lỗ hổng thử nghiệm của chúng tôi là quy trình năm giai đoạn, lấy mô hình an ninh mạng sắp ra mắt làm cốt lõi:
Phát hiện lỗ hổng: Các tác nhân xác định những phần liên quan đến bảo mật trong cơ sở mã và quét để tìm lỗ hổng tiềm năng.
Xác thực động: Các tác nhân thử tái hiện từng phát hiện tiềm năng trong môi trường cô lập và lưu giữ bằng chứng khi thực thi. Đầu ra của bước này là các lỗ hổng đã được tái hiện và xác thực.
Đánh giá khả năng khai thác: Các tác nhân kiểm tra xem lỗ hổng đã xác thực có thể làm lộ thông tin hoặc cho phép leo thang đặc quyền cục bộ hay không.
Tạo bản vá: Các tác nhân tạo bản vá để xử lý từng lỗ hổng đã xác định.
Con người rà soát: Các nhà nghiên cứu bảo mật xem xét mã khai thác, bản vá và mức độ nghiêm trọng được đề xuất trước khi báo cáo cho nhà bảo trì.
Ở cuối quy trình, hệ thống tổng hợp bản phân tích nguyên nhân gốc rễ, mã minh chứng tối giản gây sự cố, bản vá đề xuất và mã khai thác hoàn chỉnh để hỗ trợ các nhà nghiên cứu đánh giá mức độ nghiêm trọng của lỗ hổng và đưa bản sửa lỗi vào dự án gốc.
Không phải dòng mã nào trong nhân Linux cũng liên quan đến bảo mật. Quy trình của chúng tôi dùng một nhóm tác nhân trinh sát để xác định các mục tiêu kiểm tra có giá trị cao, rồi chuyển các mục tiêu này cho các tác nhân phân tích để quét lỗ hổng.
Các tác nhân trinh sát đọc từng thư mục và tệp, rồi xác định mục tiêu cần kiểm tra dựa trên khả năng tiếp cận (người dùng đặc quyền thấp có thể tiếp cận) và mức độ liên quan đến bảo mật.
Giai đoạn này xác định được 5.034 mục tiêu kiểm tra, khoảng 2,8 triệu dòng mã, tương đương khoảng 7% toàn bộ mã nguồn nhân Linux, giúp giảm đáng kể chi phí kiểm tra bảo mật so với phân tích toàn bộ mã nguồn. Bước này tốn 3.426 USD dưới dạng credit API.
Tiếp theo, các tác nhân phân tích xem xét từng mục tiêu kiểm tra và tìm ra các lỗ hổng tiềm năng bằng quy trình tương tự tiện ích Codex Security(mở trong cửa sổ mới). Về tổng thể, các tác nhân phân tích đọc mã của mục tiêu được giao để hiểu cách hoạt động, xác định mô hình mối đe dọa và tìm lỗ hổng trong đó.
Trong vòng 12 giờ, các tác nhân phân tích tìm ra 2.308 lỗ hổng tiềm năng sau khi loại bỏ trùng lặp. Giai đoạn này tốn 316.549 USD dưới dạng credit API.
Một phát hiện tiềm năng không đồng nghĩa với một lỗ hổng đã được xác thực. Ở quy mô này, việc điều tra thủ công từng báo cáo là không khả thi với nhóm nghiên cứu của chúng tôi.
Vì vậy, chúng tôi tập trung xác thực những phát hiện a) người dùng đặc quyền thấp có thể tiếp cận, b) không đòi hỏi quyền hạn đặc biệt và c) tạo ra bằng chứng đo lường được về lỗi hỏng bộ nhớ.
Với mỗi phát hiện tiềm năng, một tác nhân phân loại tạo mã minh chứng rồi chạy mã đó trong máy ảo cô lập, sử dụng nhân Linux có Kernel Address Sanitizer (KASAN). Tác nhân theo dõi cả đầu ra chương trình lẫn bảng điều khiển hệ thống, rồi tinh chỉnh mã minh chứng qua nhiều vòng cho đến khi tái hiện được hành vi đã báo cáo hoặc đã thử hết các cách có thể kích hoạt hành vi đó.
Trong vòng 30 giờ, hệ thống của chúng tôi tái hiện được 1.724 lỗ hổng, tương đương khoảng 74,7% trong số 2.308 phát hiện tiềm năng. Chỉ rà soát mã tĩnh có thể dễ dẫn đến dương tính giả, nên chúng tôi rất ấn tượng với độ chính xác của các tác nhân phân tích và hiệu quả của các tác nhân phân loại khi tự chủ tạo mã minh chứng hoạt động được cho gần ba phần tư số phát hiện tiềm năng.
Phần lớn phát hiện còn lại hoặc đòi hỏi đặc quyền cao hơn, hoặc không thể tái hiện trong thời gian cho phép do điều kiện tranh chấp khó kích hoạt, điều kiện kích hoạt đặc thù (ví dụ: phải xảy ra lỗi cấp phát tại một dòng cụ thể), hoặc quá trình xác thực tốn thời gian (ví dụ: bộ đếm tham chiếu tràn vòng). Chỉ 3,1% là do mô hình phân tích sai, trong đó lỗ hổng được báo cáo giả định một điều kiện không thể xảy ra.
Giai đoạn xác thực tốn tổng cộng 73.330 USD dưới dạng credit API. Chúng tôi nhận thấy quy trình xác thực, vốn cần tạo mã minh chứng để xác nhận một phát hiện có thực sự là lỗ hổng hay không, tốn kém hơn việc đưa ra khuyến nghị chỉ dựa trên phân tích tĩnh; đồng thời, chi phí cố gắng xác thực một dương tính thật và một dương tính giả là tương đương. Vì vậy, loại bỏ dương tính giả sớm hơn trong quy trình giúp tiết kiệm chi phí đáng kể.
Xác thực chứng minh lỗ hổng có thật, nhưng không cho biết cần xử lý khẩn cấp đến mức nào. Ví dụ, lỗ hổng có thể cho phép leo thang đặc quyền cục bộ cần được ưu tiên hơn lỗ hổng chỉ có thể gây từ chối dịch vụ cục bộ. Với 1.724 lỗ hổng đã được xác thực, nhiệm vụ tiếp theo là xác định những phát hiện có tác động tiềm tàng lớn nhất đến bảo mật.
Một tác nhân sàng lọc ban đầu rà soát tĩnh từng báo cáo, nhật ký sự cố và mã nguồn liên quan. Tác nhân được chủ ý đặt tiêu chí rộng để tránh bỏ sót phát hiện có thể nghiêm trọng, đồng thời loại bỏ những trường hợp không có hướng khai thác khả thi. Bước này thu hẹp kết quả còn 313 lỗ hổng rò rỉ thông tin tiềm năng và 1.238 lỗ hổng leo thang đặc quyền cục bộ tiềm năng.
Sau đó, các tác nhân phát triển mã khai thác (ExploitDev) kiểm thử những lỗ hổng tiềm năng đó trong máy ảo cô lập, bật các biện pháp bảo vệ của bản phân phối Linux tiêu chuẩn, gồm ngăn thực thi ở chế độ giám sát (SMEP), ngăn truy cập ở chế độ giám sát (SMAP), ngẫu nhiên hóa bố cục không gian địa chỉ nhân (KASLR) và HARDENED_USERCOPY. Điều này giúp tránh những đánh giá thiếu thực tế dựa vào việc tắt các biện pháp bảo vệ.
Các tác nhân tạo ra 291 mã minh chứng rò rỉ thông tin và 1.169 mã khai thác leo thang đặc quyền cục bộ hoạt động được, có thể cho phép người dùng cục bộ không có đặc quyền giành quyền root.
Chúng tôi thực hiện phân tích biến thể và phát triển 948 bản vá riêng biệt cho các lỗ hổng đứng sau những mã khai thác đó. Chúng tôi dùng con số đó để xác định tổng số lỗ hổng LPE riêng biệt. Chi phí phát triển mã khai thác thành công trung bình là 359 USD dưới dạng credit. Nhờ vậy, bên phòng thủ có thể kiểm tra khả năng khai thác của các lỗ hổng tìm được với chi phí tương đối thấp.
Tác nhân sàng lọc lỗ hổng ban đầu tốn 44.194 USD dưới dạng credit API. Giai đoạn khai thác tốn tổng cộng 775.929 USD dưới dạng credit API, gồm 84.929 USD để xử lý các lỗ hổng rò rỉ thông tin tiềm năng và 691.000 USD cho các lỗ hổng leo thang đặc quyền cục bộ tiềm năng.
Trung bình, xử lý một lỗ hổng leo thang đặc quyền cục bộ tiềm năng (558 USD) tốn gần gấp đôi xử lý một lỗ hổng rò rỉ thông tin tiềm năng (271 USD). Nguyên nhân là các PoC rò rỉ thông tin được kế thừa từ giai đoạn xác thực và cần ít chỉnh sửa hơn để có thể dùng trong mã khai thác. Ngược lại, phát triển mã khai thác từ một lỗ hổng LPE tiềm năng đòi hỏi nhiều bước bổ sung như lập chiến lược khai thác, xác định đối tượng có lỗ hổng để sử dụng, vượt qua các biện pháp giảm thiểu và nhiều bước khác. Chúng tôi cũng nhận thấy những nỗ lực khai thác không thành công (3.922 USD cho 69 trường hợp) tốn kém hơn nhiều so với các trường hợp thành công (360 USD cho 1.169 trường hợp). Nguyên nhân là một số lỗ hổng khó khai thác (ví dụ: điều kiện tranh chấp). Đặt điều kiện dừng hợp lý, chẳng hạn dừng sau một giờ không có tiến triển, sẽ giúp giảm đáng kể chi phí của ExploitDev.
Với mỗi lỗ hổng đã xác thực, hệ thống cũng tạo một bản vá. Chúng tôi cung cấp mã nguồn liên quan cho mô hình và hướng dẫn mô hình áp dụng các thực hành tốt nhất khi viết bản vá, như kiểm tra tĩnh bản vá, tuân theo cách phát triển phần mềm được dùng trong mã lân cận và phân tích biến thể để bảo đảm bản vá xử lý đầy đủ.
Theo đề xuất của cộng đồng nhân Linux, chúng tôi đã gửi hàng trăm báo cáo và bản vá cho các lỗ hổng nghiêm trọng, đồng thời đang hợp tác với các đối tác Patch the Planet để từng bước gửi bản vá cho số còn lại. Công việc này thuộc cam kết Daybreak rộng hơn của chúng tôi nhằm hỗ trợ các dự án nguồn mở.
Trong phần này, chúng tôi chia sẻ những bài học, nhận định và phân tích bổ sung từ nghiên cứu.
Trong nghiên cứu này, chúng tôi nhận thấy các nhà bảo trì Linux đang nhanh chóng khắc phục lỗ hổng và bảo vệ người dùng. Quá trình quét được thực hiện trên nhân Linux mới nhất vào giữa tháng 10 năm 2026. Khi quá trình quét tự chủ và phân tích thủ công hoàn tất sau 10 ngày, 61 lỗ hổng LPE đã được vá trong dự án gốc, 43 lỗ hổng có bản vá chờ tích hợp và 299 lỗ hổng đang được báo cáo, thảo luận công khai.
Chúng tôi rất trân trọng các nhà bảo trì Linux đang khẩn trương vá những vấn đề đã xác định, cũng như cộng đồng bảo mật rộng lớn đang đóng góp các phát hiện của mình. Sự chung tay này chính là điều cần thiết để bảo vệ phần mềm trên toàn thế giới. Tốc độ công bố và vá lỗ hổng nhanh chóng cũng nhấn mạnh tầm quan trọng của việc người dùng và doanh nghiệp luôn cập nhật phần mềm.
Bài học: Quá trình phân loại tự động cần tính đến chu kỳ vá lỗi nhanh. Xác thực lại các phát hiện trên mã mới nhất, kể cả mã được hợp nhất sau lần quét ban đầu, giúp tránh báo cáo trùng lặp hoặc không còn phù hợp. Điều này giúp tập trung vào các lỗ hổng chưa được xử lý và cung cấp cho nhà bảo trì bằng chứng để hành động mà không tạo thêm gánh nặng rà soát không cần thiết.
Trong quá trình chúng tôi phát triển quy trình, vào cuối tháng 7 năm 2026, GPT‑5.6 Sol đã tìm và khai thác 166 lỗ hổng LPE riêng biệt, với tổng chi phí 513.690 USD dưới dạng credit API.
Trong lần quét thứ hai, vào giữa tháng 10 năm 2026, mô hình an ninh mạng mới hơn đã tìm và khai thác 948 lỗ hổng LPE riêng biệt, với tổng chi phí 1.213.430 USD dưới dạng credit API. Trong cả hai đợt, chúng tôi đều quét nhánh master mới nhất của nhân Linux tại thời điểm đó.
Bài học: Quét lại mã đã kiểm tra khi năng lực mô hình được cải thiện. Mô hình mạnh hơn có thể phát hiện những lỗ hổng mà các mô hình trước bỏ sót, ngay cả khi dùng cùng hệ thống điều khiển phục vụ nghiên cứu.
Chúng tôi lấy mẫu 166 mã khai thác do các tác nhân phát triển và phân tích những kỹ thuật khai thác được sử dụng. Theo hiểu biết của chúng tôi, các tác nhân đã dùng 10 kỹ thuật khai thác mới trong các mã khai thác được lấy mẫu. Chúng tôi chia sẻ các kỹ thuật này với những chuyên gia khai thác nhân bên thứ ba, và những kỹ thuật này cũng mới đối với họ.
Trong 10 kỹ thuật, hai kỹ thuật dùng các đối tượng co giãn tồn tại lâu dài mới mà mô hình sử dụng để rải đối tượng vào bộ nhớ đệm nhân mục tiêu; hai kỹ thuật sắp xếp trang nhớ mới giúp tăng độ tin cậy của mã khai thác; năm kỹ thuật mới chỉ thao tác dữ liệu để leo thang đặc quyền trực tiếp hoặc thông qua khả năng ghi tùy ý; kỹ thuật còn lại liên quan đến nhầm lẫn kiểu tùy ý. Vì lý do an toàn, chúng tôi không chia sẻ đầy đủ chi tiết kỹ thuật của những kỹ thuật khai thác mới này trong bài viết.
Bài học: Các mô hình tiên phong không chỉ đối chiếu mẫu mã dễ bị tấn công đã biết hay chỉ dùng kỹ thuật khai thác có sẵn; các mô hình này còn thể hiện khả năng sáng tạo và cách tiếp cận mới.
Một phần quan trọng trong sứ mệnh của nhóm chúng tôi là đo lường chi phí tìm và khai thác lỗ hổng, rồi dùng bằng chứng đó để định hướng đầu tư cho phòng thủ. Mục tiêu của chúng tôi là giúp bên phòng thủ sửa lỗ hổng trước khi kẻ tấn công có thể sử dụng, đồng thời khiến chi phí khai thác phần mềm trở nên quá cao đối với kẻ tấn công. Đo lường chi phí khai thác giúp chúng tôi đánh giá thách thức này thay đổi ra sao khi năng lực mô hình được cải thiện. Trong phần này, chúng tôi so sánh chi phí chạy quy trình với mức thưởng của các chương trình thưởng tìm lỗi dành cho những lỗ hổng đã xác định.
Các máy ảo mục tiêu trong thí nghiệm chạy hệ điều hành máy tính để bàn tiêu chuẩn, không bị cố ý làm yếu đi, theo cùng mô hình mối đe dọa được dùng trong các cuộc thi an ninh mạng (ví dụ: Pwn2Own(mở trong cửa sổ mới), TyphoonPWN(mở trong cửa sổ mới)). Trước đây, Pwn2Own và TyphoonPWN từng trao thưởng lần lượt 20.000 USD và 70.000 USD cho mã khai thác leo thang đặc quyền cục bộ trong nhân Linux. Áp dụng các mức thưởng trước đây đó cho 948 mã khai thác cho ra giá trị giả định 18,9–66,3 triệu USD, gấp khoảng 16 đến 55 lần chi phí quy trình của chúng tôi.
Chúng tôi cũng thử nghiệm quy trình với chương trình thưởng tìm lỗ hổng kernelCTF(mở trong cửa sổ mới) của Google, có mục tiêu là nhân Linux được tăng cường bảo mật và thu hẹp bề mặt tấn công. Chúng tôi chạy quy trình trên phiên bản nhân Linux mới nhất trong môi trường kernelCTF (phiên bản này không tương thích với biện pháp giảm thiểu SLAB_VIRTUAL của kernelCTF nên chúng tôi loại bỏ biện pháp đó khỏi cấu hình), thu được 25 mã minh chứng rò rỉ thông tin và 21 mã khai thác leo thang đặc quyền cục bộ. Để so sánh, tính đến thời điểm viết bài, kernelCTF đã chấp nhận 26 mã khai thác LPE 0-day được xác nhận trong năm 2026. Toàn bộ đợt nghiên cứu kéo dài 112 giờ, tốn khoảng 32.936 USD dưới dạng credit API, trong đó bước phát hiện lỗ hổng chiếm 83,7% chi phí API. Nếu 21 lỗ hổng được chương trình chấp nhận, tổng tiền thưởng sẽ vào khoảng 1,5 triệu USD, gấp khoảng 45 lần chi phí.
Bài học: Dựa trên các mức thưởng công khai, với những mô hình có năng lực an ninh mạng hiện tại, quy trình nghiên cứu lỗ hổng của chúng tôi có lợi nhuận ròng tại thời điểm nghiên cứu. Bên phòng thủ nên chủ động phân tích phần mềm của mình để khiến chi phí khai thác trở nên quá cao đối với kẻ tấn công.
Trong giai đoạn đánh giá khả năng khai thác, các tác nhân ExploitDev được cung cấp báo cáo lỗ hổng và giao nhiệm vụ tạo mã khai thác hoạt động đầy đủ. Quy trình của chúng tôi đánh dấu một lỗ hổng là đã khai thác nếu giành được shell có quyền root. Trong một lần chạy ban đầu, giai đoạn khai thác báo cáo 200 mã khai thác leo thang đặc quyền cục bộ thành công. Tuy nhiên, sau khi con người xem xét, chúng tôi phát hiện 20 mã trong số đó đã giành quyền root thông qua một lỗ hổng 0-day khác với lỗ hổng được giao. Điều này cho thấy ngay cả khi tác nhân khai thác thành công, kết quả vẫn cần được xác thực đúng cách.
Sau đó, chúng tôi siết chặt các ràng buộc nhiệm vụ và bổ sung bước kiểm tra độc lập để xác nhận mỗi mã khai thác cuối cùng đều dùng đúng lỗ hổng được giao.
Bài học: Với nghiên cứu bảo mật tự chủ, hãy kiểm chứng cả cách đạt được kết quả chứ không chỉ bản thân kết quả; cô lập, giám sát và kiểm tra độc lập là những biện pháp kiểm soát cần thiết.
Ở giai đoạn đầu nghiên cứu, chúng tôi cân nhắc liệu có nên xây dựng cơ chế điều phối phức tạp quanh tác nhân để cải thiện năng lực an ninh mạng của nó hay không. Kết quả cho thấy các mô hình mạnh hơn cần ít điều phối và hướng dẫn sát sao hơn. Mức cải thiện nhỏ thu được cũng không xứng đáng với chi phí bảo trì. Vì vậy, chúng tôi quyết định loại bỏ cơ chế điều phối phức tạp.
Thí nghiệm so sánh GPT‑5.5 Cyber với GPT‑5.6 Cyber. Theo quan sát của chúng tôi, GPT‑5.5 Cyber chưa xác định một cách nhất quán khi nào và cách nào để áp dụng các kỹ thuật khai thác nhân Linux hiện có. Sau đó, chúng tôi tập hợp 103 kỹ thuật theo định dạng dễ sử dụng cho mô hình, đưa các kỹ thuật này vào môi trường của tác nhân và yêu cầu tác nhân sử dụng. Trên 63 lỗ hổng tiềm năng được chọn để khai thác, cách này nâng tỷ lệ thành công từ 76,2% lên 88,9%.
Khi lặp lại thí nghiệm với GPT‑5.6 Cyber, mô hình có khả năng tự tìm, chọn và áp dụng kỹ thuật phù hợp tốt hơn. Chúng tôi loại bỏ phần điều phối kỹ thuật/kỹ năng; quy trình GPT‑5.6 Cyber với cơ chế điều phối gọn nhẹ này vượt qua quy trình GPT‑5.5 Cyber có nhiều lớp hỗ trợ hơn. Bổ sung lại lớp kỹ thuật cho GPT‑5.6 Cyber chỉ cải thiện thêm 1,5 điểm phần trăm.
Bài học: Đánh giá lại cơ chế điều phối và hệ thống điều khiển khi năng lực mô hình cơ sở thay đổi. Lớp hỗ trợ giúp cải thiện đáng kể một thế hệ mô hình có thể mang lại rất ít giá trị cho mô hình mạnh hơn, nên cần cân nhắc lợi ích so với chi phí bảo trì.
Ban đầu, khi được yêu cầu trực tiếp tạo bản vá đề xuất, mô hình tạo ra những bản vá đúng về chức năng, ngăn được mã minh chứng nhưng đôi khi gây vấn đề khác: viết nhiều mã hơn cần thiết, có thể ảnh hưởng hiệu năng, lệch khỏi quy ước viết mã hoặc không kiểm tra mã liên quan để tìm biến thể của cùng lỗ hổng, khiến bản vá chưa đầy đủ.
Việc bổ sung hướng dẫn và cải tiến quy trình tạo bản vá qua nhiều vòng đã nâng chất lượng bản vá. Điều này cho thấy nếu được xử lý đúng cách, các bản vá bảo mật do AI tạo có thể chính xác, tối giản và nhất quán với quy ước mã hiện có. Đây là lĩnh vực đang được tích cực nghiên cứu, và chúng tôi tin rằng các mô hình tương lai sẽ giúp công việc này dễ dàng, hiệu quả hơn. Trong một vài trường hợp, hệ thống nghiên cứu thử nghiệm của chúng tôi còn xác định được vấn đề trong bản vá do chuyên gia viết, nhờ đó chúng được sửa trước khi hợp nhất.
Bài học: Mô hình có thể đẩy nhanh quá trình vá lỗi, nhưng kỹ năng vá lỗi và hệ thống điều khiển có thể cần cải tiến qua nhiều vòng để bảo đảm bản vá đáp ứng đáng tin cậy cả yêu cầu chức năng lẫn phi chức năng. Ngoài ra, chúng tôi khuyến nghị dùng mô hình để rà soát bản vá của con người và AI từ góc nhìn đối kháng, qua đó phát hiện những vấn đề như bản vá có thể bị vượt qua, bỏ sót đường tấn công hoặc biến thể khác, cùng nhiều vấn đề nữa.
Trong lần chạy kernelCTF, ngoài 21 mã khai thác lỗ hổng 0-day của nhân Linux, hệ thống nghiên cứu thử nghiệm của chúng tôi còn tìm và khai thác một lỗ hổng QEMU TCG. Tác nhân phân tích được giao xem xét mã tại điểm vào của lời gọi hệ thống. Khi viết chương trình thử nghiệm chuyển đổi đặc quyền, nó gặp sự cố nhân ngoài dự kiến. Tác nhân phân loại sự cố và truy nguyên vấn đề đến QEMU TCG dù không có quyền truy cập mã nguồn QEMU, rồi đưa lỗ hổng vào báo cáo. Sau đó, tác nhân ExploitDev phát triển thành công mã khai thác leo thang đặc quyền cục bộ cho lỗ hổng này. Chúng tôi phát hiện lỗ hổng QEMU này khi phân tích thủ công các mã khai thác và xác nhận rằng nó đã được sửa trong dự án QEMU gốc, nhưng chưa được sửa trong bản phát hành dùng cho thí nghiệm.
Bài học: Các mô hình tiên phong có năng lực an ninh mạng có thể tìm ra lỗ hổng trong hạ tầng kiểm thử. Chúng tôi khuyến nghị kiểm thử từng phần của hạ tầng trước khi tiến hành nghiên cứu lỗ hổng theo hướng tấn công. Chúng tôi đã chủ động kiểm thử hạ tầng của mình, công bố và vá nhiều lỗ hổng trong Kata, Moby/Docker, gVisor cùng các dự án khác.
Mục tiêu của chúng tôi là biến năng lực ngày càng cao của mô hình thành lợi thế lâu dài cho những người bảo vệ Internet. Nghiên cứu này cho thấy năng lực an ninh mạng ngày càng cao của các mô hình tiên phong có thể được dùng để tìm kiếm hiệu quả các lỗ hổng trong phần mềm phức tạp, chẳng hạn như nhân Linux. Việc tăng cường bảo mật cho các dự án phần mềm trọng yếu như Linux và các dự án nguồn mở khác có thể bảo vệ nhiều hệ thống và người dùng phụ thuộc vào các dự án này.
Thông qua Patch the Planet, một sáng kiến thuộc Daybreak, chúng tôi hướng tới mở rộng nghiên cứu này sang nhiều dự án phần mềm trọng yếu hơn, đồng thời cùng các nhà bảo trì và đối tác bảo mật phát triển khả năng vá lỗi tự động đáng tin cậy. Chúng tôi muốn từng bước thu hẹp cơ hội của kẻ tấn công và nâng chi phí tìm kiếm, khai thác lỗ hổng cho đến khi lợi ích kỳ vọng không còn xứng đáng với công sức tấn công.
Mỗi thế hệ mô hình cần giúp chúng ta xây dựng phần mềm mà thế hệ tiếp theo khó xâm phạm hơn. Chúng tôi sẽ tiếp tục nỗ lực xây dựng một Internet an toàn, nơi ai cũng có thể thỏa sức sáng tạo.
