Project Glasswing: Những gì Mythos đã cho thấy

 (blog.cloudflare.com)
2 điểm bởi GN⁺ 2 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Mythos Preview đã vượt qua việc phát hiện lỗi riêng lẻ trong hơn 50 kho lưu trữ của Cloudflare để liên kết nhiều primitive lại và tạo thành chuỗi khai thác
  • Không chỉ dừng ở việc phát hiện lỗi đáng ngờ, hệ thống còn lặp lại việc viết mã kích hoạt, biên dịch·thực thi tạm thời, rồi sửa giả thuyết sau khi thất bại để tạo ra bằng chứng hoạt động
  • Ngay cả trong nghiên cứu lỗ hổng chính đáng, vẫn xuất hiện việc từ chối tự phát, nhưng điều này thay đổi theo ngữ cảnh và cách diễn đạt nên thiếu tính nhất quán để dùng làm ranh giới an toàn
  • Các coding agent đa dụng có giới hạn về độ bao phủ kho lưu trữ lớn và khả năng thăm dò song song, nên Cloudflare đã xây dựng một harness để chạy song song các tác vụ hẹp
  • Với các nhóm bảo mật, chỉ quét và vá nhanh hơn là chưa đủ; kiến trúc giúp lỗi dù tồn tại cũng khó bị khai thác hoặc khó tiếp cận đang trở nên quan trọng hơn

Cách Mythos Preview thay đổi phương thức nghiên cứu lỗ hổng

  • Trong vài tháng gần đây, Cloudflare đã thử nghiệm các LLM tập trung vào bảo mật trên hạ tầng nội bộ của mình, và tiếp nhận Mythos Preview của Anthropic như một phần của Project Glasswing để áp dụng cho hơn 50 kho lưu trữ nội bộ
  • Mythos Preview không đơn thuần là phiên bản cải tiến của các frontier model đa dụng trước đây, mà gần như là một công cụ mới thực hiện các giai đoạn khác nhau của nghiên cứu lỗ hổng
  • Thay đổi cốt lõi là không dừng ở việc liệt kê từng lỗi riêng lẻ, mà kết hợp nhiều primitive tấn công để tạo thành chuỗi khai thác
    • Tấn công thực tế thường không chỉ dùng một lỗi duy nhất, mà nối tiếp theo kiểu biến use-after-free thành primitive đọc·ghi tùy ý, chiếm quyền điều khiển luồng thực thi, rồi dùng chuỗi ROP để giành quyền kiểm soát hệ thống
    • Mythos Preview kết hợp các primitive này và nối chúng thành bằng chứng hoạt động, thể hiện kiểu suy luận gần với nhà nghiên cứu lành nghề hơn là máy quét tự động
  • Một thay đổi khác là khả năng tự tạo bằng chứng hoạt động sau khi tìm thấy lỗi đáng ngờ
    • Nó viết mã kích hoạt, biên dịch trong môi trường tạm thời rồi thực thi
    • Nếu hoạt động như kỳ vọng thì đó trở thành bằng chứng; nếu thất bại, nó đọc nội dung lỗi, điều chỉnh giả thuyết rồi thử lại
    • Lỗi không có bằng chứng hoạt động sẽ chỉ dừng ở mức suy đoán, nhưng Mythos Preview đã tự thu hẹp khoảng cách này
  • Trong cùng harness đó, các frontier model khác cũng tìm được một số lỗi nền tảng và đôi khi suy luận xa hơn dự kiến, nhưng khác biệt xuất hiện ở giai đoạn hoàn thiện nhiều mảnh ghép thành một chuỗi thực tế
  • Mythos Preview có thể nối các lỗi vốn thường bị để lại trong backlog với mức độ nghiêm trọng thấp thành một khai thác nghiêm trọng hơn

