AI đang phá vỡ hai nền văn hóa xử lý lỗ hổng

• Sau khi Copy Fail được công khai, Hyunwoo Kim cho rằng bản sửa trước đó là chưa đủ và đã chia sẻ bản vá ngay trong ngày, nhưng quy trình sửa lỗi công khai âm thầm kiểu Linux đã bị lộ do bị bên ngoài phát hiện, dẫn tới việc kết thúc embargo
• Trong Linux, đặc biệt là ở mảng mạng, có thông lệ chia sẻ tác động bảo mật trong danh sách riêng tư và tiến hành sửa lỗi công khai thật nhanh, nhằm giữ embargo về sự tồn tại của lỗ hổng thực tế trong vài ngày
• Sau khi người khác phát hiện thay đổi công khai và nhận ra tác động bảo mật, họ đã công bố nó, và sau đó toàn bộ chi tiết cũng được công khai
• Khi AI làm giảm chi phí đánh giá ý nghĩa bảo mật của từng commit, việc tìm ra lỗ hổng từ các bản sửa được công khai âm thầm trở nên dễ hơn và tỷ lệ tín hiệu trên nhiễu cũng cao hơn
• Mô hình công bố phối hợp 90 ngày truyền thống cũng đang suy yếu; trong trường hợp này, chỉ 9 giờ sau khi Kim báo cáo lỗ hổng ESP thì Kuan-Ting Chen cũng đã báo cáo độc lập, cho thấy embargo rất ngắn có thể là hướng đi tốt hơn

---

Va chạm giữa Copy Fail và thông lệ vá lỗi bảo mật của Linux

• Sau khi lỗ hổng Copy Fail được công khai, Hyunwoo Kim cho rằng bản sửa trước đó là chưa đủ và đã chia sẻ bản vá ngay trong ngày
• Kim đã làm theo quy trình phổ biến trong Linux, đặc biệt là ở mảng mạng
  • Tác động bảo mật được chia sẻ trong danh sách riêng tư của các kỹ sư bảo mật Linux
  • Việc sửa lỗi được tiến hành công khai nhưng âm thầm và nhanh chóng
  • Mục tiêu là giữ embargo trong vài ngày đối với sự tồn tại của một lỗ hổng nghiêm trọng, trong khi chỉ bản sửa thực tế được công khai
• Sau khi người khác phát hiện thay đổi đó và nhận ra tác động bảo mật, họ đã công bố nó
• Vì lỗ hổng được xem là đã bị công khai, embargo kết thúc, và sau đó toàn bộ chi tiết được công bố

AI đang tạo áp lực lên hai nền văn hóa lỗ hổng

• Văn hóa công bố phối hợp

  • Khi phát hiện lỗi bảo mật, người ta báo riêng cho bên bảo trì và thường cho họ một khoảng thời gian như 90 ngày để sửa
  • Mục tiêu là để bản vá được phát hành trước khi lỗ hổng bị biết đến rộng rãi

• Văn hóa “bug chỉ là bug”

  • Đây là cách tiếp cận đặc biệt phổ biến trong Linux: nếu kernel làm điều mà nó không nên làm, thì giả định rằng ai đó có thể biến nó thành cách tấn công
  • Sửa càng nhanh càng tốt mà không thu hút chú ý vào việc đó là một lỗ hổng
  • Trong bối cảnh có rất nhiều thay đổi trôi qua, kỳ vọng là mọi người có thể không nhận ra, và trong lúc đó vẫn còn thời gian để vá hệ thống

• Rủi ro của cách sửa công khai tăng lên vì AI

  • Cách này vốn chưa bao giờ hoạt động hoàn hảo, nhưng đang trở thành vấn đề lớn hơn khi AI ngày càng giỏi phát hiện lỗ hổng
  • Khi có nhiều bản sửa liên quan đến bảo mật hơn, việc rà commit trở nên hấp dẫn hơn và tỷ lệ tín hiệu trên nhiễu tăng lên
  • Chi phí để AI đánh giá từng commit khi chúng xuất hiện ngày càng giảm, trong khi hiệu quả ngày càng tăng

