พบ 0-day ระยะไกลด้วย o3 ในอิมพลีเมนต์ SMB ของ Linux

 (sean.heelan.io)
2 คะแนน โดย GN⁺ 2025-05-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในการตรวจสอบ ksmbd ซึ่งเป็นอิมพลีเมนต์ SMB3 server ของเคอร์เนล Linux พบช่องโหว่ remote use-after-free CVE-2025-37899 โดยใช้เพียง o3 API ของ OpenAI และไม่มีการใช้ agent framework หรือเครื่องมือเสริมใด ๆ
  • ช่องโหว่เกิดจากปัญหาที่ sess->user ซึ่งถูก free ไปแล้วระหว่างการจัดการคำสั่ง SMB logoff ยังอาจถูกเข้าถึงต่อโดยเธรดอื่นได้ โดยจะเห็นปัญหานี้ได้เมื่อพิจารณาทั้งการเชื่อมต่อพร้อมกันและสถานะการแชร์เซสชันร่วมกัน
  • ใน benchmark ที่ใช้ CVE-2025-37778 ซึ่งค้นพบด้วยมือเป็นเกณฑ์อ้างอิง o3 พบช่องโหว่ได้ 8 ครั้ง จาก 100 ครั้ง ส่วน Claude Sonnet 3.7 พบ 3 ครั้ง และ Claude Sonnet 3.5 พบ 0 ครั้ง
  • ภายใต้เงื่อนไข 12k LoC / 100k input tokens ที่ขยายอินพุตให้ครอบคลุม handler ของคำสั่ง SMB ทั้งหมดและโค้ดจัดการการเชื่อมต่อ อัตราการพบช่องโหว่เดิมลดลงเหลือ 1 ครั้งจาก 100 แต่ในผลลัพธ์ชุดเดียวกันกลับพบช่องโหว่ใหม่ CVE-2025-37899
  • แม้ยังมี false positive และผลลัพธ์ที่ไร้สาระอยู่มาก แต่ความน่าจะเป็นที่จะได้ คำตอบที่ถูกต้อง สูงขึ้นจนคุ้มให้มนุษย์นำไปตรวจทานและยืนยันต่อในงานวิจัยช่องโหว่จริง

การทดลองหาช่องโหว่ ksmbd ด้วย o3

  • เป้าหมายของการตรวจสอบคือ ksmbd ซึ่งเป็นอิมพลีเมนต์การแชร์ไฟล์ผ่านโปรโตคอล SMB3 ใน kernel space ของ Linux
  • มีการเรียกใช้ โมเดล o3 ผ่าน o3 API โดยไม่มี scaffolding, agent framework หรือเครื่องมือเสริมอื่น
  • ช่องโหว่ที่พบคือ CVE-2025-37899 และแพตช์แก้ไขอยู่ใน Linux kernel commit
  • ปัญหาหลักคือ use-after-free ใน handler ของคำสั่ง SMB logoff โดยมีโครงสร้างที่ object ซึ่งไม่มี reference count ถูก free ในขณะที่ยังเข้าถึงได้จากเธรดอื่น
  • การหาช่องโหว่นี้จำเป็นต้องเข้าใจทั้งการเชื่อมต่อพร้อมกันไปยังเซิร์ฟเวอร์และ object ที่ถูกแชร์กันในบางสถานการณ์
  • มีการประเมินว่านี่น่าจะเป็นกรณีแรกที่มีการพูดถึงต่อสาธารณะซึ่ง LLM สามารถหาช่องโหว่ลักษณะนี้ได้

ช่องโหว่อ้างอิง CVE-2025-37778

  • เริ่มจากใช้ CVE-2025-37778 ซึ่งค้นพบด้วยมือ เป็น benchmark สำหรับประเมินประสิทธิภาพของ o3
  • ช่องโหว่นี้เป็น use-after-free ที่เกิดขึ้นระหว่างจัดการคำขอ session setup ของ remote client ในเส้นทางการยืนยันตัวตนด้วย Kerberos
  • krb5_authenticate จะ free sess->user หาก sess->state == SMB2_SESSION_VALID
  • จากนั้นโค้ดจะอาศัยสมมติฐานว่า ksmbd_krb5_authenticate จะ initialize ค่านี้ใหม่ให้ถูกต้อง หรือหากคืนค่า -EINVAL แล้วก็จะไม่มีการใช้งาน sess->user
  • แต่ในความเป็นจริงสามารถทำให้ ksmbd_krb5_authenticate ไม่ initialize sess->user ใหม่ได้ และแม้ krb5_authenticate จะคืน -EINVAL ก็ยังอาจมีการเข้าถึง sess->user

