Tin đồn về lỗ hổng cũng đủ để hacker tấn công: Đã đến lúc thay đổi cách phản ứng bảo mật mã nguồn mở

Hôm nay, tôi đã phát hành bản vá bảo mật cho cohttp 6.3.0 của OCaml nhằm khắc phục lỗi path traversal (truy cập đường dẫn trái phép). Bản vá này khá đơn giản và trong điều kiện bình thường, quy trình bảo mật sẽ là sửa lỗi một cách riêng tư, thông báo cho người dùng bị ảnh hưởng, sau đó mới đưa ra thông báo công khai. Tuy nhiên lần này, chỉ vài phút sau khi tôi mở PR (Pull Request) để sửa lỗi, tôi đã phát hiện các truy vấn trong nhật ký máy chủ web của mình có chứa đúng mẫu lỗi đó.

Tệ hơn nữa, tôi nhận ra mình có thể sử dụng các tác nhân (agent) của chính mình để tìm ra lỗ hổng chỉ bằng cách nắm sơ qua về vấn đề, nghĩa là tôi hoàn toàn có thể khai thác nó từ rất lâu trước khi bản vá công khai được tung ra! Khi mà chỉ cần tin đồn về một lỗ hổng bảo mật cũng đủ để cung cấp cho kẻ tấn công thông tin cần thiết để tìm ra các cách khai thác mới, chúng ta cần thay đổi cách tiếp cận phản ứng bảo mật trong mã nguồn mở (open source).

1 Tin đồn về một lỗi là tất cả những gì các hệ thống khai thác bằng tác nhân (agentic exploit systems) mới cần.

Báo cáo cụ thể này được gửi riêng tư qua kênh Slack từ Jane Street vào tuần trước, và bản thân nó cũng được tìm ra thông qua Claude Fable. Điều đó rút ngắn đáng kể mọi mốc thời gian...

1.1 Mốc thời gian của một báo cáo bảo mật hiện đại.

Trước khi xem xét kỹ bản vá, tôi đã yêu cầu Claude của riêng mình kiểm tra đoạn mã bị ảnh hưởng để xem còn những gì ẩn giấu (yêu cầu nó điều tra các vấn đề chuẩn hóa đường dẫn). Fable đã từ chối thẳng thừng do các rào cản bảo mật vì tôi không có quyền truy cập vào Glasswing, nhưng DeepSeek V4 Pro đã hỗ trợ tôi và độc lập tìm ra một vài vấn đề liên quan. Tác nhân của tôi cũng dễ dàng tạo ra một mã khai thác để thăm dò máy chủ cục bộ chỉ trong chưa đầy một phút.

Sau khi trao đổi qua lại với người báo cáo lỗi về các phương án sửa lỗi, tôi lặng lẽ mở cohttp#1145 công khai để có thêm nhiều người cùng xem xét. Việc này thường mất vài ngày và việc phát hành bản vá trong vòng một hoặc hai tuần là hợp lý. Chỉ trong khoảng mười phút (!) trang web này đã phải hứng chịu các truy vấn về chuỗi traversal được mã hóa phần trăm (percent-encoded), cho thấy các trình theo dõi tự động đang giám sát chặt chẽ các kho lưu trữ công khai.

Nếu tôi chỉ mất một phút để tự tạo mã khai thác cục bộ, thì mười phút thực sự là khoảng thời gian khá dài để một cuộc tấn công tự động bắt đầu! Một kẻ tấn công quyết tâm đang giám sát các kho lưu trữ gói có thể dễ dàng khai thác chúng chỉ trong vài giây.

1.2 Các lệnh cấm vận bảo mật không còn hiệu quả.

Quy trình bảo mật truyền thống bao gồm việc cấm vận (embargo) lỗi và giả định rằng việc giữ kín chi tiết sẽ bảo vệ người dùng. Tuy nhiên, tất cả những gì một tác nhân cần ngày nay chỉ là một hướng tìm kiếm rộng, và nó có thể tự thực hiện nghiên cứu. Fang và cộng sự đã phát hiện ra rằng khi được cung cấp mô tả CVE, tác nhân GPT-4 của họ đã khai thác thành công 87% trong số 15 lỗ hổng chuẩn, và nếu không có mô tả, con số đó chỉ là 7%.