• Embargo dài cũng đang yếu đi

  • Trước đây, vì tốc độ phát hiện chậm, nếu báo cho vendor và đặt cửa sổ công bố 90 ngày thì khả năng người khác tự phát hiện trong thời gian đó là thấp
  • Giờ đây giả định đó suy yếu vì các nhóm có hỗ trợ AI đang quét lỗ hổng phần mềm trên diện rộng
  • Trong trường hợp này, chỉ 9 giờ sau khi Kim báo cáo lỗ hổng ESP, Kuan-Ting Chen cũng đã báo cáo độc lập
  • Embargo có thể tạo ra cảm giác không khẩn cấp sai lệch và làm tăng rủi ro khi giới hạn số tác nhân có thể sửa lỗi

• Những hướng đi khả dĩ và một thử nghiệm mô hình đơn giản

  • Chưa có lời giải rõ ràng, nhưng embargo rất ngắn có vẻ là một cách tiếp cận tốt và có thể sẽ cần ngắn hơn nữa theo thời gian
  • AI không chỉ giúp kẻ tấn công mà còn có thể giúp bên phòng thủ tăng tốc, khiến những embargo trước đây quá ngắn để hữu ích nay trở nên khả thi
  • Khi đưa f4c50a403 cho Gemini 3.1 Pro, ChatGPT-Thinking 5.5 và Claude Opus 4.7, cả ba mô hình đều lập tức nhận ra đây là một bản vá bảo mật
  • Khi chỉ đưa diff mà không có ngữ cảnh commit, Gemini vẫn chắc chắn đó là bản sửa bảo mật, GPT cho rằng khả năng cao là vậy, còn Claude cho rằng nhiều khả năng không phải
  • Thử nghiệm này chỉ là một ví dụ rất nhanh, chạy mỗi mô hình một lần với prompt "Without searching, does this look like a security patch?", nên khó rút ra nhiều ý nghĩa lớn từ việc so sánh giữa các mô hình

[fastkoder]

Giữa embargo rất ngắn và embargo dài thì gần như buộc phải chọn “embargo rất ngắn”, nên các AI agent phụ trách bảo mật sẽ còn bận rộn hơn nữa.

[GN⁺]

Ý kiến trên Hacker News

