Báo cáo bảo mật curl do AI tạo ra

 (daniel.haxx.se)
1 điểm bởi GN⁺ 2024-01-04 | 1 bình luận | Chia sẻ qua WhatsApp
  • Dự án curl vận hành chương trình bug bounty, và số lượng báo cáo bảo mật có vẻ được tạo bằng LLM đang tăng lên, khiến thời gian của lập trình viên bị tiêu tốn vào việc xác minh báo cáo giả thay vì xử lý lỗ hổng thực tế
  • Tính đến nay, curl đã chi trả hơn 70.000 USD và nhận 415 báo cáo, nhưng chỉ có 64 trường hợp là vấn đề bảo mật thực sự, còn 77 trường hợp được phân loại là informative
  • Cốt lõi của vấn đề là các báo cáo có tiếng Anh trông rất thuyết phục, mô tả chi tiết và thậm chí kèm cả bản vá đề xuất, làm tăng mạnh chi phí thẩm định
  • Năm 2023, đã có các báo cáo về việc lộ thay đổi mã của CVE-2023-38545 và lỗi tràn bộ đệm WebSocket, nhưng thực tế lần lượt không có vụ lộ nào và cũng không có tràn bộ đệm
  • AI có thể hữu ích như công cụ hỗ trợ dịch thuật, viết câu hoặc phát hiện lỗ hổng, nhưng việc nộp đầu ra LLM mà không có kiểm chứng của con người đang đẩy chi phí ứng phó bảo mật mã nguồn mở sang cho dự án

Các báo cáo chất lượng thấp mà bug bounty của curl đang phải đối mặt

  • Dự án curl vận hành chương trình bug bounty, trả tiền thưởng thực tế cho các hacker báo cáo vấn đề bảo mật
  • Khả năng nhận thưởng thu hút những “luck seekers” chỉ grep mẫu trong mã nguồn hoặc chạy các trình quét bảo mật cơ bản rồi gửi kết quả mà không phân tích đầy đủ
  • Trước đây, các báo cáo chất lượng thấp phần lớn có thể được nhận diện và loại bỏ khá nhanh, nên chưa trở thành vấn đề lãng phí thời gian nghiêm trọng cho dự án
  • Kết quả bug bounty của curl đến nay:
    • Đã chi trả hơn 70.000 USD tiền thưởng
    • Nhận 415 báo cáo lỗ hổng
    • Xác nhận 64 trường hợp là vấn đề bảo mật thực sự
    • 77 trường hợp được phân loại là informative, thường là lỗi thông thường hoặc tương tự
    • 66% tổng số báo cáo không phải là vấn đề bảo mật cũng không phải lỗi thông thường

Vì sao các báo cáo giả nhưng thuyết phục lại nguy hiểm hơn

  • Báo cáo giả càng tinh vi thì càng tốn nhiều thời gian điều tra và công sức trước khi có thể loại bỏ
  • Mọi báo cáo bảo mật đều cần con người trực tiếp đọc và đánh giá ý nghĩa thực tế
  • Công việc bảo mật thường dễ được ưu tiên cao, nên cả báo cáo giả cũng có thể đẩy lùi các công việc phát triển khác
  • Những báo cáo không cải thiện bảo mật thực tế lại lấy mất thời gian lẽ ra dùng để sửa các lỗi phiền toái hoặc phát triển tính năng mới
  • Việc phải liên tục xử lý các báo cáo chất lượng thấp cũng làm tăng mức tiêu hao năng lượng của lập trình viên

Các báo cáo bảo mật có vẻ do AI tạo ra

  • AI là công cụ đa dụng nên có thể được dùng cho mục đích tốt, nhưng cũng rất dễ bị sử dụng sai cách
  • AI có thể có tiềm năng được dùng một cách hiệu quả trong việc phát hiện và báo cáo vấn đề bảo mật, nhưng dự án curl đến nay vẫn chưa thấy ví dụ tốt nào
  • Hiện tại có vẻ người dùng đưa mã curl vào LLM rồi nộp đầu ra của nó như một báo cáo lỗ hổng bảo mật
  • Người dùng không chỉ sao chép nguyên văn đầu ra AI mà còn trộn thêm câu chữ của riêng mình, khiến việc phát hiện khó hơn
  • Dù toàn bộ báo cáo không trùng khớp hoàn toàn với câu chữ AI, kết quả cuối cùng vẫn có thể là một báo cáo không hợp lệ