การจัด benchmark และพรอมป์ต์

  • CVE-2025-37778 ถูกใช้เป็น benchmark เพราะอยู่บน remote attack surface และต้องตัดสินใจครบทั้งเงื่อนไข sess->state == SMB2_SESSION_VALID, เส้นทางที่ไม่ถูก initialize ใหม่ และเส้นทางการเข้าถึงหลัง free
  • โค้ดขั้นต่ำที่จำเป็นต่อการอธิบายเส้นทางช่องโหว่คำนวณได้ราว 3.3k LoC
  • อินพุตการทดลองรวม handler ของคำสั่ง session setup และฟังก์ชันที่ handler นี้เรียกใช้ลึกถึง call depth 3
  • ยังใส่โค้ดรับแพ็กเก็ต การ parse คำขอ การเลือก command handler และโค้ด cleanup การเชื่อมต่อหลัง handler ทำงานเสร็จ เพื่อลดการคาดเดาเรื่องการ initialize โครงสร้างข้อมูล
  • อินพุตสุดท้ายมีขนาดประมาณ 3.3k LoC / 27k tokens และไฟล์โค้ดที่ใช้วิเคราะห์เปิดเผยไว้ที่ session_setup_code.prompt
  • พรอมป์ต์มีเงื่อนไขดังนี้
    • สั่งให้ค้นหาช่องโหว่ use-after-free
    • ให้ข้อมูลระดับสูงเกี่ยวกับบทบาท สถาปัตยกรรม และ threat model ของ ksmbd
    • ชี้นำอย่างชัดเจนให้ยอมพลาดการรายงานดีกว่ารายงาน false positive
  • ไฟล์พรอมป์ต์ทั้งหมดอยู่ใน repo o3_finds_cve-2025-37899
  • การรันใช้เครื่องมือ llm ของ Simon Willison

ผล benchmark ของ CVE-2025-37778

  • ชุดทดสอบรันคำถามเดียวกัน 100 ครั้ง และเก็บผลลัพธ์ทั้งหมด
  • o3 พบ CVE-2025-37778 ได้ 8 ครั้ง จาก 100 ครั้ง
  • ใน 66 ครั้ง จาก 100 ครั้ง โมเดลตัดสินว่าไม่มีบั๊ก ทำให้เป็น false negative
  • ที่เหลืออีก 28 ครั้ง เป็น false positive
  • ผลเปรียบเทียบมีดังนี้
    • Claude Sonnet 3.7: พบ 3 ครั้ง จาก 100 ครั้ง
    • Claude Sonnet 3.5: พบ 0 ครั้ง จาก 100 ครั้ง
  • ใน benchmark นี้ o3 ให้ผลดีขึ้นจาก Claude Sonnet 3.7 ราว 2~3 เท่า
  • ตัวอย่างรายงานเปิดเผยไว้ที่ ผลลัพธ์ o3 และ ผลลัพธ์ Sonnet 3.7
  • เอาต์พุตของ o3 อ่านคล้ายรายงานบั๊กฉบับย่อที่มนุษย์เขียน เพราะมีโครงสร้างและโฟกัสชัดเจน แต่บางครั้งสั้นเกินไปจนความชัดเจนลดลง
  • เอาต์พุตของ Sonnet 3.7 ออกมาในลักษณะที่ใกล้กับลำดับความคิดหรือบันทึกการทำงานมากกว่า