Hai năm trôi qua, thời gian trung bình để khai thác là -7 ngày. Nói cách khác, việc khai thác hiện nay diễn ra trước cả bản vá! Chỉ số tương tự đó vào khoảng 63 ngày trong giai đoạn 2018-19 và đã vượt ngưỡng 0 vào năm 2024. Một tìm kiếm nhanh cho thấy rất nhiều trường hợp tương tự hiện nay... CVE-2026-39987 của marimo đã đi từ thông báo đến nỗ lực khai thác đầu tiên trong 9 giờ, ngay cả khi không có bằng chứng khái niệm (proof-of-concept) công khai nào tồn tại. CVE-2026-33017 của Langflow mất 20 giờ. Có vẻ như chúng ta đã vượt qua "con sông Rubicon" đối với việc tạo mã khai thác tự động...

Tình trạng khai thác bằng LLM vào năm 2026 (nguồn: Vulncheck).

2 Liệu "bugonomics" có đang chống lại những người bảo trì OSS (Open Source Software)?

Đối với tôi, có vẻ như các quy trình bảo mật của chúng ta cần phải đảo ngược phần nào, vì chỉ cần một người tìm kiếm lớp vấn đề đó (có thể là một câu hỏi trên danh sách gửi thư, một commit lạ trong nhánh mồ côi, hoặc rò rỉ ngữ cảnh) là đủ để cảnh báo tác nhân của người khác và cho phép họ lấy được mã khai thác. Điều này thật điên rồ.

Một bài báo vào tháng 5 năm 2026 đã đặt ra thuật ngữ "bugonomics" và lập luận rằng nút thắt cổ chai đã chuyển sang "tốc độ khắc phục của người bảo vệ". Các LLM đang vui vẻ tạo ra các mã khai thác, nhưng khả năng phòng thủ của chúng ta trước chúng không nhất thiết được cải thiện khi tốc độ xác thực, phân loại và phát hành của người bảo trì vẫn dậm chân tại chỗ. Điều này thật không may lại khớp với quan điểm từ vị trí người bảo trì OSS của tôi:

Câu hỏi không phải là liệu các mô hình tiên phong (frontier models), mô hình trọng số mở (open-weight models) hay phân tích chương trình sẽ "thắng". Câu hỏi là làm thế nào để điều phối chúng sao cho năng lực xác thực, ưu tiên và phát hành khan hiếm được hướng vào các bản sửa lỗi bền vững thay vì tìm kiếm máy móc và soạn thảo báo cáo. Một cơ hội cho người bảo vệ trung tâm là khắc phục nợ kỹ thuật: các quy trình làm việc có ngữ nghĩa, được công cụ xác minh và có sự hỗ trợ của mô hình, giúp người bảo trì tìm, xác thực, ưu tiên và sửa chữa các lỗi bảo mật trước khi chúng trở thành các lỗ hổng bị khai thác vào ngày mai. -- Demystifying the Mythos or Disrupting Bugonomics?, Pesoli et al, 2026.

Và tại sao năng lực của người bảo trì lại dậm chân tại chỗ? Chà, việc không có quyền truy cập vào các tác nhân tiên phong như Mythos là một lý do rõ ràng, nhưng cũng vì việc thiết kế một bản vá bảo mật không gây ra bất kỳ lỗi hồi quy (regression) nào về cơ bản là công việc nặng nhọc hơn nhiều.

3 Vậy chúng ta có thể làm gì về điều này?

Chúng ta rõ ràng cần thích nghi khá nhanh. Tôi không nghĩ quy trình phân loại thủ công hiện tại nên biến mất, nhưng tôi đã thấy một sự gia tăng hoạt động không bền vững kể từ khi Fable ra mắt. Chúng ta chỉ mới bắt đầu nắm bắt được bao nhiêu trong số "cơn lũ" tấn công đến từ máy móc, nhưng rõ ràng là rất nhiều.

