1 คะแนน โดย GN⁺ 2024-01-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ค่าตอบแทนบั๊ก

  • โครงการค่าตอบแทนบั๊กมอบเงินรางวัลจริงเมื่อแฮ็กเกอร์รายงานปัญหาด้านความปลอดภัย
  • บางคนหวังรับรางวัลโดยมองหารูปแบบจากซอร์สโค้ดหรือรันเครื่องสแกนความปลอดภัยพื้นฐาน แล้วส่งผลลัพธ์โดยไม่วิเคราะห์เพิ่มเติม
  • ตลอดหลายปีที่ดำเนินโครงการ สัดส่วนของรายงานขยะไม่ได้เป็นปัญหาใหญ่ และส่วนมากตรวจจับได้ง่ายและมองข้ามได้
  • จนถึงตอนนี้มีการจ่ายค่าตอบแทนบั๊กไปแล้วมากกว่า 70,000 USD และจากรายงานช่องโหว่ 415 ฉบับ มี 64 ฉบับที่ยืนยันว่าเป็นปัญหาด้านความปลอดภัยจริง

ขยะที่ดีขึ้น แย่กว่าเดิม

  • หากทำให้รายงานดูดีขึ้นและเหมือนมีประเด็นมากขึ้น ก็จะยิ่งใช้เวลามากขึ้นในการตรวจสอบและคัดทิ้ง
  • รายงานด้านความปลอดภัยต้องอาศัยคนใช้เวลาตรวจอ่านและประเมินว่ามีความหมายจริงหรือไม่
  • รายงานขยะไม่ได้ช่วยโครงการ และดึงเวลาและพลังงานของนักพัฒนาออกจากงานที่มีประสิทธิผล

รายงานความปลอดภัยที่สร้างโดย AI

  • AI ทำเรื่องดี ๆ ได้มากมาย แต่ก็อาจถูกใช้ในทางที่ผิดได้เช่นกัน
  • AI อาจถูกใช้อย่างมีประโยชน์เพื่อค้นหาและรายงานปัญหาความปลอดภัยได้ แต่จนถึงตอนนี้ยังไม่พบตัวอย่างที่ดีเช่นนั้น
  • ขณะนี้ผู้ใช้จำนวนมากกำลังหมกมุ่นกับการใช้ LLM วิเคราะห์โค้ดของ curl แล้วส่งผลลัพธ์เป็นรายงานช่องโหว่ด้านความปลอดภัย

การตรวจจับขยะจาก AI

  • ผู้รายงานอาจไม่ได้เชี่ยวชาญภาษาอังกฤษเต็มที่ ทำให้บางครั้งเข้าใจเจตนาได้ไม่ทันที
  • บางครั้งผู้รายงานใช้ AI หรือเครื่องมืออื่นเพื่อช่วยเรียบเรียงหรือแปลสิ่งที่ต้องการสื่อ
  • การมีข้อความบางส่วนที่สร้างโดย AI หรือเครื่องมือคล้ายกัน ไม่ได้หมายความว่าเป็นปัญหาในทันที

ตัวอย่าง A: การเปิดเผยการเปลี่ยนแปลงโค้ด

  • ช่วงฤดูใบไม้ร่วงปี 2023 มีการประกาศล่วงหน้าเกี่ยวกับ CVE-2023-38545
  • หนึ่งวันก่อนมีการประกาศปัญหา ผู้ใช้ได้ส่งรายงานบน Hackerone: การเปลี่ยนแปลงโค้ดของช่องโหว่ Curl CVE-2023-38545 ถูกเปิดเผยบนอินเทอร์เน็ต
  • รายงานนี้มีกลิ่นอายของภาพหลอนแบบ AI: สร้างเรื่องใหม่ที่ไม่เชื่อมโยงกับความจริง
  • ผู้ใช้แจ้งว่าใช้ Bard ซึ่งเป็น generative AI ของ Google เพื่อค้นหาปัญหานี้