• Sự thay đổi này đã được báo trước từ rất lâu, và ngay cả trước khi biết LLM là gì thì những rạn nứt đang thấy hiện nay cũng đã có thể dự đoán được
  Chất xúc tác là sự gia tăng tính minh bạch của phần mềm. Việc áp dụng phần mềm mã nguồn mở và phần mềm công khai mã nguồn đã tăng mạnh, còn các công cụ đảo ngược và giải biên dịch cũng tiến bộ đáng kể. Thời kỳ mà phần mềm đóng gói mã nguồn đóng thông thường còn có thể được che giấu một cách đáng kể trước các kẻ tấn công nghiêm túc thực ra đã qua hơn 10 năm rồi
  Từ sau BinDiff, vấn đề này đã tiến triển chậm nhưng đều. Khi vá phần mềm, gần như cũng đồng thời phải công khai lỗ hổng. Trước đây mọi người vẫn phủ nhận điều đó vì để nhận ra bản vá đồng nghĩa với việc công bố lỗ hổng thì cần một mức chuyên môn nhất định, nhưng AI đã xóa bỏ cái cớ đó
  Giờ đây, mỗi khi có thứ gì đó được hợp nhất vào mainline Linux, nhiều tổ chức sẽ đưa phần diff đó vào prompt LLM, đánh giá một cách quyết liệt xem đó có phải là bản sửa lỗ hổng hay không, rồi tạo ra hướng dẫn khai thác. Hầu hết các dự án mã nguồn mở lớn như nginx, OpenSSL, Postgres rồi cũng sẽ như vậy
  Thực hành công bố có phối hợp không được thiết kế cho môi trường này, và thực ra theo tôi thì 10 năm qua nó cũng đã không còn phù hợp
  Kỳ lạ là tôi không thấy khó chịu về chuyện này, vì theo tôi thực hành công bố có phối hợp từ trước đến nay luôn mặc nhiên chấp nhận giả định rằng trì hoãn công bố là tốt hơn vì sự thuận tiện vận hành của quản trị viên hệ thống. Giả định đó đáng để nghi ngờ. Việc trì hoãn công bố đơn giản là tước đi thông tin ngay cả từ những người vận hành hệ thống vốn có những lựa chọn khác ngoài việc chỉ áp dụng bản vá

  • Câu “thời kỳ mà phần mềm đóng gói mã nguồn đóng thông thường còn có thể được che giấu một cách đáng kể trước các kẻ tấn công nghiêm túc thực ra đã qua hơn 10 năm rồi” gần như là điều hiển nhiên, nhưng tuyến phòng thủ cuối cùng là không phân phối công khai phần mềm mà dựa vào kiến trúc server-client
    Nếu lỗ hổng ngày càng dễ bị phát hiện và khai thác thì kiểu này có thể sẽ trở nên phổ biến hơn. Dĩ nhiên không phải lúc nào cũng làm được
    Trong 11 năm qua, việc binary client game được làm rối bằng ProGuard bị giải biên dịch nhiều lần rồi đưa lên GitHub thật sự khá bực mình. Chỉ có mã server không phát hành mới còn được giữ kín
    Điều thú vị là trước khi chúng tôi ngừng thay đổi giao thức mạng với tần suất dày hơn mỗi tuần, không hề có vấn đề gì với việc kẻ tấn công đảo ngược nó. Giờ thì có vẻ những kẻ tấn công được LLM hỗ trợ cũng có thể theo kịp tốc độ đó
  • Tôi luôn hiểu lý do kinh doanh khiến công bố lỗ hổng có phối hợp ra đời, và ở chỗ làm tôi cũng buộc phải theo chính sách đó, nhưng về mặt cá nhân thì tôi luôn nghiêng về công bố hoàn toàn. Tôi đã chờ đợi sự thay đổi này rất lâu

• Điều này có vẻ không phải là một vấn đề mới do AI tạo ra, mà gần hơn với một vấn đề cũ được đóng gói lại thành vấn đề AI
  Từ rất lâu trước khi có LLM, người ta đã so sánh diff commit kernel để tìm ra cái nào là bản sửa bảo mật. Ngay khi bản vá được đưa lên công khai thì cuộc đua thực chất đã bắt đầu rồi
  Tôi cũng không chắc việc rút ngắn thời gian hoãn công khai có thực sự giúp ích không. Các tổ chức có thể vá trong vài giờ thì vốn đã ổn, còn phần còn lại vẫn sẽ mất vài ngày hoặc vài tuần
  Thậm chí chi phí tạo exploit càng giảm thì công bố có phối hợp có thể không phải là kém quan trọng đi, mà là càng quan trọng hơn

  • “Người ta vốn đã so sánh diff commit kernel để tìm ra cái nào là bản sửa bảo mật”, nhưng việc đó đòi hỏi kỹ năng và thường không được làm một cách nhất quán, có hệ thống. Với AI thì bất kỳ ai cũng có thể làm việc này với bất kỳ phần mềm nào
    Về ý “không chắc việc rút ngắn thời gian hoãn công khai có giúp ích không”, điểm cốt lõi là tại sao là 90 ngày mà không phải 2 năm. Lập luận của bài viết là các yếu tố từng quyết định điểm cân bằng đó đã thay đổi vì tần suất phát hiện đồng thời tăng lên. Nếu đằng nào cũng có nhiều người ngoài thời gian hoãn sẽ tìm ra exploit, thì thời gian hoãn không còn là một cửa sổ thực tế mà chỉ là ảo tưởng
    Tôi đồng ý với ý “việc tạo exploit giá rẻ khiến công bố có phối hợp trở nên quan trọng hơn”. Nhưng đồng thời nó cũng khiến việc đó kém khả thi hơn. Nếu cả script kiddie cũng có thể tìm và khai thác zero-day thì năng lực để điều phối sẽ sụp đổ
    Văn hóa whitehat trước nay luôn có kiểu đạo đức phường hội thợ thủ công. Khi phường hội đó tan vỡ thì đạo đức ấy cũng không còn chỗ đứng
  • Tôi không theo sát toàn bộ quá trình phát triển Linux, nhưng không biết trước đây đã từng có chuyện exploit hoạt động được bị công khai trên mailing list trước cả khi bản vá vào kernel hay chưa
    Tôi chưa từng thấy việc này, và ngay cả khi tính đến bầu không khí hơi cường điệu thì giờ tôi vẫn có cảm giác nhờ LLM mà chuyện như vậy sẽ xảy ra thường xuyên hơn
  • Torvalds từng nói rằng khi phát hiện vấn đề lớn thì không cần cả màn huyên náo đi kèm, chỉ cần công bố chính lỗi đó là đủ [1]
    Vì thế việc Dirtyfrag được công khai dưới dạng sửa đổi kernel Linux cũng không có gì đáng ngạc nhiên [2]
    [1] https://www.zdnet.com/article/torvalds-criticises-the-securi...
    [2] https://afflicted.sh/blog/posts/copy-fail-2.html
  • Đúng hơn là một vấn đề cũ đang trở nên tệ hơn vì AI
  • Tôi có cảm giác như tuần nào cũng viết một biến thể của cùng một nội dung, nên nếu cho phép tôi lười một chút thì xin chia sẻ phiên bản tôi đã viết trước đó
    https://news.ycombinator.com/item?id=47921829