Các công ty kỹ thuật lớn (như Google) đã xây dựng các bản cập nhật nhỏ (microupdates) trực tiếp vào phần mềm của họ để đảm bảo các bản sửa lỗi đến tay người dùng như một ưu tiên thay vì (ví dụ) phải sửa trong kho lưu trữ mã Chrome. Chúng ta thực sự không có sự xa xỉ đó trong Docker hoặc OCaml, vì chúng ta không kiểm soát các điểm cuối (endpoints) nơi phần mềm của mình được sử dụng. Ngoài Docker Desktop, các bản phân phối hạ nguồn (downstream distributions) đóng gói lại OSS theo thời gian và điều khoản riêng của họ là hoàn toàn đúng đắn.

Đối với các dự án nhỏ hơn như OCaml, chỉ riêng việc giành quyền truy cập vào các mô hình tiên phong đã là một cuộc đấu tranh. Các mô hình phương Tây có các rào cản bảo mật khiến chúng ta không thể sử dụng các mô hình thương mại sẵn có. Dự án Glasswing đã mở rộng ra 150 tổ chức tại 15 quốc gia bao gồm các nhà vận hành cơ sở hạ tầng quan trọng, các nhà cung cấp đám mây và tài chính, Linux Foundation, nhưng những người bảo trì nhỏ lẻ vẫn không có quyền truy cập. Tôi đã từng phân vân hồi tháng 4 liệu điều này có gây hại hay không, nhưng hôm nay thì khá rõ ràng là nó đang trở nên rất tồi tệ.

3.1 Phát triển bản vá riêng tư "siêu bí mật".

Cách khắc phục đầu tiên là phát triển các bản sửa lỗi ở một nơi thực sự riêng tư, nằm ngoài tầm với của AI. Các nhánh rẽ (fork) riêng tư tạm thời của GitHub về lý thuyết làm được điều này, nhưng nó không thực sự hiệu quả với chúng tôi.

Thứ nhất, GitHub hạn chế nó "để giữ an toàn thông tin về các lỗ hổng, các tích hợp, bao gồm cả CI, không thể truy cập vào các nhánh rẽ riêng tư tạm thời", điều này ngay lập tức ngắt kết nối người bảo trì khỏi nguồn sống là kết quả CI của chúng tôi. Thứ hai, chỉ một PR duy nhất có thể được hợp nhất vào nhánh rẽ, điều này không hiệu quả đối với các vấn đề thường trải dài trên vài kho lưu trữ. Những người đánh giá cũng phải được quản trị viên thêm vào từng người một, và trong thế giới mã nguồn mở, người đánh giá thường là những người ghé qua tùy thuộc vào ai đang rảnh (đặc biệt là vào tháng 8!).

Tuy nhiên, rộng hơn thì điều này lại bịt sai chỗ rò rỉ. Việc bản vá được giữ bí mật không quan trọng bằng việc đảm bảo mô tả về vấn đề đến đúng người mà không bị rò rỉ cho kẻ tấn công.

Chúng ta không có cơ sở hạ tầng thảo luận mạnh mẽ trong OSS vì nó được lan truyền qua nhiều kênh mã hóa đầu cuối khác nhau (chúng tôi sử dụng Matrix) nhưng cũng qua các cơ sở hạ tầng chia sẻ như Discord hoặc Slack, vốn cực kỳ dễ rò rỉ. Chúng ta cần một loại "web-of-trust" (mạng lưới tin cậy) để phân biệt người tốt và kẻ xấu trong một ngữ cảnh dự án cụ thể.

3.2 Không cấm vận, chỉ phát hành liên tục.

Một điều khác chúng ta có thể làm là nhanh chóng sửa lỗi công khai, phát hành liên tục và cải thiện lộ trình phát hành thông qua tự động hóa tốt hơn.

