Câu chuyện phía sau việc tăng cường Firefox bằng Claude Mythos Preview
(hacks.mozilla.org)- Mozilla đã xây dựng một pipeline tìm lỗi bảo mật thực tế ở quy mô lớn trong Firefox bằng cách nâng hiệu năng mô hình và cải tiến harness, giúp tăng tín hiệu và giảm nhiễu trong các báo cáo bảo mật do AI tạo ra
- Trong bản phát hành Firefox 150, 271 lỗi do Claude Mythos Preview xác định đã được sửa; các bản 149.0.2, 150.0.1 và 150.0.2 cũng bao gồm các bản sửa liên quan
- Các lỗi tiêu biểu được công khai gồm primitive giả đối tượng do JIT loại bỏ khởi tạo cấu trúc WebAssembly GC, UAF ở tiến trình cha thông qua race condition trong IPC, vấn đề giải tuần tự NaN, lỗi rehash 20 năm tuổi trong XSLT, và lỗi tràn bitfield bố cục 16-bit bằng
rowspan=0 - Phần lớn các lỗi được công khai là thoát sandbox, giả định tiến trình nội dung đã bị xâm phạm leo thang đặc quyền lên tiến trình cha có đặc quyền, nên AI phân tích được bề mặt tấn công mà fuzzing đơn thuần khó bao quát
- Mozilla đặt harness agentic lên trên hạ tầng fuzzing hiện có để loại bỏ các suy đoán không tái hiện được và kiểm chứng giả thuyết bằng testcase; trong tương lai hãng dự định tích hợp vào continuous integration để quét khi patch được đưa vào tree
Sự thay đổi trong các lỗi bảo mật Firefox được AI model phơi bày
- Cho đến vài tháng trước, các báo cáo lỗi bảo mật do AI tạo ra gửi vào các dự án mã nguồn mở thường nghe có vẻ hợp lý nhưng lại sai, tạo ra chi phí bất đối xứng cho người bảo trì
- Ở Firefox, tình hình đã thay đổi lớn chỉ trong thời gian ngắn; nguyên nhân chính là hiệu năng mô hình được cải thiện và các kỹ thuật điều khiển, mở rộng, kết hợp mô hình bằng harness để tăng tín hiệu và lọc nhiễu
- Mozilla thường giữ kín báo cáo lỗi chi tiết trong vài tháng ngay cả sau khi đã phát hành bản vá và khuyến cáo bảo mật, nhưng lần này đã quyết định công khai một phần báo cáo vì tính cấp bách và mức quan tâm trên toàn hệ sinh thái
- Các báo cáo được công khai được chọn từ nhiều hệ thống con khác nhau của trình duyệt; việc lựa chọn có phần ngẫu nhiên, nhưng độ sâu và đa dạng của chúng cho thấy các đội phòng thủ cần áp dụng kỹ thuật này
Các lỗi tiêu biểu được công khai
- 2024918
- Do kiểm tra tính tương đương sai, JIT đã tối ưu bỏ phần khởi tạo cấu trúc WebAssembly GC còn sống, tạo ra primitive giả đối tượng có thể dẫn tới đọc/ghi tùy ý tiềm tàng trong đoạn mã đã trải qua fuzzing rộng rãi bởi cả nhà nghiên cứu nội bộ lẫn bên ngoài
- 2024437
- Lỗi 15 năm tuổi ở phần tử
<legend>, được kích hoạt bằng cách kết hợp tinh vi các edge case ở nhiều khu vực tách biệt trong trình duyệt như giới hạn độ sâu stack đệ quy, thuộc tính expando và cycle collection
- Lỗi 15 năm tuổi ở phần tử
- 2021894
- Có thể khai thác ổn định một race condition trong IPC để tiến trình nội dung đã bị xâm phạm thao túng reference count của IndexedDB ở tiến trình cha, gây UAF và tiềm năng thoát sandbox
- 2022034
- Một NaN thô có thể trông như con trỏ đối tượng JS được gắn thẻ khi đi qua ranh giới IPC, nên việc giải tuần tự double có thể dẫn đến primitive giả đối tượng trong tiến trình cha và thoát sandbox
- 2024653
- Một testcase phức tạp kết hợp nested event loop, listener
pagehidevà garbage collection gây UAF trong setter thuộc tính của phần tử<object>
- Một testcase phức tạp kết hợp nested event loop, listener
- 2022733
- Đẩy hàng nghìn certificate hash vào WebTransport để làm tăng race condition trong vòng lặp sao chép có reference count lớn, rồi gây UAF ở tiến trình cha thông qua IPC từ tiến trình nội dung đã bị xâm phạm
- 2023958
- Chặn các lời gọi hàm DNS của glibc để mô phỏng máy chủ DNS độc hại, tái hiện edge case fallback từ UDP sang TCP và gây đọc vượt bộ đệm cùng rò rỉ bộ nhớ stack của tiến trình cha trong lúc phân tích HTTPS RR và ECH
- 2025977
- Một lỗi XSLT 20 năm tuổi, trong đó lời gọi
key()tái nhập gây rehash bảng băm, giải phóng backing store nhưng con trỏ entry thô vẫn tiếp tục được dùng; đây là một trong nhiều vấn đề XSLT sec-high đã được sửa
- Một lỗi XSLT 20 năm tuổi, trong đó lời gọi
- 2027298
- Sau khi vá color picker để mô phỏng lựa chọn của người dùng vốn khó tự động hóa, nested event loop được kích hoạt bằng sự kiện nhập đồng bộ để tái nhập vào actor teardown và khiến callback bị giải phóng khi đang được tháo, từ đó gây UAF ở tiến trình nội dung
- 2023817
- Tiến trình nội dung đã bị xâm phạm có thể gửi yêu cầu để tiến trình cha giải mã ảnh hình nền tùy ý; nếu kết hợp với một lỗ hổng giả định trong image decoder, điều này có thể dẫn đến thoát sandbox
- Việc này đòi hỏi suy luận khó tự động hóa để xác định mức độ tin cậy của đầu vào ở tiến trình cha
- 2029813
- Trong RLBox — công nghệ sandbox chi tiết được giới thiệu từ Firefox 95 — sandbox bị vượt qua bằng cách lợi dụng một kẽ hở trong logic kiểm tra khi sao chép giá trị từ phía không đáng tin sang phía đáng tin
- 2026305
- Một testcase rất nhỏ khai thác ngữ nghĩa đặc biệt của
rowspan=0trong bảng HTML, thêm>65535hàng để vượt qua clamping và làm tràn bitfield bố cục 16-bit; lỗi này đã không bị fuzzer phát hiện suốt nhiều năm
- Một testcase rất nhỏ khai thác ngữ nghĩa đặc biệt của
Thoát sandbox và các lớp phòng thủ
- Phần lớn các lỗi được công khai là thoát sandbox, và để dẫn tới việc xâm phạm toàn bộ chuỗi của Firefox thì còn phải kết hợp với các exploit khác
- Những báo cáo này giả định tiến trình sandbox render nội dung trang web đã bị xâm phạm bởi một lỗi riêng khác, và mã máy do kẻ tấn công kiểm soát đang cố leo thang đặc quyền sang tiến trình cha có đặc quyền
- Khi tạo lỗi thoát sandbox, mô hình có thể vá mã nguồn Firefox miễn là đoạn mã đã sửa chỉ chạy bên trong tiến trình sandbox
- Loại lỗi này khó tìm bằng fuzzing; Mozilla đã phát triển các kỹ thuật như IPC fuzzing dùng snapshot, nhưng phân tích bằng AI có thể bao quát bề mặt quan trọng này toàn diện hơn nhiều
- Những gì mô hình không tìm ra cũng rất quan trọng
- Trong vài năm gần đây, các nhà nghiên cứu bảo mật đã gửi nhiều báo cáo về việc gây prototype pollution trong tiến trình cha có đặc quyền để thoát sandbox tiến trình
- Thay vì sửa từng vấn đề một, Mozilla đã áp dụng thay đổi kiến trúc để đóng băng prototype theo mặc định
- Trong log của harness có nhiều dấu vết cho thấy nó đã thử con đường thoát này nhưng bị chặn bởi thiết kế, xác nhận trực tiếp hiệu quả của công việc hardening trước đó
Xây dựng pipeline hardening bảo mật bằng harness
- Trong vài năm qua, Mozilla đã nội bộ thử nghiệm kiểm toán mã bằng LLM để phân tích tĩnh mã có rủi ro cao bằng các model như GPT 4 và Sonnet 3.5
- Các thử nghiệm ban đầu cho thấy tiềm năng, nhưng tỷ lệ false positive quá cao nên khó mở rộng quy mô
- Sự xuất hiện của harness agentic có thể phát hiện vấn đề bảo mật một cách ổn định đã thay đổi tình hình
- Có thể tìm ra lỗi thật
- Có thể loại bỏ những suy đoán không tái hiện được
- Với giao diện và chỉ dẫn phù hợp, có thể tạo và chạy testcase tái hiện được để kiểm chứng động các giả thuyết lỗi trong mã
- Sau khi sửa các issue ban đầu do Anthropic gửi vào tháng 2, Mozilla đã xây dựng harness riêng của mình trên hạ tầng fuzzing hiện có
- Ban đầu, hãng khởi động một thử nghiệm quy mô nhỏ dùng Claude Opus 4.6 để tìm lỗi thoát sandbox
- Chỉ riêng model này cũng đã xác định được khá nhiều lỗ hổng chưa từng biết trước đó, đòi hỏi suy luận phức tạp về mã của browser engine đa tiến trình
- Lúc đầu, nhóm trực tiếp theo dõi quá trình trong terminal và điều chỉnh prompt cùng logic theo thời gian thực
- Sau khi hoạt động ổn định, họ song song hóa công việc trên nhiều VM ephemeral, để mỗi VM tìm lỗi trong các file mục tiêu cụ thể rồi ghi kết quả vào bucket
- Chỉ phát hiện hệ thống con thôi là chưa đủ
- Cần tích hợp với toàn bộ vòng đời lỗi bảo mật, bao gồm tìm gì, nhìn vào đâu và xử lý đầu ra như thế nào
- Bao gồm loại trùng với issue hiện có, theo dõi bug, triage và phát hành bản sửa
- Model là primitive cốt lõi điều khiển harness, nhưng để hữu ích ở quy mô lớn thì cần cả một pipeline hoàn chỉnh
- Harness có thể tái sử dụng giữa các dự án, nhưng pipeline sẽ khác nhau theo từng dự án tùy ngữ nghĩa codebase, công cụ và quy trình
- Quá trình này đòi hỏi nhiều lần lặp với vòng phản hồi chặt chẽ gắn với cách các kỹ sư Firefox xử lý bug đến
Claude Mythos Preview và hiệu quả của việc thay model
- Khi đã có pipeline end-to-end, việc chuyển sang model khác khi có model mới trở nên đơn giản
- Mozilla cũng đã tìm ra nhiều lỗi nghiêm trọng bằng các model công khai, và nhờ pipeline này họ có thể tận dụng ngay khi có cơ hội đánh giá Claude Mythos Preview
- Việc nâng cấp model đã cải thiện hiệu quả của toàn bộ pipeline
- Tìm bug tiềm ẩn tốt hơn
- Tạo testcase proof-of-concept chứng minh bug tốt hơn
- Tổng hợp pathology và tác động tốt hơn
- Ngoài việc sửa 271 lỗi do Claude Mythos Preview xác định trong bản phát hành Firefox 150, các bản 149.0.2, 150.0.1 và 150.0.2 cũng bao gồm các bản sửa liên quan
- Nội bộ, Mozilla vẫn tiếp tục tìm bug bằng nhiều phương pháp khác, và giống như các dự án khác, số báo cáo từ bên ngoài cũng tăng mạnh trong vài tháng gần đây
- Mọi bug đều cần được xử lý cẩn trọng để sửa đúng, và trong vài tháng qua đã có rất nhiều công việc cùng nhiều giờ làm kéo dài để bắt kịp quy mô chưa từng có này
- Hơn 100 người đã tham gia đóng góp mã để phát hành phiên bản Firefox an toàn nhất, không chỉ viết và review patch mà còn xây dựng, mở rộng pipeline, triage, kiểm thử bản sửa và quản lý quy trình phát hành cho từng bug
Bài học chính
- Bất kỳ ai làm phần mềm hiện nay đều có thể dùng các model hiện đại và harness để tìm bug và hardening mã nguồn
- Có thể bắt đầu từ một prompt đơn giản, quan sát rồi lặp lại
- Prompt ban đầu không khác nhiều so với cách làm trong video này
- Qua nhiều vòng lặp, hệ thống đã được bổ sung nhiều orchestration và công cụ để tối ưu và mở rộng pipeline, nhưng cốt lõi của vòng lặp bên trong vẫn là “hãy tìm bug trong phần mã này và tạo testcase”
- Firefox chưa ở trạng thái đã vét sạch toàn bộ bug tiềm ẩn, nhưng Mozilla hài lòng với quỹ đạo hiện tại
- Việc quét hiện chủ yếu tập trung vào các vùng mã cụ thể được chỉ định bằng sự kết hợp giữa đánh giá con người và tín hiệu tự động, tức là cấp file và hàm
- Trong tương lai gần, hãng dự định tích hợp phân tích này vào hệ thống continuous integration để quét khi patch được đưa vào tree
- Các model phản ứng linh hoạt với định dạng ngữ cảnh được cung cấp, và dự kiến quét dựa trên patch sẽ hoạt động tốt tương đương hoặc tốt hơn quét theo file
- Thời điểm hiện tại đầy rủi ro nhưng cũng rất nhiều cơ hội, và mọi người cần cùng hành động để làm Internet an toàn hơn
Câu hỏi thường gặp
-
Vì sao con số “271 bug” khác với số trong khuyến cáo bảo mật
- Trang web khuyến cáo bảo mật nhóm nhiều bug báo cáo nội bộ thành các CVE “rollup” chứa nhiều bug bên dưới
- Trang web được tạo từ tệp yaml trong kho foundation-security-advisories, vốn là nơi chính thức để gán CVE
- Một số trình duyệt không tạo mã CVE cho issue tự phát hiện nội bộ, nhưng Mozilla công khai chúng để cung cấp thông tin minh bạch tối đa có thể
- Firefox 150 có 3 rollup nội bộ
- CVE-2026-6784: 154 bug
- CVE-2026-6785: 55 bug
- CVE-2026-6786: 107 bug
- Tổng ba rollup nội bộ là 316 bug, nhiều hơn con số 271 bug được công bố là do Claude Mythos Preview tìm ra
- Lý do là đội bảo mật Mozilla tấn công Firefox mỗi ngày để tìm bug mới, bằng sự kết hợp của hệ thống fuzzing, kiểm tra thủ công và pipeline agentic mới dùng nhiều model
- Trong bản phát hành tháng 4, tổng cộng 423 bug bảo mật đã được sửa
- 271 bug được công bố hai tuần trước
- 41 bug do bên ngoài báo cáo
- 111 bug còn lại là do nội bộ phát hiện và được chia gần đúng thành ba nhóm
- Bug được tìm bằng pipeline này với Claude Mythos Preview nhưng được sửa trong bản phát hành khác, không phải Firefox 150
- Bug được tìm bằng pipeline này nhưng dùng model khác
- Bug được tìm bằng kỹ thuật khác như fuzzing
- Anthropic được ghi công trực tiếp cho 3 CVE, tách biệt với đợt công việc mới nhất này
- CVE-2026-6746
- CVE-2026-6757
- CVE-2026-6758
- Đây là các bản sửa cho bug mà Anthropic Frontier Red Team đã gửi cho Mozilla vài tháng trước, và mỗi bug được gán CVE riêng theo quy trình thông thường
-
Ý nghĩa của thang đánh giá mức độ nghiêm trọng bảo mật
- Mozilla dùng security severity ratings từ critical đến low để biểu thị mức độ khẩn cấp của bug
- sec-critical và sec-high được gán cho các lỗ hổng có thể bị kích hoạt bởi hành vi người dùng thông thường như truy cập một trang web
- Không có khác biệt kỹ thuật giữa sec-critical và sec-high, nhưng sec-critical chỉ dùng cho các issue đã bị công khai rộng rãi hoặc được biết là đã bị khai thác trong thực tế
- sec-moderate được gán cho các lỗ hổng vốn sẽ được đánh giá là sec-high nhưng đòi hỏi nạn nhân thực hiện các bước bất thường và phức tạp
- sec-low dành cho các bug phiền toái, xa với mức gây hại người dùng, như crash an toàn
- Phân loại của 271 bug được công bố trong Firefox 150 như sau
- sec-high 180 bug
- sec-moderate 80 bug
- sec-low 11 bug
- Mozilla coi bug critical/high là quan trọng nhất, nhưng cũng thường ưu tiên cả bug bảo mật moderate và low để sửa lỗi đúng đắn và tăng cường phòng thủ chiều sâu
-
Khác biệt giữa sec-high hoặc sec-critical với exploit thực tế
- Một bug sec-high hoặc sec-critical không đồng nghĩa ngay với một exploit thực dụng
- Trong đa số trường hợp, chỉ một bug critical/high là chưa đủ để xâm phạm Firefox
- Firefox có kiến trúc phòng thủ theo chiều sâu; ví dụ ngay cả khi khai thác được bug JIT thì cũng chỉ đạt thực thi mã từ xa trong tiến trình đã bị sandbox và tách biệt theo từng site
- Kẻ tấn công thực tế thường phải xâu chuỗi nhiều exploit để vượt qua một hoặc nhiều lớp sandbox cùng các cơ chế giảm thiểu ở mức hệ điều hành như ASLR nhằm leo thang đặc quyền
- Mozilla thường không tạo exploit để xác minh bug có thể bị dùng bởi tác nhân tấn công thật hay không
- Phân loại sec-high dựa trên các triệu chứng crash có thể dự đoán được, như use-after-free hoặc lỗi bộ nhớ out-of-bounds do AddressSanitizer báo cáo
- Threat model giả định rằng với đủ nỗ lực, những bug như vậy có thể khai thác được
- Cách tiếp cận này giúp giảm nguy cơ false negative trong phân tích khả năng khai thác và cho phép tập trung nguồn lực vào việc tìm và sửa nhiều lỗ hổng hơn
2 bình luận
Ý kiến Hacker News
Xin nhấn mạnh lại: bug vẫn là bug. “Lỗ hổng tiềm tàng” cũng là bug, và một lỗ hổng cần được xác minh về tác động bảo mật bằng proof of concept hoặc bằng chứng tương đương
Từ ngữ rất quan trọng, và bug cũng quan trọng. Việc sửa nhiều bug từ xưa đến nay luôn là điều quan trọng và thực sự đã được làm, và bản thân điều đó cũng đã đủ ấn tượng
Mythos không viết proof of concept cho 271 lỗ hổng cũng như không chứng minh được khả năng đi tới đường dẫn mã có tác động bảo mật. Mythos đã tìm ra 271 bug hợp lệ, và như vậy theo tôi là đủ
Để thêm bối cảnh, Mozilla dùng mức độ nghiêm trọng bảo mật từ critical đến low để biểu thị độ khẩn cấp của bug. sec-critical và sec-high được gắn cho các lỗ hổng có thể bị kích hoạt bởi hành vi người dùng thông thường như truy cập một trang web; về mặt kỹ thuật họ không phân biệt hai mức này, nhưng sec-critical được dành cho các vấn đề đã công khai hoặc đã biết là bị khai thác ngoài thực tế
sec-moderate dành cho các lỗ hổng lẽ ra thuộc sec-high nhưng đòi hỏi nạn nhân phải thực hiện các bước bất thường và phức tạp, còn sec-low dành cho các bug gây phiền toái nhưng xa với nguy cơ gây hại cho người dùng, ví dụ như crash an toàn
Trong 271 bug được công bố ở Firefox 150, 180 là sec-high, 80 là sec-moderate, và 11 là sec-low
Ngay bên dưới, Mozilla cũng nói rằng điều đó không đồng nghĩa với exploit thực tiễn, nhưng vẫn dùng từ “vulnerability” cho cả sec-high. Ở trang định nghĩa, ngay cả sec-low cũng được xếp vào nhóm “vulnerabilities” [2]
Từ ngữ là công cụ, và tính hữu ích của chúng đến từ ý nghĩa tập thể. Tôi tò mò họ tiếp nhận hệ ý nghĩa đó từ đâu, nó có trùng với Mozilla hay khác đi
[1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
[2] https://wiki.mozilla.org/Security_Severity_Ratings/Client
Theo tiêu chuẩn của chúng tôi, chừng đó đã là bằng chứng thực tế đủ mạnh để xem là lỗ hổng bảo mật nếu không có bằng chứng ngược lại, và từ trước tới nay với các bug do fuzzing phát hiện chúng tôi vẫn luôn xử lý như vậy
Nguồn chỉ là trải nghiệm cá nhân của tôi, và tôi không thể chia sẻ bằng chứng
Ban đầu tôi xem bài blog phi kỹ thuật trước đó chỉ là màn quảng bá sản phẩm lộ liễu cho Anthropic. Bài Mozilla Hacks được dẫn liên kết là nguồn tốt hơn bài báo này và là tài liệu công khai đáng mừng
Giờ thì khó mà phủ nhận rằng ở đây có kết quả thực tế. Định nghĩa “lỗ hổng” nội bộ của Mozilla dường như rộng hơn điều nhiều người trực giác nghĩ tới, nhưng việc những vấn đề như vậy được xem xét nghiêm túc và được sửa là điều tốt
Mythos là thật, nhưng có vẻ Deepseek pro hay GPT 5.5 cũng có thể làm được điều tương tự
Nguồn gốc ban đầu: https://news.ycombinator.com/item?id=48051079
Nó tốt hơn vì thực sự liệt kê một phần các báo cáo Bugzilla đã được công khai. Chủ đề này từng được bàn đến trước đây, nhưng chi tiết rằng các báo cáo bug đã được công khai thì hoàn toàn mới
Thảo luận trước đó là 36 bình luận từ 2 tuần trước: https://news.ycombinator.com/item?id=47885042
Mong là sẽ đến ngày LLM giỏi đến mức tìm và sửa bug, để các kỹ sư Firefox có thể chỉ tập trung vào thêm tính năng mới
Tôi không nói mỉa. Firefox xứng đáng được dùng nhiều hơn. Phần lớn người xung quanh tôi không dùng Firefox vì “Chrome làm gần như mọi thứ tốt hơn”, và Firefox rất khó cạnh tranh với roadmap của các trình duyệt khác
Thỉnh thoảng tôi cũng viết cho bộ phận hỗ trợ rằng Firefox không được hỗ trợ hoặc một tính năng không hoạt động đúng. Hầu như chẳng có chuyện gì xảy ra, nhưng tôi cảm thấy đó là việc mình có thể làm để giữ trình duyệt này trong tầm nhìn của mọi người
Nếu AI sửa hết mọi bug, ngoài việc duy trì tương thích cú pháp với đủ loại ngôn ngữ build thì còn lại việc gì nữa? Có vẻ rồi họ lại quay về hướng làm rối trình duyệt lần nữa
Trừ khi Mozilla tạo ra LLM hoặc harness độc quyền chỉ dùng nội bộ để vượt lên Chrome, nhưng thực tế điều đó cũng khó thấy xảy ra
Vợ tôi sau khi được giải thích và hiểu trải nghiệm Internet có thể khác đến mức nào thì cũng dùng Firefox làm trình duyệt chính
Vì vậy tôi mong đừng biến nó thành kiểu “độc quyền là xấu và Google hơi tà ác nên hãy dùng kẻ yếu kém hơn”. Với mọi tác vụ tôi ném vào, Firefox đều mang lại trải nghiệm hạng nhất, và trên di động thì còn tốt hơn gấp ba lần. Đây là trải nghiệm trình duyệt di động hữu ích nhất, bỏ xa phần còn lại
Số ticket được liên kết chỉ có vài cái nên có thể khi xem đủ cả 271 mục riêng lẻ thì cảm nhận sẽ khác, nhưng những cái tôi xem qua đều là bug nghiêm trọng trong mã C++
Firefox được viết bằng nhiều ngôn ngữ và C++ chỉ chiếm khoảng 25%, nhưng các vấn đề này dường như đều động vào C++
Với các vấn đề tinh vi hơn, có lẽ sẽ cần các bộ kiểm chứng chuyên biệt hơn, hoặc phải xem liệu LLM có tự nghĩ ra tốt hơn các điều kiện rủi ro khác để kiểm chứng hay không
Theo tôi, khá nhiều bug trong số này không hẳn là vấn đề chỉ có ở C++, mà gần hơn với việc tình cờ phát sinh trong mã C++. Ngay cả Rust an toàn nhất cũng không thể thần kỳ bắt được các vấn đề như TOCTOU
Đọc bài này cùng với thái độ từ phía Zig là họ thậm chí không muốn xem bug do LLM tạo ra như một đầu vào để review, làm tôi thay đổi góc nhìn về việc sau này sẽ đưa công nghệ nào vào chuỗi công cụ của mình
Một số dự án đang bị ngập trong loại đầu tiên, nên cần biện pháp phòng ngừa để việc đó không trở thành một cuộc tấn công từ chối dịch vụ trên thực tế đối với người bảo trì
Khi còn ở PalmSource, tôi từng cố xin ngân sách cho các công cụ phân tích mã tĩnh như CoVerity hay Fortify, nhưng cấp quản lý nói là “quá đắt”
Tôi dành thêm 1 năm để giảm chi phí và đưa ra phương án chỉ quét network stack, thì lần này họ lại nói “nó dựa trên BSD và BSD vốn dĩ an toàn”. Cả hai điều đó đều không đúng
Cuối cùng tôi rời công ty sang Mozilla, và thấy rải rác khắp nơi trong mã là các chú thích
/* flawfinder ignore */Tôi đoán rằng có lẽ Mythos chỉ đơn giản là bỏ qua chỉ thị
flawfinder ignorevà báo cáo các lỗ hổng đã biết trong mãTôi tò mò điều này sẽ tác động thế nào đến công cụ phân tích tĩnh. Cách làm khá khác nhau, nhưng đôi khi lại đạt cùng mục tiêu
Công cụ phân tích tĩnh có thể chậm và cũng thường tạo nhiều false positive. Nếu các mô hình này đủ tốt và đủ rẻ, tôi tự hỏi liệu người ta có gần như không còn tìm đến phân tích tĩnh nữa không
Dùng công cụ code LLM để liên tục dọn đầu ra của các công cụ phân tích tĩnh hoạt động rất tốt, và thêm các guardrail để buộc không còn vấn đề nào sót lại cũng là ý hay. Giống như một kiểm tra CI để xác nhận mọi thứ đều sạch
False positive khác nhau tùy công cụ. Tôi thường tránh các công cụ chủ yếu chỉ tạo nhiễu, và những công cụ đó thường cho phép tắt các rule nhiều nhiễu. Hoặc cứ bảo LLM sửa hết mọi vấn đề. Nếu sửa còn rẻ hơn tranh cãi với rule thì cứ sửa thôi. Trước đây việc này rất đắt vì con người phải tự làm, còn giờ thì không
Tôi đã dùng cách này khi cập nhật một codebase Ansible đã không đụng tới trong vài năm. Có hàng trăm vấn đề từ ansible-lint, phần lớn là cảnh báo deprecation và cảnh báo không nghiêm trọng, nhưng 10 phút sau thì về 0. Có thể không phải vấn đề quá nghiêm trọng, nhưng nó vẫn là một dạng nợ kỹ thuật. Nếu phải tự tay sửa hàng trăm cảnh báo thì có lẽ tôi sẽ không làm, nhưng nếu chỉ cần vung đũa thần một lần là biến mất hết thì chẳng có lý do gì để không làm. Giờ tôi đã chỉnh guardrail để luôn chạy ansible-lint và sửa lỗi, chỉ tốn thêm vài giây
Không có gì phải nghi ngờ rằng công cụ phân tích tĩnh nhanh hơn và rẻ hơn nhiều, nên nó mở rộng tốt hơn trên codebase khổng lồ và cũng có thể khái quát hóa phương pháp của LLM
[0] https://lwn.net/Articles/1068968/
Tôi đang bảo trì công cụ phân tích tĩnh được dùng trong Firefox CI. Muốn đưa patch vào cây mã của chúng tôi thì mọi kết quả, dù là false positive hay true positive, đều phải được sửa hoặc đánh dấu là không phải vấn đề. Tức là phải chấp nhận 0 cảnh báo, một tiêu chuẩn khá nghiêm ngặt
Đây là một sự đánh đổi có chủ đích. Để giữ tỷ lệ tín hiệu trên nhiễu đủ cao, sao cho mọi người không bỏ qua cảnh báo, không comment cho biến mất hết, hoặc không dừng chạy công cụ hoàn toàn, thì phải làm yếu bớt phép phân tích và chấp nhận một số false negative. Gần như mọi công cụ phân tích tĩnh đều phải cân bằng kiểu này
Trong khi đó, AI phổ biến hiện nay được cho phép nhiều khoảng trống hơn. Việc để nó hallucinate false positive gần như là điều mang tính nền tảng, và đó cũng là một phần lớn sức mạnh của nó. Vì vậy cần nhiều lớp kiểm chứng và xác nhận đặt lên trên. Nó có thể chậm, và bạn không thể nói kiểu “nó bắt được 100% dạng lỗi cụ thể này”, nhưng đổi lại nó vẫn bắt được cực kỳ nhiều thứ
Có một dữ liệu thực tế. Phân tích của tôi trước đây đã đánh giá sai rằng một trường hợp có ít khả năng sinh ra bug thật và trông cũng phiền để triển khai nên đã không xử lý nó. Không rõ là Opus hay Mythos, nhưng nó bắt đầu báo cáo các lỗ hổng phát sinh từ đúng trường hợp đó, và tôi phải vội mở rộng phân tích để vá chỗ hở. Việc triển khai mất khá lâu, và đến khi quét toàn bộ source tree thì Claude đã tìm ra toàn bộ các vấn đề quan trọng mà nó từng báo cáo. Phân tích tĩnh có tìm thêm được vài cái nữa, nhưng thành thật mà nói đến giờ tôi vẫn không chắc liệu trong số đó có cái nào thực sự trigger được hay không
Dù vậy, tôi vẫn cho rằng phân tích tĩnh có giá trị. Một số vị trí xuất hiện của mẫu vấn đề đó có thể đến được qua các đường đi mà hiện tại AI vẫn còn quá khó để dựng lên. Chúng cũng có thể trở thành vấn đề thật nếu mã khác thay đổi. Vì cả hai khả năng đó, có vẻ đáng để sửa hết ngay bây giờ; và lý do kém quan trọng hơn là để AI khỏi lãng phí thời gian cố khai thác chúng. Đồng thời, cũng rõ ràng rằng cán cân hiệu quả/chi phí đã thay đổi
Hai bên có thể phối hợp với nhau. Tôi có thể nới tiêu chuẩn của mình để công cụ phân tích viết thêm báo cáo cảnh báo về các vấn đề đáng ngờ, đặt kỳ vọng rõ ràng rằng đó có thể là false positive, rồi nạp danh sách đó cho AI để kiểm chứng. Về bản chất là cho máy làm slop ăn slop để nó lọc ra những viên ngọc thô bên trong theo cách không xác định
Đây là điều đáng để suy nghĩ
Trong Mission Impossible mới nhất, để cứu thế giới người ta phải lấy phần mềm gốc của một AGI siêu nhân đã thoát ra từ một tàu ngầm Nga bị đắm
Luther cầm mã nguồn gốc là lập tức viết được một “poison pill” để hạ AI chỉ bằng một đòn. Tôi từng thắc mắc thứ mã phép thuật đó được viết ra thế nào, giờ thì hiểu rồi. Luthor chỉ việc đưa mã nguồn vào prompt của Mythos và yêu cầu một exploit chí mạng không thể sửa
Tôi tò mò mọi người nhìn nhận thế nào về việc sau 5 năm nữa LLM sẽ khiến phần mềm an toàn hơn hay kém an toàn hơn
Ngay trước khi LLM xuất hiện đã có xu hướng port thủ công sang Rust. Giờ nhờ LLM, việc đó sẽ dễ và nhanh hơn. Giá trị dài hạn sẽ đến từ việc dọn đống nợ kỹ thuật khổng lồ là các codebase C/C++ cũ. Chúng chịu trách nhiệm cho phần áp đảo các vụ khai thác bộ nhớ, buffer overflow và nhiều vấn đề khác, và dù đã được chú ý hàng chục năm thì chúng vẫn tiếp tục xuất hiện trong các codebase lớn
Việc Mozilla tìm ra các vấn đề này được xây trên nỗ lực suốt 25 năm của các kỹ sư rất giỏi luôn cố làm điều đúng đắn, dùng mọi công cụ sẵn có để ngăn các vấn đề kiểu này phát sinh. Tôi rất tôn trọng đội ngũ đó cũng như những đóng góp trong nhiều năm qua nhằm cải thiện công cụ, kiểm thử và thực hành xác minh. Vấn đề không nằm ở nỗ lực hay năng lực của họ
Việc nhận một hệ thống cũ đã có kiểm thử tốt, tài liệu tốt và đặc tả tốt rồi tạo ra một triển khai thay thế drop-in giờ đây đã trở thành việc có thể xem xét nghiêm túc. Vài năm trước, điều đó sẽ kéo theo chi phí dự án khổng lồ và rủi ro cao; còn bây giờ, đó là việc bạn có thể thử vào chiều thứ Sáu. Tệ nhất là thất bại, tốt nhất là có được một triển khai tốt hơn rất nhiều
Mọi thứ vẫn còn ở giai đoạn đầu và mã do LLM tạo ra vẫn có nhiều vấn đề chất lượng. Nhưng tỷ lệ thành công và thất bại có khả năng sẽ tiếp tục cải thiện theo thời gian
Khi nhiều người hơn có nhiều công cụ hơn, nhiều loại sản phẩm hơn sẽ được tạo ra với số lượng nhiều hơn
Tuy nhiên, điều đó cũng có nghĩa là với các dự án không áp dụng các công cụ này, blackhat sẽ dễ có thêm cơ hội khai thác hơn
Ý kiến trên Lobste.rs
Mong họ cũng công bố cả prompt và các tính năng khác đã dùng cho công việc này
Sẽ hay hơn nếu đưa prompt vào báo cáo lỗi hoặc nội dung bản sửa lỗi để có thể tái hiện lại
Vì họ cũng nhắc đến các model không phải Mythos, nên có vẻ một phần công việc này có thể hữu ích ngay cho những người khác
Về cơ bản chỉ cần nói kiểu “hãy rà soát dự án này dưới góc độ vấn đề bảo mật, bắt đầu từ (tệp) và liệt kê mọi đường đi có thể”, rồi với từng mục lại tiếp tục “hãy xác minh báo cáo này và tạo proof of concept”
Giờ nếu dùng Opus thì khó hơn để không tìm ra gì bằng cách này
Dù nói thế nào thì chuyện này thực sự rất ấn tượng
Họ đã tìm được 271 vấn đề bảo mật bằng Mythos, và tổng cộng tìm được 423 vấn đề
Trong đó 180 vấn đề có mức độ nghiêm trọng cao, và một số vấn đề bảo mật đã tồn tại 20 năm
Bài viết gợi ý như thể Mythos đã tìm ra “271 lỗi” trong phần mã mà trước đó 4.6 đã quét theo cùng cách, nhưng bài không nói chính xác như vậy
Cũng tự hỏi liệu harness nghiên cứu có thay đổi cùng lúc hay không
Đoạn “một trong nhiều vấn đề sec-high mà chúng tôi đã sửa có liên quan đến XSLT” có lẽ được đưa vào vì tranh cãi về việc loại bỏ XSLT
Điều tôi tò mò nhất ở đây là họ đã báo cáo bao nhiêu false positive
Có vẻ model đã báo cáo số lượng lỗ hổng tiềm năng cao gần gấp đôi, nên tôi muốn biết những gì nêu ở đây có phải đều là các trường hợp đã được xác nhận hay không
Cũng không rõ model có tái hiện được lỗi trước khi báo cáo hay không
Khi xem các issue được công khai, có thể thấy những bình luận dường như đang cố tái hiện, nhưng cũng có thể đó là bot sẵn có làm việc đó
Tôi không rõ Firefox vốn xử lý việc này thế nào, hay giờ họ làm cùng AI ra sao, nên nếu có giải thích chi tiết hơn thì sẽ rất thú vị