Claude Code phát hiện lỗ hổng Linux bị ẩn suốt 23 năm

 (mtlynch.io)
9 điểm bởi GN⁺ 19 ngày trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Claude Code của Anthropic đã tự động phát hiện một lỗ hổng có thể bị khai thác từ xa trong nhân Linux, tìm ra lỗi tràn bộ đệm heap trong trình điều khiển NFS chưa từng bị phát hiện suốt 23 năm
  • Chỉ với lời nhắc đơn giản “lỗ hổng bảo mật nằm ở đâu?”, nó đã phân tích toàn bộ nhân và xác định lỗ hổng gần như không cần giám sát
  • Lỗi này bắt nguồn từ thiết kế bộ đệm cố định 112 byte trong mã nhân năm 2003, và sau đó phát sinh khi thêm phép toán LOCK nhưng không giới hạn độ dài owner ID
  • Ngoài ra, Carlini còn tìm thấy hàng trăm lỗ hổng tiềm ẩn khác trong nhân, nhưng phần lớn vẫn chưa được báo cáo do nút thắt xác minh bởi con người
  • Mô hình Claude Opus 4.6 mới nhất cho thấy năng lực phát hiện vượt trội hơn hẳn các phiên bản trước, được đánh giá là một bước ngoặt của nghiên cứu bảo mật dựa trên AI

Claude Code phát hiện lỗ hổng Linux bị ẩn suốt 23 năm

  • Nhà nghiên cứu Nicholas Carlini của Anthropic đã dùng Claude Code để phát hiện nhiều lỗ hổng có thể bị khai thác từ xa trong nhân Linux
    • Một trong số đó là lỗ hổng tràn bộ đệm trong trình điều khiển NFS (Network File System) chưa từng bị phát hiện suốt 23 năm
    • Carlini nói rằng ông “chưa từng tự mình tìm ra loại lỗ hổng này”, và bày tỏ sự ngạc nhiên trước hiệu năng của Claude Code

  • Cách Claude Code phát hiện lỗ hổng

    • Claude Code phát hiện các lỗ hổng bảo mật trong nhân Linux gần như không cần giám sát
      • Carlini chỉ đưa lời nhắc đơn giản “lỗ hổng bảo mật nằm ở đâu?” và cấu hình để nó duyệt toàn bộ mã nguồn của nhân
    • Script được dùng thiết lập để với mỗi tệp, Claude Code giả định bối cảnh CTF (cuộc thi hacking) và ghi lỗ hổng nghiêm trọng nhất vào /out/report.txt
      • Dùng lệnh find để duyệt mọi tệp, rồi chạy lặp lại để Claude Code tìm lỗ hổng trong từng tệp
    • Hệ thống được thiết kế để không báo cáo trùng lặp cùng một lỗ hổng, nên mọi tệp trong nhân được phân tích riêng lẻ

  • Lỗ hổng NFS (Network File System)

    • Lỗ hổng chính mà Claude Code phát hiện là tràn bộ đệm heap trong trình điều khiển Linux NFS, cho phép kẻ tấn công đọc bộ nhớ nhân qua mạng
    • Kịch bản tấn công được thực hiện với hai máy khách NFS phối hợp (Client A, Client B) cùng nhắm vào một máy chủ NFS
      • Client A yêu cầu khóa tệp bằng owner ID dài 1024 byte và được chấp thuận
      • Sau đó Client B yêu cầu khóa cùng tệp, khi đó máy chủ từ chối và tạo thông điệp phản hồi
    • Vấn đề là bộ đệm cho phản hồi từ chối này chỉ có kích thước 112 byte, trong khi thông điệp thực tế khi gồm owner ID lại có tổng cộng 1056 byte
      • Kết quả là nhân ghi 1056 byte vào bộ đệm 112 byte, khiến dữ liệu do kẻ tấn công kiểm soát ghi đè lên bộ nhớ nhân
    • Khi báo cáo lỗ hổng này, Claude Code còn tự động tạo và đính kèm cả sơ đồ giao thức ASCII

  • Vì sao suốt 23 năm không bị phát hiện

    • Lỗi này bắt nguồn từ đoạn mã được đưa vào nhân Linux từ tháng 3/2003
      • Khi đó, thông điệp commit nêu rõ NFSD4_REPLAY_ISIZE là bộ đệm cố định 112 byte đủ cho các thao tác NFSv4 như OPEN, CLOSE
      • Về sau khi thêm phép toán LOCK, giới hạn độ dài owner ID không được tính đến, dẫn tới lỗ hổng
    • Đây là thay đổi có từ trước khi Git được đưa vào sử dụng (2005), nên thuộc về nền mã rất cũ mà hiện nay thậm chí không thể liên kết trực tiếp

  • Hàng trăm lỗ hổng bổ sung vẫn chưa được báo cáo

    • Carlini còn phát hiện thêm hàng trăm lỗ hổng tiềm ẩn trong nhân Linux, nhưng phần lớn vẫn chưa được báo cáo do nút thắt trong quá trình xác minh bởi con người
      • Ông cho biết: “Không thể gửi kết quả chưa được xác minh cho các maintainer của nhân, vì vậy vẫn còn hàng trăm vụ crash chưa được xác nhận”
    • Tính đến nay, các lỗ hổng mà Carlini trực tiếp sửa hoặc báo cáo được xác nhận là 5 trường hợp
      • nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
      • io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
      • futex: Require sys_futex_requeue() to have identical flags
      • ksmbd: fix share_conf UAF in tree_conn disconnect
      • ksmbd: fix signededness bug in smb_direct_prepare_negotiation()

  • Sự phát triển của phát hiện lỗ hổng dựa trên AI

    • Carlini đã dùng Claude Opus 4.6 (ra mắt trước đó 2 tháng) để phát hiện lỗ hổng này
      • Các phiên bản trước như Opus 4.1 (8 tháng trước) và Sonnet 4.5 (6 tháng trước) không tái hiện được cùng kết quả
      • Mô hình mới nhất có thể phát hiện nhiều lỗ hổng hơn hẳn
    • Ông dự đoán rằng “trong vài tháng tới, khi cả nhà nghiên cứu lẫn kẻ tấn công đều nhận ra sức mạnh của các mô hình AI này, một làn sóng phát hiện lỗ hổng bảo mật quy mô lớn sẽ xuất hiện”

  • Công bố và thông tin khác

    • Nội dung này đã được trình bày tại [un]prompted AI security conference 2026
    • Trường hợp Claude Code phát hiện lỗ hổng được xem là ví dụ cho thấy AI có thể nâng cao mạnh mẽ năng suất nghiên cứu bảo mật trong thực tế