การทดลองที่ขยายไปยัง handler ของทุกคำสั่ง

  • ในการทดลองถัดไป มีการป้อนให้ o3 ไม่ใช่แค่ handler ของ session setup แต่รวมโค้ดของ handler คำสั่ง SMB ทั้งหมด
  • command handler เหล่านี้อยู่ใน smb2pdu.c ซึ่งมีขนาดประมาณ 9k LoC
  • เมื่อนำ handler ทั้งหมด โค้ดตั้งค่าและ cleanup การเชื่อมต่อ และ dispatch routine ของ command handler มารวมกัน จะได้ประมาณ 12k LoC / 100k input tokens
  • ภายใต้เงื่อนไขนี้ก็ยังรันทดลอง 100 ครั้ง
  • o3 พบช่องโหว่ Kerberos เดิม CVE-2025-37778 ได้เพียง 1 ครั้ง จาก 100 ครั้ง แสดงให้เห็นการลดลงของประสิทธิภาพอย่างชัดเจนเมื่อจำนวน input tokens เพิ่มขึ้น
  • แต่ในผลลัพธ์ชุดเดียวกันกลับพบรายงานของช่องโหว่ใหม่ที่ไม่เคยทราบมาก่อนคือ CVE-2025-37899

เส้นทางช่องโหว่ของ CVE-2025-37899

  • ช่องโหว่ใหม่ก็เกี่ยวข้องกับการ free sess->user เช่นกัน แต่ครั้งนี้เกิดใน session logoff handler
  • smb2_session_logoff ทำงานตามลำดับดังนี้
    • เรียก ksmbd_close_session_fds(work)
    • เรียก ksmbd_conn_wait_idle(conn)
    • ตั้งสถานะเซสชันเป็น SMB2_SESSION_EXPIRED
    • หากมี sess->user ให้ free ด้วย ksmbd_free_user(sess->user) แล้วตั้ง sess->user = NULL
  • สถานการณ์ช่องโหว่ในรายงานของ o3 เป็นดังนี้
    • บน SMB 3.0 ขึ้นไป การส่งข้อมูลครั้งที่สองถูก bind เข้ากับเซสชันเดิมและทำให้ conn->binding == true
    • Worker-A ประมวลผลคำขอทั่วไปอย่าง WRITE บนการเชื่อมต่ออีกเส้น C2
    • smb2_check_user_session() เก็บ pointer ของ struct ksmbd_session เดิมไว้ใน work->sess และเพิ่ม session reference count แต่ไม่ได้ถือ reference แยกให้ sess->user
    • Worker-B ประมวลผล SMB2 LOGOFF สำหรับเซสชันเดียวกันบนการเชื่อมต่อแรก C1 และรัน smb2_session_logoff()
    • ksmbd_conn_wait_idle(conn) รอเฉพาะคำขอที่กำลังรันอยู่บนการเชื่อมต่อนั้น ไม่ได้รอคำขอจากการเชื่อมต่ออื่นที่ใช้เซสชันเดียวกัน
    • Worker-A จึงยังทำงานต่อและอาจเข้าถึง user_guest(sess->user), ksmbd_compare_user(sess->user, …), sess->user->uid ได้
  • แล้วแต่จังหวะเวลา อาจกลายเป็น use-after-free ที่ชี้ไปยัง slab object ที่ถูก free แล้ว หรือถ้าอ่านหลัง sess->user = NULL ก็อาจกลายเป็น NULL dereference จนเกิด DoS ได้

แพตช์แก้ไขที่ผิดพลาดและคุณค่าของผลลัพธ์จาก o3

  • สำหรับ CVE-2025-37778 แพตช์แรกที่เสนอคือเพิ่ม sess->user = NULL ต่อจาก ksmbd_free_user(sess->user)
  • หลังอ่านรายงาน CVE-2025-37899 จึงเห็นได้ชัดว่าแพตช์นี้ยังไม่เพียงพอ
  • handler ของ logoff มีการทำ sess->user = NULL อยู่แล้ว แต่ยังคงมีช่องโหว่ เพราะโปรโตคอล SMB อนุญาตให้ bind การเชื่อมต่อสองเส้นที่ต่างกันเข้ากับเซสชันเดียวกันได้
  • แม้ในเส้นทาง Kerberos authentication ก็ยังมีช่วงสั้น ๆ หลัง free sess->user และก่อนตั้งเป็น NULL ที่เธรดอื่นสามารถเข้าถึงได้
  • รายงานบางส่วนของ o3 ก็พลาดแบบเดียวกัน แต่บางส่วนสามารถจับประเด็นได้ว่าเพียง sess->user = NULL ยังไม่พอ เพราะมีความเป็นไปได้ของการ bind เซสชัน
  • ข้อจำกัดคือสัดส่วน true positive เทียบกับ false positive ยังสูงไม่มาก จึงไม่แน่ชัดว่าจะมีการตรวจรายงานทุกฉบับอย่างละเอียดเพียงพอหรือไม่

