- Công bố có trách nhiệm trong 90 ngày đã mất tác dụng bảo vệ khi LLM làm tăng số người phát hiện và tốc độ phát triển exploit
- Trong 6 tuần, 11 người đã báo cùng một lỗi xác minh thanh toán nghiêm trọng, cho thấy hiện tượng tái phát hiện đồng thời
- Diff bản vá của React được biến thành exploit hoạt động chỉ trong 30 phút với sự hỗ trợ của AI
- Copy Fail và Dirty Frag đã dẫn tới PoC công khai và khai thác thực tế, khiến lệnh cấm tiết lộ sụp đổ
- Các vấn đề nghiêm trọng cần được xử lý ngay như P0, và phải đưa LLM vào pipeline bảo mật
Vì sao mô hình công bố có trách nhiệm 90 ngày bị phá vỡ
- Khoảng thời gian công bố có trách nhiệm 90 ngày được xây dựng dựa trên giả định rằng người tìm ra bug là hiếm và việc phát triển exploit diễn ra chậm
- Trong 12 tháng gần đây, các công cụ mà đội ngũ bảo mật, kẻ tấn công và nhà nghiên cứu sử dụng đã trở nên thông minh hơn với tốc độ tương tự, và nhận định là LLM đã rút ngắn thời gian tìm lỗ hổng và phát triển exploit xuống gần như bằng 0
- Trong mô hình kiểu năm 2019, theo phong cách Google Project Zero, nhà cung cấp được cho 90 ngày và trong khoảng đó có các giả định sau
- Gần như sẽ không có ai khác tìm ra cùng bug đó
- Ngay cả khi người khác tìm ra thì cũng sẽ mất thời gian
- Nhà cung cấp sẽ có đủ thời gian đi trước để viết bản vá
- Sau khi bản vá được công khai, kẻ tấn công sẽ cần vài ngày hoặc vài tuần để đảo ngược và tạo ra exploit hoạt động
- Tất cả các giả định này đều đã sai, và khoảng 90 ngày đã trở thành cấu trúc trao 90 ngày lợi thế đi trước cho những ai đã nắm bug thay vì bảo vệ người dùng
Trường hợp 1: 11 người báo cùng một bug nghiêm trọng trong 6 tuần
- Cuối tháng 4, một bug nghiêm trọng được báo cho một công ty, nhưng đội triage trả lời rằng bug này đã được báo lần đầu vào tháng 3 và người báo hiện tại là người thứ 11
- Dạng bug là sau khi mua hàng trên website, kẻ tấn công có thể gửi ngược lên máy chủ một phản hồi do chính mình chỉnh sửa trực tiếp, và do không có xác minh chữ ký cho phản hồi nên máy chủ vẫn chấp nhận nguyên trạng
- Ví dụ có thể mua món hàng giá 5.000 USD với giá 0 USD, hoặc hoàn tất mua hàng mà không thanh toán thật
- Việc có tới 11 người khác nhau tìm ra cùng một bug nghiêm trọng trong khoảng 6 tuần cho thấy mô hình các hunter được LLM hỗ trợ đang hội tụ gần như đồng thời vào cùng một lỗ hổng
- Một người quen từ BlueWater CTF đã chỉ ra từ vài tháng trước hiện tượng các reporter và workflow không liên quan nhau cùng đổ về một loại bug nhờ hỗ trợ của LLM
- Phía triage cũng quan sát thấy hiện tượng tương tự
- @d0rsky viết rằng khi một lỗ hổng mới được phát hiện bằng prompt, kỹ năng và tự động hóa với LLM, thì chỉ trong vài ngày sẽ xuất hiện hàng loạt báo cáo trùng lặp có cùng nguyên nhân gốc
- Nếu nhà nghiên cứu có thể tái tạo nhanh đến vậy, thì lo ngại rằng black hat cũng có thể làm điều tương tự trước khi có bản vá sẽ càng lớn
- Nếu đã có 10 người báo cáo thì có thể vẫn còn những người chưa báo, và cùng một LLM không chỉ mở cho các nhà nghiên cứu thiện chí mà còn cho bất kỳ ai khác
- CVE credit và bug bounty chỉ có 1 người nhận được, nên 9 người còn lại hoặc những người vốn không báo cáo ngay từ đầu sẽ không bị ràng buộc bởi đồng hồ 90 ngày
- Cửa sổ công bố 90 ngày trong tình huống này không thể bảo vệ người dùng, mà chỉ là cơ chế mua thêm thời gian cho những người đã có bug trong tay
Trường hợp 2: Từ bản vá React tới exploit hoạt động trong 30 phút
- React đã vá nhiều vấn đề bảo mật và đăng bài blog công khai
- Chỉ mất 30 phút để đọc bản vá và tạo exploit hoạt động nhắm vào một ứng dụng kiểm thử cục bộ
- Vấn đề công khai này là từ chối dịch vụ (DoS), và AI đã xử lý phần lớn việc hiểu diff, xác định đường đi mã dễ tổn thương và viết PoC
- Trước đây, để biến một bản vá công khai thành exploit n-day hoạt động, một chuyên gia đảo ngược giàu kinh nghiệm sẽ phải mất từ vài ngày đến vài tuần, và khoảng chênh thời gian đó là lớp đệm an toàn để quản trị viên kịp cập nhật
- Giờ đây, bug đơn giản có thể chỉ mất vài phút, bug phức tạp chỉ mất vài giờ, và không còn bắt buộc phải có chuyên gia đảo ngược lành nghề
- Phải giả định rằng ngay khi bản vá xuất hiện thì exploit cũng đã tồn tại, và cách trì hoãn triển khai tới kỳ bảo trì tiếp theo không còn phù hợp
Trường hợp 3: Copy Fail và Dirty Frag bùng nổ liên tiếp trong Linux kernel
- Trong 2 tuần gần đây, Linux kernel liên tiếp xuất hiện hai lỗ hổng nghiêm trọng, cả hai đều có exploit công khai và ảnh hưởng đến các bản phân phối lớn
-
Copy Fail
- Ngày 29/4, Xint Code công bố Copy Fail
- Xint Code là đội đứng sau Theori, được giới thiệu là đội đã vô địch DEF CON CTF 9 lần
- Copy Fail là CVE-2026-31431, được mô tả là lỗi logic khá trực diện trong subsystem crypto của kernel
- Không cần race condition, độ tin cậy 100%, và có thể giành quyền root trên mọi bản phân phối Linux phát hành từ năm 2017 bằng script Python 732 byte
- Các bản phân phối lớn như Ubuntu, RHEL, Amazon Linux, SUSE đều bị ảnh hưởng
- Theo mô tả, lỗi được tìm ra bằng cách dùng AI quét tự động subsystem
crypto/ của kernel trong khoảng 1 giờ, và là lỗ hổng đã lộ diện suốt 9 năm
- Phân tích kỹ thuật có trong bài viết của Xint
- Bản vá được phát hành qua commit mainline
a664bf3d603d, và cũng có biện pháp giảm thiểu là vô hiệu hóa module algif_aead
- Sau đó được cho là đã quan sát thấy dấu hiệu kẻ tấn công Iran khai thác lỗ hổng này để xâm nhập máy chủ Ubuntu và tái sử dụng chúng làm node cho chiến dịch DDoS
- Chỉ mất vài ngày để một lỗ hổng leo thang đặc quyền kernel được AI phát hiện đi từ PoC công khai tới bị vũ khí hóa bởi tác nhân cấp quốc gia
-
Dirty Frag
- Khoảng 1 tuần sau, ngày 7/5, Hyunwoo Kim(@v4bel) công bố Dirty Frag
- Dirty Frag là lỗ hổng xâu chuỗi CVE-2026-43284 và CVE-2026-43500
- Nó xâu chuỗi hai lỗ hổng trong IPSec ESP(
esp4/esp6) và module mạng RxRPC của kernel
- Cùng họ lỗi với Copy Fail và Dirty Pipe, cùng kỹ thuật page-cache corruption nhưng đường tấn công khác nhau
- Ngay cả khi áp dụng biện pháp giảm thiểu cho Copy Fail thì Dirty Frag vẫn hoạt động
- Việc đưa
algif_aead vào blacklist không ảnh hưởng vì Dirty Frag không dùng module đó
- Có thể leo thang từ người dùng không đặc quyền lên root một cách xác định, và được cho là hoạt động trên các bản phân phối lớn như Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44
- Việc biên dịch và chạy chỉ cần lệnh một dòng
-
Quá trình công bố Dirty Frag và sự sụp đổ của lệnh cấm tiết lộ
- Hyunwoo Kim đã báo cáo tới
[email protected] vào ngày 29~30/4 và gửi bản vá công khai
- Ngày 7/5, anh phối hợp với mailing list
linux-distros và thống nhất lệnh cấm tiết lộ 5 ngày
- Cùng ngày đó, chỉ trong vài giờ, một bên thứ ba không liên quan đã công khai thông tin exploit chi tiết của lỗ hổng ESP liên quan, khiến lệnh cấm tiết lộ bị phá vỡ
- Sau khi trao đổi với các maintainer của các bản phân phối, Hyunwoo đã công bố phân tích đầy đủ Dirty Frag, mã exploit và PoC hoạt động
- Tại thời điểm đó, không có bản phân phối Linux nào cung cấp bản vá
- Theo tình trạng hiện tại, chỉ phía ESP của CVE-2026-43284 có bản sửa mainline, còn thành phần RxRPC của CVE-2026-43500 vẫn chưa có bản vá upstream
- Ubuntu, Red Hat, Tenable và các bên khác đã phát hành tư vấn riêng
-
Khai thác Dirty Frag ngoài thực tế
- Đội Microsoft Defender đã xác nhận tình trạng khai thác thực tế ở mức hạn chế chỉ trong 24 giờ sau khi công khai
- Theo mô tả, kẻ tấn công đã có được quyền truy cập SSH, triển khai binary ELF, dùng
su để lấy quyền root, sửa cấu hình xác thực, xóa file phiên và thực hiện di chuyển ngang
- CTS(@gf_256) đã tóm tắt bằng câu “responsible disclosure is dead🤦”
Những thứ thực sự đã chết
- Cửa sổ công bố 90 ngày không còn là thứ có thể sửa chữa, mà là một mô hình đã kết thúc
- Mô hình này phù hợp với một thế giới nơi người phát hiện là hiếm và việc phát triển exploit diễn ra chậm, nhưng LLM đã làm số người phát hiện tăng lên và làm việc phát triển exploit nhanh hơn
- Nếu 10 người không liên quan nhau có thể tìm ra cùng một bug trong 6 tuần, và AI có thể biến patch diff thành exploit hoạt động trong 30 phút, thì cửa sổ 90 ngày không bảo vệ được ai
- Copy Fail đã đi từ quét bằng AI tới PoC công khai rồi tới bị vũ khí hóa bởi tác nhân cấp quốc gia chỉ trong vài ngày
- Dirty Frag thì lệnh cấm tiết lộ đã bị phá vỡ chỉ sau vài giờ do một bên thứ ba độc lập tìm ra cùng họ lỗi
- Trong môi trường mà cùng một lỗ hổng được nhiều nhà nghiên cứu và công cụ AI độc lập tái phát hiện đồng thời, việc điều phối công bố rất khó duy trì
- Chu kỳ vá hàng tháng cũng đã hết thời
- Cửa sổ 30 ngày giữa lỗ hổng và bản sửa dựa trên giả định rằng kẻ tấn công chậm hơn nhịp phát hành
- Khi Microsoft thấy khai thác Dirty Frag thực tế trong vòng 24 giờ, kỳ bảo trì hàng tháng không còn là vùng đệm an toàn mà trở thành cửa sổ tấn công
- Cách chờ advisory cũng đã hết thời
- Trong lúc bên phòng thủ đang đọc mô tả CVE, bên tấn công đã đọc
git log --diff-filter=M
- Advisory là sản phẩm đầu ra downstream, còn patch diff mới là tín hiệu
Ngành cần thay đổi cách ứng phó như thế nào
- Kết luận là mọi vấn đề bảo mật nghiêm trọng phải được xem là P0 và sửa ngay lập tức
- Không phải “trong 24 giờ”, “ở sprint tiếp theo” hay “sau khi đánh giá tác động”, mà là mức độ phải dừng việc đang làm và khắc phục ngay
- Có những lý do thực tế khiến triển khai production phức tạp và cần quy trình quản lý thay đổi, nhưng môi trường đe dọa không chờ thủ tục quản lý thay đổi
-
Nhà cung cấp
- Đồng hồ bắt đầu chạy từ khoảnh khắc báo cáo bug nghiêm trọng được gửi đến
- Không phải từ lúc triage xong hay lúc engineering tiếp nhận, mà là ngay thời điểm báo cáo đến nơi
- Nếu đã có một người báo thì phải giả định rằng 10 người khác đã có bug đó, và ít nhất 1 người trong số đó không thân thiện
-
Nhà nghiên cứu
- Không nên giữ bug nghiêm trọng quá lâu mà cần thúc đẩy cửa sổ công bố ngắn nhất có thể
- Nếu nhà cung cấp không thể sửa trong vòng 1 tuần thì đó là vấn đề của nhà cung cấp chứ không phải vấn đề công bố
- Sự lịch thiệp kiểu cũ là “cho thêm thời gian” chỉ có ý nghĩa khi mình là người phát hiện duy nhất, nhưng giờ rất có thể không còn là người duy nhất
-
Quản lý lỗ hổng
- Quản lý lỗ hổng phải diễn ra theo thời gian thực
- Mô hình “quét hàng tuần, triage trong sprint, vá theo chu kỳ” là một mốc thời gian mà kẻ tấn công đã đi qua từ lâu
- Thời gian phản hồi tối đa mới cho các vấn đề nghiêm trọng không còn là vài ngày mà là vài giờ, và thậm chí như vậy vẫn có thể là chậm
Vì sao blue team phải đưa LLM vào pipeline phòng thủ
- Kẻ tấn công đã tích hợp LLM vào pipeline exploit, và phía phòng thủ cũng phải di chuyển với tốc độ tương tự
- Phải tích hợp LLM ngay ở thời điểm push code
- Cần chạy review bảo mật có AI hỗ trợ như một phần của pipeline CI cho mọi pull request, merge và deploy
- Nó phải chạy ngay lúc push giống như linter và unit test, chứ không phải là audit hàng quý hay kiểm tra hậu kỳ
- Nếu có lỗ hổng thì phải chặn trước khi chạm production, vì chi phí sửa trong lúc review PR thấp hơn rất nhiều so với sau khi CVE được công khai
- Cũng phải tích hợp LLM vào phân tích bản vá
- Khi dependency upstream phát hành bản vá bảo mật, pipeline phải tự động kéo diff, phân tích thay đổi, xác định liệu codebase của mình có bị ảnh hưởng hay không và phát cảnh báo
- Không nên phụ thuộc vào việc con người đọc mailing list rồi mở ticket Jira, mà phải tự động diễn ra trong vài phút ngay khi bản vá xuất hiện trong kho công khai
- Nếu Xint Code có thể tìm ra Copy Fail bằng 1 giờ quét tự động, thì dependency nội bộ cũng phải được quét theo cách tương tự
- Phải dùng LLM cả cho quét dependency
- Chuỗi cung ứng chỉ mạnh bằng dependency bắc cầu yếu nhất của nó
- Trình quét dependency dựa trên AI có thể theo dõi tác động của lỗ hổng trong cây dependency, đánh dấu các phiên bản bị ảnh hưởng và đề xuất đường nâng cấp
- Nó phải chạy liên tục chứ không phải theo tuần
- Phải dùng AI để kiểm thử bản vá trước khi phát hành bản vá
- Nếu như trong trường hợp React, LLM có thể biến bản vá thành exploit trong 30 phút, thì bên phòng thủ phải dùng chính các công cụ đó để kiểm tra trước khi công khai bản vá
- Cần xác nhận rằng bản vá thực sự sửa được vấn đề và không tạo ra vấn đề mới
- Cũng nên dùng để tạo kiểm thử hồi quy và kiểm tra xem cùng một pattern có tồn tại ở nơi khác trong codebase hay không
- Cửa sổ giữa “lỗ hổng tồn tại” và “lỗ hổng bị khai thác” đang tiến gần về 0, và phía phòng thủ cũng phải tự động hóa với cùng tốc độ như phía tấn công
- Sẽ có nhiều zero-day hơn bị khai thác ngoài thực tế với tốc độ nhanh hơn, và lý do là cùng một bộ công cụ, rào cản gia nhập thấp hơn, nhiều người phát hiện hơn và timeline ngắn hơn
- Những đội sống sót qua bước chuyển này là những đội biến AI thành thành phần hạng nhất của pipeline bảo mật trước khi bị ép buộc phải làm vậy
Kết luận
- Một quản trị viên hệ thống đọc advisory về Dirty Frag giờ phải đối mặt với thực tế mới: chưa có bản vá, exploit đã công khai, Microsoft đã thấy khai thác thực tế, biện pháp giảm thiểu là vô hiệu hóa module IPSec, và họ phải xử lý 400 máy chủ
- Chính sách công bố 90 ngày, chu kỳ vá hàng tháng, và giả định rằng có thời gian giữa công bố và khai thác đều đã chết
- Điều còn lại là khả năng di chuyển nhanh, tự động hóa mạnh và xử lý bug nghiêm trọng như một tình huống khẩn cấp thực sự
- Làn sóng AI đã phá vỡ mô hình cũ, nhưng đồng thời cũng mở ra mô hình mới như vá nhanh, quét tự động, threat intelligence thời gian thực và review mã có AI hỗ trợ
- Công cụ thì đã có sẵn; điều quan trọng là liệu bên phòng thủ có dùng chúng trước kẻ tấn công hay không, và hiện tại kẻ tấn công đang dẫn trước trong cuộc đua đó
1 bình luận
Ý kiến trên Lobste.rs
Đành phải miễn cưỡng đồng ý. Công ty chúng tôi cũng đã điều tra về chủ đề này, và thời gian từ bản vá đến exploit gần như là ngay lập tức
Chính sách công bố có trách nhiệm ngay từ đầu đã là một thứ hư cấu mà người ta chỉ giả vờ tin nhau vì phép lịch sự. Vốn dĩ nó chỉ là kiểu hùa theo bầu không khí, và các công cụ tìm lỗ hổng dựa trên LLM chỉ đơn giản là phơi bày bản chất đó
Cũng khá mỉa mai khi chính bài viết này lại toát ra mùi do LLM viết
Có lẽ thứ đã chết là thời đại của các chương trình C thủ công kiểu boutique dùng trong những tình huống bắt buộc theo nhiệm vụ