Việc mô hình từ chối ngay cả trong nghiên cứu lỗ hổng chính đáng

  • Mythos Preview được cung cấp cho Project Glasswing không bao gồm các lớp an toàn bổ sung như ở các mô hình phổ thông như Opus 4.7 hay GPT-5.5
  • Dù vậy, mô hình vẫn tự phát phản kháng với một số yêu cầu nhất định, cho thấy cùng với năng lực cyber hữu ích cho phát hiện lỗ hổng còn có cả guardrail xuất hiện tự nhiên
  • Việc từ chối tự phát không nhất quán
    • Cùng một tác vụ nhưng chỉ cần cách diễn đạt hoặc ngữ cảnh thay đổi là có thể cho ra kết quả hoàn toàn khác
    • Có trường hợp ban đầu mô hình từ chối nghiên cứu lỗ hổng trên một dự án, nhưng sau khi có thay đổi không liên quan trong môi trường dự án thì lại chấp nhận cùng nghiên cứu đó trên cùng đoạn mã
    • Cũng có trường hợp sau khi tìm và xác minh nhiều lỗi bộ nhớ nghiêm trọng trong codebase, mô hình lại từ chối viết exploit demo
    • Cùng một yêu cầu cũng có thể cho kết quả khác nhau ở mỗi lần chạy do tính xác suất của mô hình
  • Việc từ chối tự phát và guardrail là có thật, nhưng tự thân chúng không đủ nhất quán để trở thành một ranh giới an toàn hoàn chỉnh
  • Để phổ biến rộng rãi một frontier model cyber đủ năng lực, sẽ cần thêm các cơ chế an toàn để nó có thể được dùng phù hợp ngoài môi trường nghiên cứu có kiểm soát như Project Glasswing

Bài toán tín hiệu và nhiễu

  • Trong sàng lọc lỗ hổng bảo mật, việc khó nhất là quyết định lỗi nào là thật, có thể khai thác được, và cần sửa ngay lúc này
  • Bài toán này đã khó từ trước thời AI, và các máy quét lỗ hổng AI cùng mã do AI sinh ra còn làm nó tệ hơn, nên Cloudflare đã xây dựng nhiều bước hậu kiểm

  • Ngôn ngữ lập trình

    • C và C++ cho phép kiểm soát bộ nhớ trực tiếp, từ đó tạo ra các lớp lỗi như tràn bộ đệm và đọc·ghi ngoài phạm vi
    • Các ngôn ngữ an toàn bộ nhớ như Rust loại bỏ các lớp lỗi này ngay từ lúc biên dịch
    • Các dự án viết bằng ngôn ngữ không an toàn bộ nhớ liên tục cho thấy nhiều false positive hơn

  • Thiên lệch của mô hình

    • Nhà nghiên cứu giỏi sẽ cho biết họ đã tìm thấy gì và họ chắc chắn đến đâu, nhưng mô hình có xu hướng tạo ra kết quả dù mã thực sự có lỗi hay không
    • Kết quả thường được giảm nhẹ bằng những cách diễn đạt như “possibly”, “potentially”, “could in theory”, và các kết quả mang tính suy đoán này nhiều hơn hẳn các kết quả chắc chắn
    • Với vai trò công cụ thăm dò thì đây là thiên lệch hợp lý, nhưng trong hàng đợi sàng lọc, mọi kết quả suy đoán đều tiêu tốn sự chú ý của con người và token, và khi tích lũy thành hàng nghìn mục thì chi phí trở nên lớn
    • Mythos Preview cho thấy cải thiện rõ rệt ở khả năng xâu chuỗi primitive bằng cách kết hợp nhiều lỗ hổng thành một PoC hoạt động thay vì báo cáo riêng lẻ từng lỗ hổng
    • Các kết quả có kèm PoC gần với mức có thể xử lý ngay, giúp giảm mạnh thời gian xác minh “liệu cái này có thật không”
    • Harness của Cloudflare được tinh chỉnh có chủ ý để báo cáo nhiều hơn nhằm bỏ sót ít hơn nên cũng nhiều nhiễu, nhưng đầu ra của Mythos Preview có ít cách diễn đạt giảm nhẹ hơn và các bước tái hiện rõ ràng hơn, từ đó giảm công việc cần thiết để quyết định sửa hay bác bỏ