Các dự án lớn hơn như Chrome cho thấy điều này là khả thi thông qua các bản cập nhật bảo mật hàng tuần, hai bản phát hành mỗi tuần (!), và vá lỗi động (dynamic patching) thay thế các tiến trình nền bằng các tệp nhị phân đã cập nhật mà không cần khởi động lại. Đây không hoàn toàn là công nghệ mới; tôi đã từng tìm hiểu về việc tích hợp vá lỗi Linux ksplice trực tiếp với Xen hơn 15 năm trước. Nhân Linux cũng phát hành các bản sửa lỗi sớm nhất có thể, trì hoãn tối đa bảy ngày và trong trường hợp ngoại lệ là mười bốn ngày.

Tuy nhiên, đóng gói phần mềm là trở ngại chính của chúng ta. Chrome có công việc tương đối dễ dàng là vận chuyển một tệp nhị phân, nhưng OSS thường là một tập hợp các thư viện sau đó được nhúng vào nhiều sản phẩm hạ nguồn khác nhau. Vì vậy, để làm điều này, chúng ta sẽ cần:

3.3 Bảo vệ chủ động ở lớp giao thức.

Tôi cũng đã có những suy nghĩ cấp tiến hơn về cách chúng ta có thể áp dụng các biện pháp bảo vệ một cách linh hoạt để bảo vệ các điểm cuối sử dụng thư viện của chúng tôi. Nếu chúng ta chấp nhận rằng các bản vá lỗi thượng nguồn (upstream) sẽ luôn chậm hơn một bước so với mã khai thác, thì chúng ta phải đặt ra thứ gì đó nhanh hơn để đi trước.

Ví dụ, lỗi cohttp được sửa hôm nay có một biện pháp giảm thiểu đơn giản: chỉ cần chuẩn hóa các dấu phân cách đường dẫn được mã hóa phần trăm trong URL yêu cầu. Quy tắc này có thể thực hiện ngay khi báo cáo đến, và cũng có thể triển khai trong khi bản sửa lỗi đầy đủ đang được xem xét, kiểm thử và đóng gói. Vá lỗi ảo (virtual patching) là việc thường lệ trên cơ sở hạ tầng đám mây hiện nay; Cloudflare đã triển khai các quy tắc được quản lý để chặn Log4shell từ năm 2021.

Nhưng mã nguồn mở lại thiếu cơ chế phân phối cho các quy tắc như vậy bên ngoài một CDN thương mại. Đó là ý tưởng về mạng lưới "antibotty" từ bài báo về sinh thái internet của chúng tôi đang cố gắng giải quyết thông qua sự đa dạng phần mềm hơn trên Internet toàn cầu. Làm thế nào chúng ta có thể có các biện pháp phòng thủ cục bộ, lan truyền nhanh, biết về một lỗ hổng và hành động trên cơ sở hạ tầng của chúng ngay trong vài giây?

4 Một số hướng nghiên cứu tiếp theo.

Tôi nghĩ chúng ta sẽ cần kết hợp cả ba lựa chọn trong ngắn hạn. Một mạng lưới tin cậy (web-of-trust) nhẹ cho những người đóng góp OSS (giống như Advogato đáng kính trước đây), cũng như tập trung nhiều hơn vào việc đóng gói OSS và các cơ chế triển khai, phân loại liên tục mà không làm quá tải những người đóng góp bằng xương bằng thịt quý giá của chúng ta.

Tôi cũng đã đăng một vài ý tưởng nghiên cứu MPhil mới cho bất kỳ ai sắp đến Cambridge vào tháng tới và đang tìm kiếm một dự án.

Và nếu có ai từ Dự án Glasswing đang lắng nghe, đội ngũ OCaml rất cần quyền truy cập ngay bây giờ:-)

(Bản sửa lỗi cohttp không phải là nỗ lực của một cá nhân. Sapphire Livingstone đã tìm thấy và báo cáo vấn đề, hướng dẫn sửa lỗi và đồng phát triển biện pháp khắc phục; Michael Dales, Török Edwin và Patrick Ferris đã xem xét bản vá; Hannes Mehnert điều phối thông báo; và Thomas Gazagnaire đã suy nghĩ về vấn đề phân loại rộng hơn. Cảm ơn tất cả các bạn! Bugonomics có thể đang chống lại chúng ta, nhưng chúng ta sẽ vượt qua được đỉnh dốc này.)