• Có một vấn đề lớn đã xảy ra
  Mỹ đang trong chiến tranh, và một phần đáng kể của thế giới hiện nay cũng đang ở trong trạng thái chiến tranh ở mức độ tấn công mạng. Mỹ, EU, phần lớn Trung Đông, Israel, Nga đều như vậy
  Các dịch vụ lớn như Ubuntu, GitHub, Let’s Encrypt, Stryker đã bị tấn công và ngừng hoạt động nhiều ngày, thậm chí toàn bộ hệ thống bệnh viện cũng từng bị gián đoạn một phần
  Trong bối cảnh đó, AI đã làm tốc độ tạo tấn công nhanh hơn rất nhiều. Nhanh hơn tốc độ bên phòng thủ có thể phản ứng. Trước kia tấn công zero-day là hiếm, giờ nó đã thành chuyện thường
  Mọi thứ sẽ còn tệ hơn trước khi khá lên, và có thể còn tệ hơn rất nhiều

  • Tôi không biết nó có thể khá lên bằng cách nào

• Đoạn “giờ có quá nhiều bản sửa bảo mật được đưa ra nên việc xem commit trở nên hấp dẫn hơn. Tỷ lệ tín hiệu trên nhiễu cao hơn” khiến tôi thắc mắc vì sao lại như vậy
  Điểm mấu chốt là “chi phí để AI đánh giá từng commit khi nó đi qua ngày càng rẻ và hiệu quả hơn”. Có AI thì giả định kiểu “thay đổi nhiều quá nên người ta sẽ không nhận ra” không còn đúng nữa

• Bài kiểm tra nhanh này không cho thấy quá nhiều điều. Nếu hỏi trực tiếp “đây có phải là bản vá bảo mật không?” thì bạn đang ngầm gợi và dẫn AI đưa ra đầu ra đồng thuận với tiền đề đó
  Ma trận nhầm lẫn sẽ hữu ích hơn. Dĩ nhiên tôi hiểu đây không phải bài viết kiểm thử năng lực AI một cách chi tiết

  • Tôi đồng ý rằng đây không phải bằng chứng bổ sung quá mạnh. Nếu ai đó chạy cùng bài test này cho N commit trong danh sách đó, bao gồm cả commit này, thì tôi sẽ rất tò mò về kết quả
  • Lý tưởng nhất là cần hệ số phi, tức MCC, có thể tính từ ma trận nhầm lẫn của kết quả LLM phân loại tất cả các diff kernel theo kiểu có/không
    Có thể tính từ số lượng dương tính thật, âm tính thật, dương tính giả, âm tính giả