ตัวอย่าง B: ช่องโหว่บัฟเฟอร์โอเวอร์โฟลว์

  • เป็นกรณีที่สังเกตได้ยากกว่าและทำได้แนบเนียนกว่า แต่ก็ยังไม่พ้นจากภาพหลอน
  • เช้าวันที่ 28 ธันวาคม 2023 ผู้ใช้ได้ส่งรายงานบน Hackerone: ช่องโหว่บัฟเฟอร์โอเวอร์โฟลว์ในการจัดการ WebSocket
  • รายงานนี้เขียนอย่างละเอียด เป็นภาษาอังกฤษที่เหมาะสม และยังมีแนวทางแก้ไขที่เสนอมาให้ด้วย
  • หลังจากคำถามหลายรอบและเจอภาพหลอนหลายจุด ก็ได้ข้อสรุปในบ่ายวันเดียวกันว่าปัญหานี้ไม่ใช่ปัญหาจริง และไม่ได้ดำเนินการแก้ไข

แบนผู้รายงานเหล่านี้

  • ใน Hackerone ไม่มีฟังก์ชันที่ชัดเจนสำหรับห้ามการสื่อสารเพิ่มเติมกับโครงการ
  • เมื่อปิดปัญหาโดยไม่แก้ไข "ชื่อเสียง" ของนักวิจัยจะลดลง แต่ถ้าเกิดขึ้นเพียงครั้งเดียวในโครงการเดียว ผลกระทบก็เล็กน้อยมาก

อนาคต

  • รายงานประเภทนี้น่าจะพบได้บ่อยขึ้นเรื่อย ๆ ตามกาลเวลา และอาจเรียนรู้ที่จะตรวจจับสัญญาณของ AI ได้ดีขึ้นและเพิกเฉยต่อรายงานโดยอาศัยสิ่งนั้น
  • นั่นอาจเป็นเรื่องน่าเสียดายเมื่อ AI ถูกใช้กับงานที่เหมาะสม
  • เชื่อมั่นว่าในอนาคตจะมีเครื่องมือที่ใช้ AI และใช้งานได้จริงปรากฏขึ้น และ AI ก็ไม่จำเป็นต้องเป็นความคิดที่แย่เสมอไปสำหรับการค้นหาปัญหาความปลอดภัย
  • หากผสมการตรวจสอบโดยมนุษย์เพียงเล็กน้อย (ที่มีวิจารณญาณ) เข้าไป การใช้งานและผลลัพธ์ของเครื่องมือเหล่านี้จะดีขึ้นมาก

การสนทนา

  • Hacker news

เครดิต

  • ภาพ: Haider Mahmood by Pixabay
  • AI
  • cURL and libcurl
  • hackerone
  • Security

ความเห็นของ GN⁺

  • ความก้าวหน้าของเทคโนโลยี AI กำลังสร้างทั้งความท้าทายใหม่และโอกาสใหม่ในด้านความปลอดภัย AI อาจช่วยค้นหาช่องโหว่ด้านความปลอดภัยได้ แต่ในปัจจุบันก็มักทำให้นักพัฒนาเสียเวลาไปกับรายงานที่ไม่แม่นยำ
  • การระบุและแก้ไขปัญหาด้านความปลอดภัยอย่างรวดเร็วมีความสำคัญอย่างยิ่งต่อการรักษาความปลอดภัยของซอฟต์แวร์ อย่างไรก็ตาม เมื่อรายงานที่สร้างโดย AI เพิ่มมากขึ้น ก็จำเป็นต้องมีแนวทางใหม่ในการจัดการอย่างมีประสิทธิภาพ
  • บทความนี้นำเสนอตัวอย่างจริงของการใช้ AI ในทางที่ผิดในงานด้านความปลอดภัย จึงตอกย้ำความสำคัญของการใช้เทคโนโลยี AI อย่างมีความรับผิดชอบและการกำกับดูแลโดยมนุษย์