ตำแหน่งเชิงปฏิบัติในงานวิจัยช่องโหว่

  • ในด้านความคิดสร้างสรรค์ ความยืดหยุ่น และความเป็น general-purpose นั้น LLM อยู่ใกล้กับนักตรวจสอบโค้ดที่เป็นมนุษย์มากกว่าวิธีวิเคราะห์โปรแกรมแบบเดิม
  • มีการยก symbolic execution, abstract interpretation และ fuzzing ขึ้นมาเป็นตัวเปรียบเทียบ
  • แม้หลัง GPT-4 จะมีความเป็นไปได้ที่ LLM จะใช้ในงานวิจัยช่องโหว่ได้ แต่กับปัญหาจริงผลลัพธ์ก่อนหน้านี้ยังไม่ดีเท่าที่คาด
  • o3 แสดงให้เห็นว่าความสามารถด้านการให้เหตุผลกับโค้ด การถามตอบ การเขียนโปรแกรม และการแก้ปัญหา สามารถยกระดับประสิทธิภาพของนักวิจัยช่องโหว่จริงได้
  • อย่างไรก็ตาม มันยังไม่สมบูรณ์และยังมีโอกาสสร้างผลลัพธ์ที่ไร้ความหมายจนทำให้ผู้ใช้หงุดหงิดได้มาก
  • สิ่งที่เปลี่ยนไปคือเป็นครั้งแรกที่มีการประเมินว่า ความน่าจะเป็นที่จะได้คำตอบที่ถูกต้อง สูงพอจะคุ้มค่ากับการนำไปใช้กับปัญหาจริง

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2025-05-25
ความคิดเห็นบน Hacker News

  • เป็นรายละเอียดเล็ก ๆ แต่ดูเหมือนว่า วิธีจัดโครงสร้างโปรเจกต์ ของผู้เขียนจะมีประโยชน์ เขาแยก system prompt, ข้อมูลพื้นหลัง และคำสั่งเสริมเป็นไฟล์ .prompt แต่ละไฟล์ [1] แล้วรันด้วย llm
    แสดงให้เห็นว่าการใช้ LLM ให้ดี ก็เหมือนเครื่องมือวิศวกรรมอื่น ๆ ที่ต้องอาศัย วิธีคิดเชิงวิศวกรรม ที่เป็นระบบ ยึดสเปกอย่างรอบคอบ และคำนึงถึงข้อจำกัดในการออกแบบอย่างสมดุล
    [1] https://github.com/SeanHeelan/o3_finds_cve-2025-37899

    • ที่ตีความแบบนั้นก็น่าสนใจ เพราะผู้เขียนเองก็ยอมรับว่าตรงส่วนนั้นเขาทำไปตามความรู้สึกล้วน ๆ

      In fact my entire system prompt is speculative so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering

    • ผมไม่รู้ว่าควร benchmark วิธีการต่าง ๆ แบบนี้อย่างไร
      ทั้งหมดดูเหมือนคาถาที่อาศัยสัญชาตญาณ เช่นประโยคอย่าง “คุณเป็นผู้เชี่ยวชาญด้านการค้นหาช่องโหว่”, “ให้รายงานเฉพาะช่องโหว่จริงโดยไม่มี false positive” หรือวิธีจัดระเบียบด้วยแท็ก HTML ปลอม ๆ เพราะโมเดลดูเหมือนจะชอบแบบนั้น ผมไม่เห็นว่าตรงไหนคือวิศวกรรม
    • น่าสนใจที่เห็นความพยายามเอา หลักการวิศวกรรม ไปใช้กับระบบที่โดยแก่นแล้วไม่เสถียรและคาดเดาไม่ได้ เพื่อให้รู้สึกว่าควบคุมได้
      prompt แบบนั้นควรเรียกว่าคำใบ้ ไม่ใช่คำสั่ง LLM ทุกตัวในปัจจุบันจะเพิกเฉยต่อ prompt ถ้ามันขัดกับเป้าหมายสูงสุดเพียงหนึ่งเดียวของตัวเอง นั่นคือการให้คำตอบออกมา ไม่ว่าจะจริงหรือไม่ก็ตาม
    • เรื่องที่น่าสนใจคือ ถ้าถาม LLM ถึง แนวปฏิบัติที่ดีในการจัดโครงสร้าง prompt มันก็จะให้คำแนะนำไปในทิศทางแบบนี้
      การให้ LLM ช่วยเขียน prompt ก็ได้ผลดีอย่างน่าประหลาดใจ ชิ้นส่วน prompt ของผมทั้งหมดก็ออกแบบโดยมี LLM ช่วย
      ส่วนตัวผมเก็บทั้งหมดไว้ในไฟล์ org-mode แล้วคัดลอกไปวางในบทสนทนา ChatGPT เมื่อต้องใช้ ผมชอบการโต้ตอบแบบ “ถกกัน” มากกว่า แต่แนวทางก็เหมือนกัน
    • สุดท้ายแก่นสำคัญคือการจัดระเบียบ: https://taoofmac.com/space/blog/2025/05/13/2230

  • ในบทความบอกว่า อัตราส่วนสัญญาณต่อสัญญาณรบกวน อยู่ราว ๆ 1:50 ผู้เขียนรู้จัก codebase นี้ดีมาก จึงอยู่ในตำแหน่งที่เหมาะจะคัดแยกสัญญาณออกจากเสียงรบกวน
    ผลลัพธ์จริง ๆ น่าจะมาจากการทำส่วนนี้ให้เป็นอัตโนมัติ เลยตั้งใจว่าจะติดตามต่อไป

    • ช่วงหลายปีที่ผ่านมา ผมทำโจทย์สัมภาษณ์แบบ take-home ไว้หลายข้อ โดยออกแบบให้สั้นและง่ายสำหรับนักพัฒนาที่มีประสบการณ์ แต่ยากถ้าไม่รู้ภาษา ทั้งหมดเป็นปัญหาจริงจากงานที่ผมเคยแก้ แล้วลดรูปให้เล็กที่สุด
      ทุกครั้งที่มี LLM ระดับแนวหน้าตัวใหม่ออกมา ผมจะลองรันโจทย์สัมภาษณ์เหล่านั้น โดยไม่นับโมเดลที่ใช้อินพุตไปเป็นข้อมูลฝึก ผมแปลกใจที่สัดส่วนคำตอบที่ทำงานได้ตั้งแต่ครั้งแรกยังคงอยู่แถว ๆ 1:10 อย่างสม่ำเสมอ และหลายครั้งต้องจี้ให้มันหาข้อผิดพลาดของตัวเองเกิน 10 รอบ
      ดังนั้นอัตราส่วนสัญญาณต่อสัญญาณรบกวนระดับนี้ในหัวข้อที่ยากกว่าย่อมพอเข้าใจได้
    • ผมกำลังสร้างระบบที่เพิ่ม อัตราส่วนสัญญาณต่อสัญญาณรบกวน ในการตรวจจับบั๊กได้อย่างมาก และในขณะเดียวกันก็ benchmark software agent ชื่อดังหลายตัวอย่างละเอียดมาโดยตลอด
      ผลลัพธ์มีช่วงกว้างพอสมควร และจะเปิดเผยทั้งหมดในการบรรยายที่งานประชุมเร็ว ๆ นี้ รอติดตามได้เลย น่าจะสะท้อนสถานะปัจจุบันของวงการนี้ได้ค่อนข้างดี
      แก้ไข: ข้อความเดิมทำให้สับสน
    • เมื่อไม่นานมานี้ผมคิดว่า อาจเป็นไปได้ไหมที่จะทำอะไรคล้าย fine-tuning กับการเปลี่ยนแปลง git ทั้งหมดของ Linux kernel, mailing list และอื่น ๆ
      LLM แบบนั้นอาจกลายเป็นเวอร์ชันสังเคราะห์ที่คล้ายคนซึ่งทำงานกับ codebase มาหลายปีและซึมซับลักษณะเฉพาะสารพัดอย่าง
      แม้ context ที่ยาวจะใส่อะไรได้เยอะมาก แต่บาง codebase แค่โค้ดอย่างเดียวก็ 200,000 token แล้ว ผมเลยไม่แน่ใจ
    • การทำส่วนนี้ให้เป็นอัตโนมัติน่าจะง่าย โดยทั่วไป LLM ที่มีความสามารถเชิงความหมาย X ในการทำงานบางอย่าง มักมีความสามารถในการตรวจว่าคำตอบไหนดีที่สุดจากคำตอบ N ข้อสำหรับงานเดียวกัน สูงกว่า X
      โดยเฉพาะถ้าใช้วิธี ทัวร์นาเมนต์แบบไบนารี เหมือน RAInk ที่เคยขึ้นที่นี่เมื่อไม่กี่สัปดาห์ก่อน และยังมีวิธีใช้ฉันทามติระหว่าง LLM ต่างรุ่นด้วย น่าแปลกที่ตรงนี้ไม่ได้ใช้ Gemini 2.5 PRO เพราะจากประสบการณ์ของผม มันเป็น LLM ที่แข็งแกร่งที่สุดสำหรับงานประเภทนี้
    • 1:50 ถือเป็น อัตราการตรวจพบ ที่ยอดเยี่ยมสำหรับการงมเข็มในมหาสมุทร

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

    • เพิ่งนึกได้ว่าไม่ได้เขียนไว้ในบทความ ถ้าอยากรู้ การรันเวอร์ชัน 100,000 token จำนวน 100 ครั้งมีค่าใช้จ่ายประมาณ 116 ดอลลาร์
    • zero-day สามารถขายได้เป็นเงินก้อนใหญ่ และถ้าไปทาง bug bounty ก็ทำเงินได้เช่นกัน ค่าใช้จ่ายของ LLM เมื่อเทียบกันแล้วคงเหมือนหยดน้ำในถัง
      ผมไม่รู้ว่าโลก cybersecurity จะเป็นอย่างไรเมื่อ ต้นทุน inference เข้าใกล้ศูนย์ แต่มันจะเป็นพื้นที่ที่ต่างจากทุกวันนี้มาก
    • แค่มีเงินมากพอก็พอแล้ว~
    • “100 ครั้งต่อโมเดล” หมายถึง การใช้พลังงาน จำนวนมาก ความสำเร็จที่พบช่องโหว่ซึ่งพบบ่อยที่สุดใน codebase ที่เขียนด้วย C จึงดูไม่น่าทึ่งเท่าไร
      กลับดูเหมือนการเฉลิมฉลองความฟุ่มเฟือยและสิ้นเปลืองมากกว่า ทั้งที่เรากำลังเผชิญการเปลี่ยนแปลงสภาพภูมิอากาศระดับโลก แต่ก็ยังเผาทรัพยากรกับเรื่องเล็กน้อยเหมือนยุค 1950

  • อาจจะโชคดีมาก หรืออย่างที่เดาไว้ Gemini 2.5 PRO ดูเหมือนจะค้นพบช่องโหว่นี้ได้ง่ายกว่า อัตราสำเร็จสูงจนแค่รัน prompt ต่อไปนี้ไม่กี่ครั้งก็พอแล้ว: https://gist.github.com/antirez/8b76cd9abf29f1902d46b2aed3cd...

  • ช่วงหลัง ๆ รูปแบบแบบนี้เกิดซ้ำอยู่เรื่อย ๆ
    ถ้ามีปัญหาที่มีนิยามชัดเจนและมีฟังก์ชันประเมินผล ก็ให้ LLM ช่วยลดพื้นที่ของคำตอบลง LLM แข็งแกร่งมากในการประกอบรูปแบบขึ้นมาใหม่ และถ้าคำตอบมีรูปแบบคล้ายกับสิ่งที่รู้กันอยู่แล้ว ก็อาจทำงานได้ดี
    ในกรณีนี้ ปัญหาคือช่องโหว่ด้านความปลอดภัยประเภทหนึ่ง และผู้ประเมินคือผู้เชี่ยวชาญ แม้ขนาดจะแตกต่างกัน แต่ในเชิงแนวคิดก็คล้ายกับความพยายามช่วงหลัง ๆ ที่ใช้ LLM กับ genetic optimization
    “Mathematical discoveries from program search with large language models” ก็เป็นบทความที่น่าสนใจ และจำได้ว่าเคยขึ้น HN มาก่อน
    https://www.nature.com/articles/s41586-023-06924-6
    อย่างไรก็ตาม โดยส่วนตัวคิดว่าการสรุปจากการทดลองนี้เพียงอย่างเดียวว่า LLM ให้เหตุผลเกี่ยวกับโค้ดได้นั้นค่อนข้างเกินไปหน่อย

  • หวังว่านี่จะเป็นเรื่องจริง และไม่ใช่แบบเดียวกับสิ่งที่เกิดขึ้นซ้ำ ๆ กับ curl
    [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

  • ไม่ค่อยมั่นใจนักกับคำกล่าวอ้างว่านี่เป็นช่องโหว่แรกที่ค้นพบด้วย LLM ตัวอย่างเช่น OSS-Fuzz [0] เคยพบอยู่หลายรายการด้วย fuzzing และ Big Sleep ก็พบด้วยแนวทางแบบเอเจนต์ [1]
    [0] https://security.googleblog.com/2024/11/leveling-up-fuzzing-...
    [1] https://googleprojectzero.blogspot.com/2024/10/from-naptime-...

    • แน่นอนว่าไม่ใช่ช่องโหว่แรกที่พบด้วย LLM =) อาจจะควรเขียนให้ชัดเจนกว่านี้
      สิ่งที่บทความพูดคือ “การจะเข้าใจช่องโหว่นี้ ต้องให้เหตุผลเกี่ยวกับการเชื่อมต่อพร้อมกันหลายรายการไปยังเซิร์ฟเวอร์ และวัตถุหลายตัวถูกแชร์กันอย่างไรในสถานการณ์เฉพาะ o3 เข้าใจเรื่องนี้ และพบจุดที่วัตถุเฉพาะที่ไม่ได้ถูกทำ reference count ถูก free ทั้งที่ยังเข้าถึงได้จากเธรดอื่น เท่าที่ผมทราบ นี่เป็นการอภิปรายสาธารณะครั้งแรกเกี่ยวกับการที่ LLM พบช่องโหว่ลักษณะนี้”
      สิ่งที่อยากบอกคือ เท่าที่ผมทราบ นี่เป็นเอกสารสาธารณะครั้งแรกที่ LLM พบ bug ประเภทนั้น คือ bug ที่เกิดจากโค้ดจำนวนไม่น้อยและ การเข้าถึงทรัพยากรที่ใช้ร่วมกันพร้อมกัน อย่างน้อยสำหรับผม มันเป็นสัญญาณที่น่าสนใจของความก้าวหน้าของ LLM

  • ถ้าคิดถึงมูลค่าของการค้นพบ zero-day แล้ว หากสามารถค้นหาได้อย่างเสถียรด้วยการเรียก API เพียงไม่กี่ร้อยครั้ง หน่วยข่าวกรองแทบทุกแห่งทั่วโลกก็คงทุ่มเงินใส่เรื่องนี้
    โดยเฉพาะอย่างยิ่งถ้าสามารถ fine-tune โมเดลด้วยตัวอย่างจำนวนมากได้ และที่อย่าง OpenAI ก็คงไม่น่าจะทำสิ่งนั้นผ่าน API สาธารณะ

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

  • เข้าใจว่ามีนักพัฒนาเคอร์เนลหลายคน “ตรวจสอบยืนยัน” bug นี้แล้ว แต่สงสัยว่ามีใครสร้างและทดสอบ proof of concept จริง ๆ หรือไม่
    นี่เป็นส่วนสำคัญมากของกระบวนการ แต่ proof of concept กลับหายไปโดยสิ้นเชิง ถ้าไม่มี proof of concept ก็ไม่รู้ได้ว่าจะมีปัญหาอะไรเกิดขึ้นระหว่างทาง และจึงไม่สามารถตัดสินความเป็นไปได้ในการ exploit หรือผลกระทบได้ อย่างน้อยผู้เขียนก็ไม่ได้เรียกมันว่า remote code execution โดยไม่มีการตรวจสอบยืนยัน
    แต่ถ้ามีชิ้นส่วนปริศนาบางอย่างที่ผู้เขียนกับนักพัฒนาพลาดไป หรือสมมติว่า o3 จัดการแล้ว แต่จริง ๆ แล้วอยู่นอกบริบทของ o3 และมันทำให้ช่องโหว่นี้ไม่ถูกต้องขึ้นมาล่ะ?
    ไม่ได้บอกว่ามีสิ่งนั้นอยู่ และก็ไม่ได้จะใช้เวลาไปทำงานแทนผู้เขียน เพียงแต่รายงานนี้ยังไม่ได้รับการตรวจสอบยืนยันอย่างครบถ้วน และเมื่อคิดว่ามันอาจกลายเป็นบล็อกโพสต์ที่มีอิทธิพลต่อวงการวิจัยช่องโหว่ด้วย LLM ในอนาคต ก็รู้สึกว่าเป็นตัวอย่างที่อันตราย
    โดยส่วนตัวแล้วคิดว่าควรใช้หลัก PoC || GTFO กับรายงานช่องโหว่ใด ๆ ที่โมเดลสร้างขึ้นให้เข้มงวดยิ่งกว่าที่เคย
    มุมมองที่ว่า o3 ดีกว่าโมเดลก่อนหน้า หรือโมเดลปัจจุบันอื่น ๆ มากยังคงอยู่ และวิธีการก็น่าสนใจ เข้าใจแรงจูงใจและความจำเป็นที่อยากใช้ถ้อยคำแบบนั้นเพื่อให้ผู้คนสนใจบางประเด็น นี่คือปัญหาของ clickbait แต่ขอเถอะ ควรทำให้ดีกว่านี้ ต้องสร้าง proof of concept และตรวจสอบคำกล่าวอ้าง ไม่ควรขี้เกียจ ถ้าจะเขียนบล็อกโพสต์ที่อาจมีอิทธิพลต่อวิธีทำงานวิจัยของนักวิจัยช่องโหว่ ก็ควรส่งเสริมการตรวจสอบยืนยัน ไม่ใช่การตั้งสมมติฐานเชิงทฤษฎี ไม่เช่นนั้น รายงานที่เป็นเท็จแต่ดูน่าเชื่อถือจะยิ่งแพร่กระจายความไม่รู้ แทนที่จะทำให้ความเข้าใจระบบลึกขึ้นด้วยรายงานที่ตรวจสอบและพิสูจน์ได้

    • ผู้เขียนเองครับ ใช่ ผมสร้าง proof of concept แล้ว ใช่ มันทำให้เกิดรายงาน KASAN และ crash
    • อยากถามว่าต้องการ proof of concept ที่ทำให้ crash ด้วย use-after-free หรือจะพอใจก็ต่อเมื่อเป็น proof of concept สำหรับ remote code execution แบบสมบูรณ์เท่านั้น

  • มีข้อความสั้น ๆ ที่งดงามซึ่งจับภาพได้อย่างสมบูรณ์แบบว่า เซสชันการพัฒนาพรอมป์ ส่วนใหญ่ของผมดำเนินไปอย่างไร

    I tried to strongly guide it to not report false positives, and to favour not reporting any bugs over reporting false positives. I have no idea if this helps, but I’d like it to help, so here we are. In fact my entire system prompt is speculative in that I haven’t ran a sufficient number of evaluations to determine if it helps or hinders, so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering. Once I have ran those evaluations I’ll let you know.