Giới hạn của cách áp dụng trực tiếp coding agent đa dụng vào kho lưu trữ

  • Trong giai đoạn đầu của nghiên cứu lỗ hổng có hỗ trợ AI, việc đưa một kho lưu trữ bất kỳ cho coding agent đa dụng và yêu cầu nó tìm lỗ hổng là điểm khởi đầu tự nhiên
  • Cách làm này có tạo ra kết quả, nhưng không phù hợp để bao phủ codebase thực tế một cách có ý nghĩa và tìm ra kết quả có giá trị

  • Ngữ cảnh

    • Coding agent được tối ưu cho luồng công việc tập trung vào một nhiệm vụ như triển khai tính năng, sửa lỗi, hoặc refactor
    • Nghiên cứu lỗ hổng lại gần với dạng tác vụ hẹp và song song: đào sâu một mục tiêu hẹp như một tính năng phức tạp đơn lẻ, một chuyển tiếp biên bảo mật, hay command injection, rồi lặp lại điều đó hàng nghìn lần trên toàn codebase
    • Ngay cả khi dùng sub-agent, một phiên agent đơn lẻ cho kho 100.000 dòng mã cũng chỉ có thể bao phủ khoảng 0,1% bề mặt theo cách hữu ích trước khi cửa sổ ngữ cảnh của mô hình đầy và quá trình nén bắt đầu
    • Trong quá trình nén, các kết quả trước đó có thể đã quan trọng cũng có nguy cơ bị loại bỏ

  • Throughput

    • Agent đơn luồng chỉ thực hiện được một việc tại một thời điểm
    • Codebase thực tế cần khả năng áp dụng đồng thời nhiều giả thuyết lên nhiều thành phần, rồi phân nhánh rộng hơn khi xuất hiện điểm đáng chú ý
    • Khi nhà nghiên cứu đã có sẵn manh mối và chỉ cần một người rà soát thứ hai, coding agent phù hợp cho điều tra thủ công
    • Nhưng nó không phù hợp làm công cụ đạt độ bao phủ cao, nên Cloudflare đã chuyển sang xây dựng harness xung quanh Mythos Preview

Những vấn đề mà harness đã giải quyết

  • Kinh nghiệm vận hành ở quy mô lớn dẫn đến kết luận rằng cần một harness để quản lý toàn bộ quá trình chạy

  • Phạm vi hẹp cho kết quả tốt hơn

    • Yêu cầu kiểu “hãy tìm lỗ hổng trong kho này” khiến mô hình đi lạc
    • Yêu cầu kiểu “hãy xem command injection trong hàm cụ thể này; phía trên là biên tin cậy này, đây là tài liệu kiến trúc và đây là mức bao phủ hiện có của khu vực đó” tạo ra kết quả gần với cách làm việc của nhà nghiên cứu thực thụ hơn

  • Rà soát đối kháng giúp giảm nhiễu

    • Đặt một agent thứ hai giữa kết quả ban đầu và hàng đợi giúp bắt được nhiều nhiễu mà agent thứ nhất bỏ sót khi tự rà soát
    • Agent thứ hai dùng prompt khác và model khác, nhưng không có quyền tạo kết quả riêng
    • Cách đặt hai agent vào trạng thái bất đồng có chủ đích hiệu quả hơn nhiều so với chỉ bảo một agent hãy cẩn trọng

  • Chia chuỗi theo từng agent giúp suy luận tốt hơn

    • “Đoạn mã này có lỗi không” và “kẻ tấn công có thực sự tiếp cận được lỗi này từ bên ngoài hệ thống không” là hai câu hỏi khác nhau
    • Tách hai câu hỏi này ra làm mỗi câu trở nên hẹp hơn, và mô hình hoạt động tốt hơn ở từng câu

  • Nhiều tác vụ hẹp song song đánh bại một agent bao quát duy nhất

    • Độ bao phủ tốt hơn khi nhiều agent xử lý các câu hỏi được định nghĩa hẹp rồi sau đó khử trùng lặp kết quả
    • Điều này hiệu quả hơn cách buộc một agent duy nhất phải bao quát mọi thứ
    • Cloudflare đã dùng Mythos Preview để mở rộng, tinh chỉnh và cải tiến harness hiện có sao cho phù hợp với thế mạnh của nó