1 ความคิดเห็น

 
GN⁺ 2024-01-04
ความคิดเห็นจาก Hacker News
  • สรุปความคิดเห็นจาก Hacker News:
    • ความเห็นเกี่ยวกับน้ำเสียงเฉพาะของ LLM (โมเดลภาษาขนาดใหญ่):

      การที่ LLM มีน้ำเสียงบางแบบคล้ายพ่อบ้านหุ่นยนต์นั้นก็พอรับได้ แต่สิ่งที่น่ากังวลคือผู้คนเริ่มพูดเหมือน LLM

    • ความเห็นเกี่ยวกับรายงานช่องโหว่ความปลอดภัยที่เกี่ยวข้องกับ curl ซึ่งสร้างโดย LLM:

      ตอนแรกคิดว่าเป็นเนื้อหาซ้ำกับที่เคยเห็นมาก่อน แต่ภายหลังก็พบว่าแท้จริงแล้วเป็นรายงานปลอมที่สร้างโดย LLM อีกตัวหนึ่ง

    • ความกังวลเกี่ยวกับ LLM และโครงการ bug bounty:

      รายงานปลอมที่ LLM ส่งเข้าโครงการ bug bounty อาจทำให้การดำเนินโครงการเป็นไปได้ยากขึ้น อาจจำเป็นต้องเข้มงวดมากขึ้นเพื่อให้มีเพียงคนจริงและนักวิจัยด้านความปลอดภัยเท่านั้นที่เข้าร่วมได้

    • ความกังวลเรื่องต้นทุนของ LLM เทียบกับเวลาวิศวกรรมที่สูญเปล่า:

      น่ากังวลที่ LLM สามารถทำให้เวลาวิศวกรรมอันมีคุณค่าจำนวนมากสูญเปล่าได้ด้วยต้นทุนเพียงเล็กน้อย

    • ข้อสังเกตเกี่ยวกับปัญหาความน่าเชื่อถือของเนื้อหาที่เกิดจาก LLM:

      วิธีพิสูจน์ความพยายามขั้นต่ำอย่างการเขียน กลับถูก LLM เปลี่ยนให้กลายเป็นสิ่งที่ต้องใช้ความพยายามมากขึ้น เรื่องนี้ส่งผลต่อโครงการ bug bounty และกระบวนการ CVE ทำให้กำแพงในการส่งรายงานสูงขึ้น และท้ายที่สุดอาจทำให้ช่องโหว่จำนวนมากไม่ถูกค้นพบและไม่ถูกแก้ไข

    • การวิเคราะห์เชิงเทคนิคเกี่ยวกับโค้ดของ curl:

      การบ่นเรื่องการตรวจสอบความยาวนั้นดูแปลกเป็นพิเศษ เพราะ curl ไม่ได้ใช้ข้อมูลที่ผู้ใช้ส่งมา และมีขนาดที่กำหนดตายตัวตั้งแต่ตอนคอมไพล์ นอกจากนี้ยังสงสัยว่ามีใครที่คุ้นเคยกับภาษา C มากกว่านี้ช่วยอธิบายจุดประสงค์ของการใช้ตัวแปร local keyval ได้หรือไม่

    • คำวิจารณ์ต่อการรีวิวโค้ดของ LLM:

      การที่ dineshsec / dinesh_b ไปสอน Daniel เรื่องการใช้ strncpy เป็นเรื่องเสียเวลา และยังอ้างว่าการใช้ memcpy ดีกว่า strcpy หรือ strncpy ด้วย ซึ่งคำแนะนำของ LLM แบบนี้ไม่ใช่สิ่งที่แนะนำกันจริง

    • ความเห็นเกี่ยวกับปัญหา AI ในแวดวงไซเบอร์ซีเคียวริตี้:

      จนกระทั่งไม่นานมานี้ วงการไซเบอร์ซีเคียวริตี้ยังพอมีภูมิคุ้มกันต่อข้อมูลขยะอยู่บ้าง แต่ตอนนี้ AI กำลังทำให้พวกมิจฉาชีพหลอกลวงได้ง่ายขึ้น ปัญหาไม่ได้อยู่ที่ตัว AI เองเท่านั้น แต่อยู่ที่จริยธรรมด้วย และตราบใดที่รายงานความปลอดภัยดู "ถูกต้องตามแบบ" ก็อาจผ่านไปได้