Vì sao khó loại bỏ chỉ dựa trên dấu vết AI

  • Trong số người báo cáo có những người không thông thạo tiếng Anh, nên cần nhiều lượt hỏi đáp mới hiểu được ý của họ
  • Rào cản ngôn ngữ và văn hóa là có thật, và bản thân quá trình giao tiếp như vậy có thể được xem là điều tự nhiên
  • Một số người báo cáo dùng AI hoặc công cụ khác như hỗ trợ dịch thuật và viết câu để giao tiếp tốt hơn bằng ngoại ngữ
  • Ngay cả những người báo cáo không giỏi tiếng Anh cũng có thể tìm ra và báo cáo vấn đề bảo mật thực sự
  • Vì vậy, không thể lập tức loại bỏ chỉ vì một phần văn bản có dấu hiệu do AI tạo ra, và các báo cáo giả được viết khéo còn mất nhiều thời gian hơn để phân biệt

Trường hợp A: cáo buộc lộ thay đổi mã của CVE-2023-38545

  • Vào mùa thu năm 2023, cộng đồng curl được thông báo về việc sắp công bố CVE-2023-38545, được đánh giá ở mức độ nghiêm trọng high
  • Một ngày trước khi vấn đề đó được công bố, HackerOne nhận được báo cáo “Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet”
  • Chỉ nhìn tiêu đề thì đây là vấn đề có thể rất nghiêm trọng nếu là thật
  • Tuy nhiên, báo cáo trông như một kiểu hallucination điển hình của AI, trộn lẫn sự thật và chi tiết từ các vấn đề bảo mật cũ để tạo ra nội dung mới không liên hệ với thực tế
  • Các thay đổi của CVE-2023-38545 chưa từng bị công khai trên Internet, còn các thay đổi đã được công khai thì vốn liên quan đến một vấn đề cũ hơn như dự định ban đầu
  • Người báo cáo nói rằng họ đã dùng Bard để tìm ra vấn đề này, nhờ đó việc xác định sai sót và đóng báo cáo trở nên dễ dàng hơn

Trường hợp B: cáo buộc tràn bộ đệm WebSocket

  • Vào sáng ngày 28/12/2023, HackerOne nhận được báo cáo “Buffer Overflow Vulnerability in WebSocket Handling”
  • Chỉ nhìn tiêu đề thì có vẻ nghiêm trọng, nhưng mã WebSocket của curl khi đó vẫn là tính năng thử nghiệm, nên không thuộc phạm vi bug bounty
  • Người báo cáo là người dùng chưa từng thấy trước đó, nhưng có uy tín HackerOne khá tốt và đây cũng không phải báo cáo bảo mật đầu tiên của họ
  • Báo cáo được trình bày tốt, có chi tiết, câu chữ tiếng Anh phù hợp và cả bản vá đề xuất
  • Ban đầu nó trông còn tốt hơn một báo cáo đầu tiên ở mức trung bình, và dường như người báo cáo hiểu vấn đề cũng như đã đưa ra giải pháp
  • Sau 19 phút kiểm tra mã nhiều lần, vẫn không thể tìm thấy tràn bộ đệm như đã bị cáo buộc
  • Sau nhiều lượt hỏi lại và nhiều câu trả lời mang tính hallucination, dự án kết luận đây không phải vấn đề thực sự và đóng báo cáo là not applicable ngay chiều hôm đó
  • Không thể chắc chắn các câu trả lời này có phải do LLM tạo ra hay không, nhưng có nhiều dấu hiệu để lại

Tính năng chặn của HackerOne và chế tài uy tín

  • Ban đầu tác giả cho rằng HackerOne không có chức năng chặn rõ ràng người báo cáo khỏi các trao đổi tiếp theo với dự án
  • Tác giả nói rằng nếu có tính năng đó thì mình đã dùng
  • Khi một issue bị đóng là not applicable, uy tín HackerOne của nhà nghiên cứu sẽ giảm, nhưng nếu chỉ xảy ra một lần ở một dự án đơn lẻ thì tác dụng răn đe là rất nhỏ
  • Trong phần cập nhật sau đó, tác giả bổ sung rằng chức năng đó thực ra có tồn tại, chỉ là trước đó đã không nhìn đúng chỗ