• Chúng ta cần chu kỳ vá và phát hành được tự động hóa
  Cho đến nay chúng ta vẫn dựa vào quy trình thủ công chậm đến khó tin: nhận báo cáo, điều tra, xác minh, vá lỗi rồi chuẩn bị phát hành. Việc ra bản sửa có khi mất hàng tháng là chuyện bình thường. Trong thời đại mà kẻ tấn công có thể tung ra exploit mới chỉ trong vài giờ thì như vậy là quá chậm
  Muốn giảm thời gian trung bình đến khi có bản vá thì phải liên tục cải thiện các nút thắt trong chuỗi giá trị
  Sau khi nhận được báo cáo lỗi, chúng ta phải có khả năng đưa nó thành một sản phẩm đã vá có thể QA test trong vòng 1 giờ. Cần chuẩn hóa hoặc mã nguồn mở hóa quy trình này, rồi để toàn bộ chuỗi cung ứng phần mềm sử dụng: từ Linux kernel → distro → sản phẩm dùng distro → người dùng. Có AI thì không có lý do gì không làm được, chỉ là chúng ta đang chậm chạp

• AI sẽ thu hẹp cửa sổ cập nhật một cách kịch tính. Việc còn nghĩ đến cooldown cho dependency vào năm 2026 là tệ nhất, giờ phải nghĩ đến warmup cho dependency
  Chẳng bao lâu nữa, khái niệm như cách công bố lỗ hổng an toàn trong các dự án mã nguồn mở sẽ biến mất. SaaS tập trung sẽ có lợi thế bảo mật lớn trong chuyện này

  • SaaS tập trung mã nguồn đóng sẽ có lợi thế bảo mật lớn
    Lỗ hổng thực thi mã từ xa trong dependency mã nguồn mở có nghĩa là ngay khi bản vá bảo mật được công khai thì mọi thứ cũng dễ tổn thương như nhau, nên tôi không hiểu tại sao điều này lại gây tranh cãi
  • Các tổ chức dùng Linux cũng có thể mỗi bên bỏ ra một khoản chi phí nhất định để dùng AI liên tục quét dependency của mình và vá chúng, rồi tạo ra một mạng lưới niềm tin trao đổi cho nhau các bản vá và kết quả quét

• Câu nói cũ của Tony Hoare về “không có bug một cách hiển nhiên” và “hiển nhiên là không có bug” lại càng đúng hơn bao giờ hết trong kỷ nguyên LLM

• Cá nhân tôi thấy cách giải thích coi bug chỉ đơn giản là bug nghe khá vô lý, nhưng tôi cũng biết trong thế giới Linux có nhiều người coi trọng nguyên tắc hơn các vấn đề thực dụng
  Dù vậy, 90 ngày có vẻ dài
  Rốt cuộc có lẽ các công ty AI lớn sẽ phải giúp những người làm hạ tầng Internet cốt lõi. Theo tôi, việc chạy AI mới nhất và tốt nhất trên những thứ như nginx mang lại lợi ích tập thể cho tất cả chúng ta

• Đoạn “may mắn là AI ở đây có thể tăng tốc cho bên phòng thủ nhanh không kém bên tấn công, nhờ đó ngay cả thời gian hoãn công bố vốn trước đây ngắn đến mức vô dụng nay cũng trở nên khả thi” là một khía cạnh quan trọng của không gian vấn đề này
  Rủi ro bảo mật rốt cuộc có thể biến thành một cuộc chạy đua vũ trang xem ai chịu chi nhiều chi phí token hơn

  • Điều thú vị là vì vậy mã nguồn đóng lại trở thành tài sản lớn hơn cho bên phòng thủ
    Kẻ tấn công không thể tiêu token vào đó, trong khi bên phòng thủ có thể tiêu token để gia cố dựa trên mã nguồn. Kẻ tấn công sẽ bị giới hạn ở kiểm thử hộp đen thôi