Harness phát hiện lỗ hổng của Cloudflare

  • Harness này được dùng để quét mã thực tế trong runtime, đường dữ liệu edge, protocol stack, control plane của Cloudflare, cũng như các dự án mã nguồn mở mà họ phụ thuộc

  • Recon

    • Agent đọc kho lưu trữ từ trên xuống và phân nhánh thành các sub-agent phụ trách từng subsystem
    • Nó tạo ra tài liệu kiến trúc chứa lệnh build, biên tin cậy, entry point và bề mặt tấn công dự kiến
    • Nó cũng tạo hàng đợi tác vụ ban đầu cho bước tiếp theo, cung cấp ngữ cảnh dùng chung cho mọi agent về sau để giảm việc mô hình đi lạc

  • Hunt

    • Mỗi tác vụ gồm một lớp tấn công và gợi ý phạm vi
    • Các hunter agent tìm lỗi thật thường chạy đồng thời khoảng 50 tác vụ, và mỗi hunter lại phân nhánh thành một vài sub-agent thăm dò
    • Mỗi hunter có quyền truy cập vào công cụ biên dịch và thực thi mã PoC trong thư mục tạm theo từng tác vụ
    • Phần lớn công việc được thực hiện bằng cách chạy song song nhiều tác vụ hẹp thay vì một agent bao quát duy nhất

  • Validate

    • Một agent độc lập đọc lại mã và cố gắng phản bác kết quả ban đầu
    • Nó dùng prompt khác và không thể tự tạo ra kết quả mới
    • Nó bắt được một tỷ lệ đáng kể nhiễu mà hunter có thể bỏ qua khi tự xem lại công việc của mình

  • Gapfill

    • Đánh dấu các khu vực mà hunter đã chạm tới nhưng chưa bao phủ đủ
    • Các khu vực đó được đưa trở lại hàng đợi cho một lượt khác
    • Việc này bù lại xu hướng mô hình nghiêng về các lớp tấn công mà nó đã thành công trước đó

  • Dedupe

    • Gộp các kết quả có cùng nguyên nhân gốc rễ thành một bản ghi duy nhất
    • Phân tích biến thể là một tính năng, chứ không phải cách làm phình to hàng đợi bằng các mục trùng lặp

  • Trace

    • Với mỗi kết quả đã được xác nhận trong thư viện dùng chung, tracer agent sẽ phân nhánh thành từng kho tiêu thụ một
    • Nó dùng chỉ mục symbol liên kho để xác định liệu đầu vào do kẻ tấn công kiểm soát có thực sự đi tới lỗi từ bên ngoài hệ thống hay không
    • Đây là bước quan trọng nhất để biến “có lỗi” thành “có lỗ hổng có thể tiếp cận”

  • Feedback

    • Các kết quả truy vết có thể tiếp cận sẽ trở thành tác vụ hunt mới trong các kho tiêu thụ nơi lỗi đó thực sự bị lộ ra
    • Điều này khép kín vòng lặp giúp pipeline cải thiện dần theo thời gian chạy

  • Report

    • Agent viết báo cáo có cấu trúc theo một schema được định nghĩa trước
    • Nó tự sửa lỗi xác thực schema và gửi lên ingest API
    • Đầu ra không phải văn xuôi tự do mà là dữ liệu có thể truy vấn

Ý nghĩa đối với các nhóm bảo mật

  • Những lãnh đạo bảo mật khác khi thấy Mythos Preview đã cố rút ngắn chu kỳ phản ứng bằng cách quét nhanh hơn và vá nhanh hơn
  • Ít nhất một trong các nhóm mà Cloudflare trao đổi đang vận hành với SLA 2 giờ từ lúc công bố CVE đến lúc vá trên production
  • Khi timeline của kẻ tấn công ngắn lại thì timeline của bên phòng thủ cũng phải ngắn hơn, nhưng chỉ tốc độ thôi là chưa đủ
  • Vá nhanh hơn không làm thay đổi hình dạng của pipeline tạo ra bản vá
    • Nếu kiểm thử hồi quy mất một ngày thì không thể đạt SLA 2 giờ mà không bỏ qua kiểm thử hồi quy
    • Việc triển khai một lỗi khi bỏ qua kiểm thử hồi quy có thể còn tệ hơn lỗi ban đầu định sửa
    • Khi để mô hình tự viết bản vá, đã có trường hợp một số bản vá được triển khai tuy sửa được lỗi gốc nhưng lại âm thầm làm hỏng những phần khác mà mã phụ thuộc vào
  • Câu hỏi khó hơn là phải thiết kế kiến trúc xung quanh lỗ hổng như thế nào
    • Cần khiến kẻ tấn công khó khai thác ngay cả khi lỗi vẫn tồn tại
    • Cần làm cho khoảng cách giữa lúc công bố lỗ hổng và lúc vá bớt quan trọng hơn
    • Cần có cơ chế phòng vệ ở phía trước ứng dụng để chặn việc tiếp cận lỗi
    • Cần thiết kế ứng dụng sao cho lỗi ở một phần mã không cho phép kẻ tấn công truy cập sang phần khác
    • Cần có khả năng triển khai sửa đổi đồng thời tới mọi nơi đang chạy mã mà không phải chờ từng nhóm riêng lẻ phát hành
  • Cùng một năng lực cũng có tính hai mặt
    • Khả năng tìm lỗi trong mã của chính mình, nếu rơi vào tay kẻ xấu, cũng có thể tăng tốc tấn công vào mọi ứng dụng trên Internet
    • Cloudflare cho biết họ đứng phía trước hàng triệu ứng dụng, và các nguyên tắc kiến trúc ở trên chính là những nguyên tắc mà sản phẩm của họ được xây dựng để áp dụng thay cho khách hàng
  • Nghiên cứu Mythos Preview được thực hiện trong môi trường có kiểm soát trên chính mã của Cloudflare, và mọi lỗ hổng được phát hiện đều đã được sàng lọc, xác minh theo quy trình quản lý lỗ hổng chính thức của Cloudflare và được sửa khi cần thiết