Sẽ còn nhiều báo cáo do LLM tạo ra hơn nữa

  • Loại báo cáo này được dự đoán sẽ ngày càng phổ biến theo thời gian
  • Các dự án có thể học cách nhận diện tốt hơn các tín hiệu generated-by-AI và dùng đó làm cơ sở để loại bỏ báo cáo
  • Tuy nhiên, điều đó cũng có thể gây bất lợi cả cho những trường hợp AI được dùng đúng cách, như hỗ trợ dịch thuật hoặc soạn câu
  • Trong tương lai, có thể sẽ xuất hiện một số công cụ dùng AI để tìm vấn đề bảo mật hoạt động hiệu quả hơn thật sự
  • Chỉ cần thêm vào dù ở mức rất nhỏ sự kiểm chứng của con người, tính hữu dụng và kết quả của các công cụ này cũng có thể tốt hơn rất nhiều
  • Việc tìm đường tắt để săn tiền thưởng nhanh nhiều khả năng vẫn sẽ tiếp diễn, và do môi trường dễ tiếp cận các LLM mạnh, hộp thư đến HackerOne được dự đoán sẽ nhận thêm nhiều báo cáo chất lượng thấp hơn

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-04
Ý kiến trên Hacker News

  • Những câu như “Tất nhiên rồi! Tôi sẽ giải thích chi tiết hơn về những lo ngại mà người phụ trách phân loại đã nêu ra” là kiểu giọng văn của LLM điển hình, nghe như một quản gia robot
    Gần như không thấy người thật viết như vậy, và việc nhắc đến “người phụ trách phân loại” ở ngôi thứ ba cũng rất kỳ lạ, như thể có một chủ thể khác đang dẫn dắt câu trả lời
    Việc LLM có một giọng văn đặc trưng có thể nhận ra thì không sao, điều đáng lo là không phải LLM nói như con người mà là con người bắt đầu nói như LLM

    • Daniel Stenberg[1] đã chỉ ra một điểm rất hay: curl được dùng trên toàn thế giới, nên việc một người không nói tiếng Anh bản ngữ dùng LLM hỗ trợ để viết báo cáo lỗi là điều hoàn toàn không lạ
      Vì vậy, chỉ dựa vào dấu hiệu bề mặt rằng câu tiếng Anh trông giống do LLM tạo ra thì không thể kết luận rằng chính nội dung báo cáo cũng do LLM bịa ra

      [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

    • Giá mà có ai đó đang viết một tác phẩm khoa học viễn tưởng phản địa đàng nơi các chúa tể robot liên tục xin lỗi và nói những câu như “Suy cho cùng, việc có đầu hàng hay không phụ thuộc vào nhu cầu và sở thích cụ thể của quý vị”

    • Nghe câu “nghe như quản gia robot” xong tôi bỗng hiểu ngay cụm Butlerian Jihad

    • Ở Ấn Độ, tiếng Anh đôi khi được dạy theo kiểu Anh ngữ thời thuộc địa dành cho tầng lớp hầu cận, kiểu “giọng quản gia”
      Nếu đến giờ bạn vẫn chưa gặp kiểu nói này thì chắc là chưa từng làm việc với bộ phận hỗ trợ kỹ thuật doanh nghiệp của Microsoft

    • Chắc chắn đây là một dấu hiệu cảnh báo lớn, nhưng nếu đúng là người thật đã chuyển nguyên đống nội dung rác đó thì chỉ cần xóa đúng một dòng đó đi là xong
      Nội dung vẫn sẽ đáng ngờ, nhưng sẽ có ít manh mối để nhận ra hơn nhiều

  • Những người săn “tiền thưởng kiểu ăn xin” đã khiến việc vận hành chương trình bug bounty vốn đã rất đau đầu
    Trước đây, ít nhất vẫn cần người thật bỏ thời gian tạo ra một “báo cáo lỗi” về cơ bản là chẳng có gì cả, nhưng với LLM thì có thể tạo báo cáo giả gần như miễn phí, nên chuyện này có thể thật sự vượt ngoài tầm kiểm soát
    Cá nhân tôi nghĩ điều này thậm chí có thể là dấu chấm hết cho các chương trình bug bounty
    Hoặc có lẽ phải siết chặt hơn: nhận đơn đăng ký tham gia chương trình, xác minh với chi phí thấp rằng đó là người thật, là nhà nghiên cứu bảo mật thực sự và đang cố tìm lỗi bảo mật có tác động, rồi chỉ những người được duyệt mới được gửi bug và nhận thưởng tiền

    • Đã có những nền tảng cung cấp chức năng như vậy
      Họ quản lý một pool các nhà nghiên cứu đã được biết đến, theo dõi trạng thái của họ và cho phép điều chỉnh mức độ công khai của chương trình
      Một số còn có cả bộ phận phân loại, nhưng thành bại phụ thuộc khá nhiều vào việc dự án đó có điển hình hay không
    • Cũng có thể áp dụng phí nộp báo cáo
      Không chắc có giúp được không, nhưng ít nhất nó có thể là biện pháp răn đe với các đợt nộp rác do máy tạo hàng loạt
      Kịch bản tệ nhất là một đống rác AI bị nộp ồ ạt, rồi để “giải quyết” lại đưa vào một bộ lọc AI tệ hại không kém, khiến chất lượng tổng thể của mọi người tham gia với thiện chí đều đi xuống

  • Ban đầu tôi tưởng bài này là bản trùng của https://news.ycombinator.com/item?id=37904047, nhưng hóa ra đó là một báo cáo lỗ hổng giả do LLM tạo ra khác nhắm vào curl trên HackerOne

    • May là tôi không bị điên
      Khi đọc tôi chắc chắn là mình đã thấy chuyện này trước đây rồi, mà nó còn giống vụ lần trước đến mức kỳ lạ
      Với những dự án nổi tiếng như Curl, có phải người ta cứ mở hết lần này đến lần khác các báo cáo sự cố do LLM viết chỉ để thêm một dòng vào CV không
    • Khách hàng của HackerOne là các công ty vận hành chương trình bug bounty
      Có lẽ họ nên quản lý chặt hơn những người có thể gửi spam rác LLM chỉ để đánh bóng tên tuổi đến cho khách hàng
    • Tôi hoàn toàn không biết chuyện này từng xảy ra trước đây
      Vậy thì vụ lần này càng trở thành một tiền lệ rõ ràng hơn

  • Điều tôi lo nhất là chỉ vài xu chi phí LLM đã làm lãng phí rất nhiều thời gian kỹ thuật đắt đỏ và quan trọng
    Thử tưởng tượng sẽ phải bỏ ra bao nhiêu công sức để gỡ rối đủ loại thông tin giả đang được tạo ra lúc này, nó khá giống với định luật Brandolini

    • Đúng vậy, LLM có tiềm năng phá hỏng một phần rất lớn của Internet, và tôi không biết đây có phải là vấn đề giải quyết được hay không
      Các mô hình hiện tại vẫn còn lộ dấu vết, nhưng các mô hình tương lai sẽ khác và tốt hơn
      Việc phát hiện và ngăn chặn sẽ trở thành một cuộc chạy đua vũ trang, đến mức nhiều người làm việc hiệu quả và nhiều nền tảng có thể không theo kịp

  • Điều thú vị là chúng ta đã biến viết lách, phương tiện băng thông thấp nhất để chứng minh hành vi và nỗ lực, thành thứ đòi hỏi nhiều công sức hơn rất nhiều để xác định xem liệu có thật sự có hành vi hay nỗ lực phía sau hay không
    Tác động lan tỏa có lẽ sẽ rất lớn
    Ở đây cả người báo cáo lẫn người quản lý đều đã lãng phí thời gian vốn có thể dùng vào việc hữu ích hơn, còn toàn bộ bug bounty và quy trình CVE dựa trên crowdsourcing thì bị tổn hại vì tỷ lệ tín hiệu trên nhiễu đã giảm xuống
    Kết quả là rào cản nộp báo cáo có khả năng sẽ tăng lên để chống spam, điều này có thể dẫn đến ít lỗi được phát hiện và sửa hơn, nhiều lỗ hổng bảo mật hơn, và kéo theo mọi vấn đề liên quan
    Cùng một động lực đó cũng sẽ diễn ra ở các lĩnh vực khác, khiến người ta ngày càng khó đặt niềm tin vào đánh giá sản phẩm, tài liệu nộp cho tòa án, công thức nấu ăn, hướng dẫn sử dụng, lời khuyên y tế...
    Một trong những lời hứa của Internet là sự mở rộng nhanh chóng của nội dung nhờ dân chủ hóa xuất bản, nhưng giờ có cảm giác như chúng ta đang chứng kiến ngay cả những lợi thế còn sót lại cũng bị rỗng ruột dần

  • Việc coi kiểm tra ranh giới độ dài là vấn đề ở đây đặc biệt kỳ lạ
    Vì hoàn toàn không có dữ liệu do người dùng cung cấp nào được dùng đến, và mọi kích thước đều là hằng số tĩnh tại thời điểm biên dịch
    curl đang đưa một chuỗi ngẫu nhiên 16 byte được mã hóa base64, tức 25 byte ASCII cộng thêm ký tự kết thúc null \0, vào một buffer tĩnh 40 byte

    https://github.com/curl/curl/blob/1d8e8c9ad1ff3351386422535f...

Và hỏi hoàn toàn vì tò mò thôi: có ai rành C hơn tôi có thể giải thích vì sao ở đây lại dùng biến cục bộ keyval không
Sao không đơn giản gán heads[3].val = randstr, rồi khi xử lý xong dữ liệu header thì free() luôn
Và vì sao keyval lại là 40 byte chứ không phải 26 hay 32 byte

  • Có lẽ mục đích là giảm số chỗ phải gọi free, và giảm khả năng quên việc đó
    Nhìn dòng 580 thì có vẻ chuyện đó đã có thể xảy ra, nhưng trên thực tế có khi trường hợp ấy hoàn toàn không bao giờ xảy ra

  • Nếu vậy thì bỏ luôn cả randstr lẫn keyval, vì dù sao cũng đã cấp phát rồi nên cứ mã hóa thẳng vào &heads[3].val là được
    Dù vậy vẫn phải truyền randlen vô dụng, nếu không thì sẽ bị crash
    Đúng là vẻ đẹp rất “đặc trưng” của tham số đầu ra trong C
    Điệu nhảy “sao chép từ heap sang biến stack” này cũng không hề giảm bớt công dọn dẹp
    Vì sau bước mã hóa thì đằng nào cũng chỉ còn một đường trả về duy nhất
    Tuy nhiên, nếu ban đầu cứ “xếp sẵn” các biến cần dùng ở phía trên rồi sau đó mới nhận ra Curl_base64_encode luôn cấp phát, thì cũng có thể hiểu vì sao đoạn mã hiện tại lại ra hình thù như vậy

  • Dùng stack thì gần như miễn phí vì không gian đã được dành sẵn trong quá trình thiết lập hàm và sẽ tự động được dọn khi hàm trả về
    Dùng heap thì cần nhiều thao tác hơn, có thể thất bại và cần dọn dẹp thủ công

  • Một trong những bài học quan trọng học được từ thời trung học là cách phân biệt giữa điều sai được diễn đạt một cách bóng bẩy và điều đúng được diễn đạt một cách vụng về
    Nhưng điều đó có thể rất khó
    Người ta có xu hướng dùng ngữ pháp và văn phong đúng làm bộ lọc đầu tiên cho diễn ngôn trí tuệ, và LLM thì cực kỳ cực kỳ giỏi trong việc làm cho hình thức ngôn ngữ trông có vẻ thuyết phục

    • Cũng tự hỏi không biết bài học đó đã thấm đến mức nào với bản thân hồi ấy và với các bạn cùng lớp
      Đây là một vấn đề rất nan giải, và tôi nghĩ đa số người lớn cũng chưa sẵn sàng để xử lý nó
      Người bình thường thực ra hoàn toàn đủ khả năng phân biệt hai thứ đó, nhưng vấn đề là họ phải quen với việc đọc có hệ thống và bỏ công sức ra
      Khi đang lướt điện thoại lúc đêm khuya thì làm vậy là rất khó

  • Nếu không vì bực bội và tốn thời gian thì chuyện dineshsec / dinesh_b định dạy Daniel cách dùng strncpy hẳn đã buồn cười
    Đầu tiên họ tag Daniel bằng một handle ngẫu nhiên, rồi tiếp theo còn bịa ra đoạn “mã có vấn đề như sau:” kèm một đoạn code không hề tồn tại

    • Đây là một vấn đề điển hình của việc lạm dụng LLM
      Người dùng muốn phân tích thứ gì đó nhưng nó quá dài nên cắt ra thành nhiều yêu cầu
      Đến lúc chạm vào phần cốt lõi thì đoạn mã ban đầu đã trôi khỏi ngữ cảnh, và mô hình bắt đầu tự tin tuôn ra những thứ nghe có vẻ hợp lý nhưng thực ra không hề tồn tại

  • Không phải strcpy hay strncpy, mà nên dùng memcpy
    Đặc biệt, strncpy chắc chắn là lựa chọn tệ nhất trong ba cái
    Đoạn mã đã biết kích thước bộ đệm nguồn và cũng đã kiểm tra xem nó có vừa bộ đệm đích hay không, nên không có lý do gì phải gọi strcpy chỉ để đo lại độ dài chuỗi một cách không cần thiết
    Thành thật mà nói thì khuyến nghị của LLM là kiểu tôi muốn can ngăn quyết liệt
    Nếu bạn không biết kích thước, không quan tâm đến việc bị cắt ngầm, và cũng không quan tâm hiệu năng, thì cứ dùng snprintf
    strncpy sẽ vô ích điền 0 vào phần còn lại của bộ đệm
    Trừ khi bạn đang xử lý thứ như UI, còn không thì đa phần bạn nên quan tâm đến việc bị cắt bớt, và trong trường hợp đó strncpy không cứu được bạn

  • Có vẻ liên quan đến chuyện này: https://news.ycombinator.com/item?id=38840907