- 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
- 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
pagehide và garbage collection gây UAF trong setter thuộc tính của phần tử <object>
- 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
- 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=0 trong bảng HTML, thêm >65535 hà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
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
1 bình luậ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ị