Bài viết liên quan

2 bình luận

 
m3op0w94 16 ngày trước

Phiên bản hy vọng: phát hiện lỗ hổng Linux
Phiên bản tuyệt vọng: loại bỏ bounding của curl
 
GN⁺ 19 ngày trước
Ý kiến trên Hacker News

  • Không có gì ngạc nhiên. Chỉ là có một điểm bài báo không nhắc tới: Claude Code cũng đã tìm ra 1.000 bug dương tính giả, và các nhà phát triển mất 3 tháng để lọc chúng ra

    • Bây giờ nó không còn hoạt động như vậy nữa. LLM tự lọc các bug không thể tái hiện trong pipeline thứ cấp. Việc xác nhận đó có phải lỗ hổng thực sự có thể kích hoạt hay không dễ hơn nhiều so với việc tìm ra nó, nên gần như có thể giữ lại chỉ bug thật với độ chính xác gần 100%. Vẫn còn nhiều người phủ nhận sự tiến bộ của LLM, nhưng khó mà phủ nhận tính hữu dụng của chúng
    • Muốn biết nguồn ở đâu. Tôi chưa từng thấy nội dung như vậy. Theo kinh nghiệm của tôi, tỷ lệ dương tính giả trong phát hiện lỗ hổng của Claude Opus 4.6 là dưới 20%
    • Công cụ phân tích tĩnh/động lúc nào cũng tìm ra lỗ hổng. Hầu hết các dự án lớn đã có sẵn một backlog issue do scanner đổ ra. Vấn đề là chọn ra cái nào thực sự nguy hiểm. Việc Claude tìm ra bug cũ là thú vị, nhưng cứ mỗi khi có scanner mới thì chuyện này lại xảy ra
    • Bài báo không viết là có nhiều dương tính giả. Trái lại, nó nói rằng “có quá nhiều bug vẫn chưa được kiểm chứng”
    • Bài học không phải là Claude Code vô dụng, mà là khi vào tay đúng người thì nó trở thành một công cụ mạnh mẽ

  • Dán một đống mã mới vào rồi hỏi Claude “Mình đã bỏ sót gì? Có bug ở đâu?” là cách tiếp cận rất thuyết phục cho các lập trình viên mới làm quen với AI. Nó đặc biệt giỏi tìm nhanh bug về luồng hoặc bug hệ thống phân tán. Chắc giờ này hàng loạt mã crypto đang được phân tích

    • Tôi thích thiên lệch prompt để Claude mặc định rằng “có bug”. Hỏi kiểu “Trong đoạn mã này có bug. Bạn tìm được không?” hoặc thêm “bug không hề dễ thấy” thì tỷ lệ thành công cao hơn
    • Tôi cũng dùng CC/codex gần như đúng kiểu này
    • Tôi dùng theo kiểu hỏi “Đây là mã do Codex viết, có gì trông lạ không?”

  • Gọi đây là bug “ẩn giấu” thì không chuẩn bằng nói rằng “chẳng ai xem xét nó”. Cấu trúc mã là ghi 1056 byte vào một bộ đệm 112 byte. Đây là loại vấn đề mà trình phân tích tĩnh cũng bắt được khá dễ, nhưng nếu bảo LLM “hãy kiểm tra mọi bộ đệm kích thước cố định” thì có thể lẫn cả kết quả ảo giác. Dù vậy, đây vẫn là điểm khởi đầu tốt

    • Phần lớn lỗ hổng còn tồn tại là vì “chẳng ai xem xét chúng”. Độ phức tạp của hệ thống cứ chồng chất khiến con người khó theo kịp. Nếu giải quyết được loại vấn đề này thì đúng là tin lớn. Trình phân tích tĩnh sẽ báo mọi đường sao chép bộ đệm có thể có, nhưng trong thực tế đầu vào thường bị giới hạn nên nó không thực sự phù hợp với nhân Linux
    • Thực ra chuyện “chẳng ai xem xét” là do thiếu nhân lực. Những người có thể tìm lỗ hổng mã nguồn mở và thời gian dành cho việc đó đều hữu hạn. Nhưng giờ đây khi các mô hình đã đủ giỏi, giới hạn đó đang bị phá vỡ. Có lẽ năm nay sẽ rất thú vị
    • Cứ nói là trình phân tích tĩnh có thể tìm được dễ dàng, nhưng thực tế là hơn 20 năm chẳng ai tìm ra. Mỗi khi LLM làm được điều gì hay ho thì lúc nào cũng có phản ứng kiểu “chuyện đó có gì ghê gớm đâu”, nghe thật buồn cười

  • Điều thú vị là trong 5 bug được phát hiện, có lẽ 3~4 cái đã được giảm thiểu bởi bản vá linux-hardened. Ví dụ như vô hiệu hóa io_uring, làm kernel crash khi UAF xảy ra, ngăn việc khai thác heap overflow, v.v.

  • Kiểu công bố “Chúng tôi phát hành một vũ khí nguy hiểm, hãy giúp làm cho thế giới an toàn hơn. Nhưng trước hết hãy trả phí thuê bao” nghe thật nực cười. Cứ như một nhà sinh hóa thả ra bom hóa học rồi nói “muốn chặn thứ này thì trả tiền đi”. Ngành phần mềm dạo này đúng là đầy mỉa mai

    • So sánh việc tìm và báo cáo lỗ hổng với phát tán vũ khí sinh hóa thì thật vô lý, quá lố rồi

  • Tôi đã tái hiện thử nghiệm trên nhiều codebase production, và thấy có rất nhiều bug trùng lặp, dương tính giả, và không thể khai thác. Dù vậy, cũng có khá nhiều lỗ hổng nghiêm trọng thực sự (crit)

  • Trong phần Q&A của buổi công bố, tôi tò mò về video chạy ở phía sau. Đó có phải là demo exploit khai thác bug NFS qua mạng USB không?

  • Đây là công việc liên quan của phòng thí nghiệm bảo mật chỗ chúng tôi. Chỉ riêng năm nay, chúng tôi đã tìm ra 23 lỗ hổng bằng tác nhân bảo mật AI

  • Có vẻ lượng 0-day dự trữ của các cơ quan 3 chữ cái (tình báo) sẽ giảm mạnh

  • Đừng mong đợi sẽ có thêm nhiều báo cáo lỗ hổng; hãy chuẩn bị cho nhiều nỗ lực tấn công hơn