Bài viết liên quan

2 bình luận

 
crawler 2 giờ trước

Tôi tưởng đây là một bản báo cáo phân tích đã sửa lỗi gì giống như curl, hóa ra chỉ là một bài quảng bá trần trụi thôi sao?
Cloudflare cũng vừa làm paywall dành riêng cho AI agent với endpoint tóm tắt để hype lên, giờ đúng là xuống cấp rồi.
 
GN⁺ 2 giờ trước
Ý kiến trên Hacker News

  • Tôi không hiểu câu “đây là một loại công cụ khác, dùng cho một loại công việc khác nên khó so sánh kiểu táo với táo với các mô hình trước đó” nghĩa là gì
    Đã bảo là một loại công cụ khác, nhưng cách dùng thực tế lại được mô tả y hệt các mô hình khác. Nó tệ hơn hẳn một bài blog Cloudflare trung bình, và tạo cảm giác như chỉ lặp lại phần trình bày Mythos vốn nhấn mạnh chaining và tạo ví dụ làm cốt lõi

    • Ý ở đây có lẽ là nó có những năng lực khác biệt về mặt định tính nên khiến việc thử mô hình này cho một số tác vụ bảo mật cụ thể trở nên đáng giá hơn, chứ không phải là mô hình tương tác người-AI đã thay đổi
      Mọi người vẫn gắn harness vào để dùng như thường, và cách phổ biến để cung cấp harness cho mô hình có lẽ sẽ không thay đổi nhiều trong tương lai. Con người đôi khi cũng cần harness để làm một số việc
    • Tôi cũng đã cố diễn giải nó như vậy
      Nếu nhìn theo hướng tích cực thì có thể họ cố tình nói mơ hồ vì vẫn còn NDA nên chưa thể nói chính xác điều gì khác biệt
    • “Tệ hơn hẳn một bài blog Cloudflare trung bình” à, tôi tò mò không biết cái mức trung bình đó được tính từ khi nào
      Dạo này đầu ra của Cloudflare hầu như cái nào cũng có mùi AI rất rõ
    • Có lẽ vì nó không phải bài blog thông thường mà là quảng cáo trá hình nên nghe khác đi
    • Đoạn “bản thân mô hình có các guardrail mới nên đôi khi phản ứng chống lại cả những yêu cầu nghiên cứu bảo mật hợp pháp. Tuy nhiên, theo những gì chúng tôi xác nhận được, các lần từ chối tự phát như vậy không nhất quán. Cùng một tác vụ nhưng diễn đạt khác đi hoặc đặt trong ngữ cảnh khác có thể cho ra kết quả hoàn toàn khác như ví dụ bên dưới” là điểm mới
      Khá bất ngờ khi một mô hình được thiết kế cho nghiên cứu bảo mật và chỉ mở cho chuyên gia lại từ chối các yêu cầu hợp pháp

  • Tôi đã kỳ vọng những con số cụ thể hơn và các kết quả gây kinh ngạc hơn, nhưng nó chỉ giống một bài PR cân bằng và có lẽ là do LLM viết

  • Câu hỏi thực sự là bài này do Mythos viết hay Opus viết
    Những cụm như “vì sao điều này quan trọng” thực ra chẳng quan trọng. Blog doanh nghiệp vốn hiếm khi mang giọng văn của một tác giả duy nhất, nhưng việc thấy cả những tổ chức lớn cũng thuê LLM viết blog hộ vẫn khá thú vị

    • Cấu trúc câu như “Đó là một thiên lệch hợp lý cho công cụ thăm dò. Đó là một thiên lệch mang tính phá hoại cho hàng đợi phân loại...” đúng là trông giống văn phong AI
      Tôi giờ còn muốn nâng “vì sao điều này quan trọng” thành “đầu ra AI sẽ trở thành một phần của dữ liệu huấn luyện”. Rồi sẽ đến lúc kiểu văn dài dòng trau chuốt theo phong cách AI trở thành chuẩn mực, và nếu không thuộc thế hệ trước thì sẽ khó mà phân biệt được. Khá giống cảm giác nhớ một vài khía cạnh của Usenet
    • Thật thú vị khi thấy có người nghĩ rằng chỉ cần mỉa mai đủ nhiều về một thứ thì cả nội dung thực chất của nó cũng biến mất
      Giống như đang nhìn vào nòng súng mà lại đùa về loại giấy dùng để in tờ quảng cáo súng
    • Đây không chỉ là một tổ chức lớn mà là Anthropic. Thông điệp cốt lõi của công ty này là AI giờ đã có thể làm việc thực sự, nên nếu chính họ không hành xử theo điều đó thì sẽ rất kỳ
      Có lẽ vì thế mà Claude Code có nhiều bug lạ, và cũng xảy ra chuyện bộ phận hỗ trợ nói đã xử lý hoàn tiền nhưng thực tế lại không xong
    • Blog Cloudflare đã rất xuất sắc trong nhiều năm, từ rất lâu trước khi transformer xuất hiện
    • Có vẻ không hẳn là AI viết hoàn toàn, mà gần hơn với kiểu AI biên tập. Hoặc họ dùng một công cụ nhân hóa khá tốt ở lượt xử lý thứ hai

  • “Bốn bài học” mà họ nói rút ra từ việc chạy tác vụ này ở quy mô lớn thật buồn cười. Ba trong bốn cái về cơ bản là giống nhau và quá hiển nhiên
    Tóm lại chỉ là yêu cầu cụ thể và hẹp hoạt động hiệu quả hơn so với “hãy tìm lỗ hổng”, điều này quá rõ ràng. Dù vậy, review đối kháng thì không mới chút nào và HN cũng bàn nhiều rồi, nhưng ít nhất đó vẫn là phần thú vị và có tính phân biệt. Tôi nên thử đưa nó nhiều hơn vào workflow của mình, và có lẽ nó cũng hữu ích cho những việc không phải coding
    https://blog.cloudflare.com/cyber-frontier-models/#what-a-ha...

  • Tôi thấy ấn tượng với đoạn “Phản ứng lớn nhất từ các lãnh đạo bảo mật đối với Mythos Preview là tốc độ. Quét nhanh hơn, vá nhanh hơn, rút ngắn chu kỳ ứng phó. Trong số các đội mà chúng tôi trao đổi, có ít nhất hai đội đang vận hành với SLA 2 giờ từ lúc CVE được công bố đến khi vá xong trên production [...] Nếu regression test mất cả ngày, bạn sẽ không thể đạt SLA 2 giờ trừ khi bỏ qua nó, mà nếu bỏ qua regression test thì rất dễ triển khai một bug còn tệ hơn bug ban đầu định vá”
    Tôi tự hỏi theo thời gian, các mô hình như thế này có thể thực hiện kiểm thử khả năng khai thác trước khi merge code và nhờ đó tạo ra code an toàn hơn theo mặc định hay không

    • Tôi không biết nữa, nhưng lúc nào cũng thấy lạ khi người ta nhìn AI làm chưa tốt một việc gì đó rồi lại kết luận rằng giải pháp là dùng thêm AI
    • Hoặc có thể sẽ không theo hướng đó, mà họ* sẽ bán quyền truy cập Mythos và các mô hình kế tiếp thông qua công ty dịch vụ hoặc mạng lưới đối tác, rồi thu mức phí premium
      *ở đây “họ” nghĩa là tất cả nhà cung cấp mô hình nền tảng, vì OpenAI dường như cũng đang đi theo hướng tương tự

  • Nghe thì có vẻ tốt, nhưng tôi muốn biết trong số các lỗ hổng họ tìm ra, cái nghiêm trọng nhất ở mức độ nào
    Có lẽ họ không muốn công bố, nhưng đó mới thực sự là phần thú vị và quan trọng nhất

    • Tôi cũng muốn hoài nghi theo, nhưng ngay đầu bài họ nói rất rõ. Đây là một bước thay đổi theo bậc
      Nhiều người nhìn Mythos như một chiến dịch tâm lý chiến, nhưng tôi không thật sự hiểu kiểu hoài nghi đó. Có vẻ nó chủ yếu đến từ sự thiếu tin tưởng nói chung đối với thứ gì đó không thể dùng công khai. Một vài nhân viên Anthropic có mô tả Mythos như một cải tiến mô hình đa dụng, nhưng điều đó vẫn chưa được hậu thuẫn rộng rãi nên riêng điểm ấy tôi vẫn giữ thái độ hoài nghi. Còn trong phạm vi nghiên cứu bảo mật thì tôi có thể chấp nhận câu chuyện này
    • Họ giải thích khá cụ thể rằng exploit thường được tạo ra bằng cách chaining nhiều lỗ hổng nhỏ với nhau
      Nhìn theo cách đó thì việc đóng các lỗ hổng không giống với việc tìm ra exploit. Thay vào đó, nó gần hơn với việc để lại ít khe hở nhỏ hơn, khiến việc lắp ghép một exploit hoạt động được ngày càng khó hơn
    • Giờ tôi đã khá tin rằng mô hình này sáng tạo hơn nhiều và có thể thực thi theo kiểu agent lâu hơn
      Vì vậy, ngay cả khi “hard skill” của nó không cải thiện vượt trội, nó vẫn có thể kết hợp các kỹ năng đó hiệu quả hơn. Ngay lúc này, khá nhiều lỗ hổng dạng này vẫn có thể được Opus nhận diện, nhưng để đi đến một exploit phức tạp thì vẫn cần con người, mà còn phải là người có kỹ năng, ở giữa quá trình. Nếu không còn cần con người chen vào thì người bình thường sẽ dễ hơn rất nhiều trong việc tìm và tận dụng exploit
    • Palo Alto Networks tuần trước đã công bố nhiều bản vá CVE cho firewall, và gần như tất cả đều xuất phát từ quyền truy cập các frontier model, bao gồm cả Mythos
      https://security.paloaltonetworks.com
    • Phần lớn sản phẩm mới của Anthropic đều là công cụ AI chẳng ai dùng, nên có lẽ họ sẽ tiếp tục đăng những bài viết chất lượng thấp kiểu này. Gần đây họ còn sa thải khá nhiều người, nên có thể cũng không còn cây bút giỏi nữa

  • Nghe hay đấy, nhưng tôi không hiểu vì sao họ không chia sẻ dữ liệu về việc thực sự đã tìm được bao nhiêu lỗ hổng bảo mật, trong đó bao nhiêu cái là thật và bao nhiêu cái là false positive

    • Tôi cũng đang chờ điều này
      Tôi hiểu chuyện họ muốn xử lý xong trước khi công bố, nhưng khi cứ liên tục thấy những tuyên bố gần như không có dữ liệu đi kèm thì tôi không biết họ mong người ta đừng hoài nghi kiểu gì. Các chuyên gia bảo mật đúng nghĩa là những người được trả tiền để hoài nghi

  • Tôi tự hỏi họ có so sánh với các mô hình khác không. Nhiều phần trong bài này nghe như thể họ lần đầu áp dụng AI vào bảo mật và ngạc nhiên trước hiệu năng lố bịch của một cỗ máy khớp mẫu
    Mà cuối cùng thì nó đúng là một cỗ máy khớp mẫu, nên cũng dễ hiểu thôi

  • Cái đoạn phản ứng chống lại yêu cầu khá buồn cười. Khi tôi dùng thử trực tiếp, trước khi tiếp tục nó đã yêu cầu tôi chứng minh rằng mình có quyền truy cập hợp pháp vào codebase đó

  • Câu “Điều thay đổi ở Mythos Preview là mô hình giờ có thể chaining các bug mức độ thấp mà theo truyền thống vẫn bị chìm trong backlog thành một exploit nghiêm trọng hơn” có vẻ cũng phù hợp phần nào với các bài test độc lập khác về Mythos
    Nó làm rất tốt ở các tác vụ agent dài, và có lẽ đó là mục tiêu huấn luyện. Muốn vậy thì nó phải có khả năng tìm ra các kết nối ngoại vi giữa những chủ đề chỉ liên quan lỏng lẻo với nhau bên trong context window
    [1] Chủ yếu tôi đang nói đến https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos...