Claude Code ค้นพบช่องโหว่ Linux ที่ซ่อนอยู่มานาน 23 ปี

 (mtlynch.io)
9 คะแนน โดย GN⁺ 26 일 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Claude Code ของ Anthropic ตรวจพบ ช่องโหว่ในเคอร์เนล Linux ที่สามารถถูกโจมตีจากระยะไกลได้ โดยอัตโนมัติ และค้นพบ ช่องโหว่ heap buffer overflow ในไดรเวอร์ NFS ที่ไม่เคยถูกพบมานาน 23 ปี
  • เพียงใช้พรอมป์ตว่า “ช่องโหว่ด้านความปลอดภัยอยู่ที่ไหน?” ก็สามารถวิเคราะห์เคอร์เนลทั้งชุดและระบุช่องโหว่ได้ แทบไม่ต้องมีการกำกับดูแล
  • บั๊กนี้มีต้นตอมาจาก การออกแบบบัฟเฟอร์คงที่ขนาด 112 ไบต์ในโค้ดเคอร์เนลปี 2003 และภายหลังเมื่อมีการเพิ่มคำสั่ง LOCK ก็เกิดปัญหาเพราะ ไม่มีการจำกัดความยาว owner ID
  • นอกจากนั้น Carlini ยังพบ ช่องโหว่ที่อาจมีอยู่ในเคอร์เนลอีกหลายร้อยรายการ แต่ส่วนใหญ่ยังไม่ได้รายงาน เนื่องจากติดคอขวดที่กระบวนการตรวจสอบโดยมนุษย์
  • โมเดล Claude Opus 4.6 รุ่นล่าสุด แสดงความสามารถในการตรวจจับที่สูงกว่ารุ่นก่อนอย่างมาก จนถูกมองว่าเป็น จุดเปลี่ยนของงานวิจัยด้านความปลอดภัยที่ขับเคลื่อนด้วย AI

Claude Code ค้นพบช่องโหว่ Linux ที่ซ่อนอยู่มานาน 23 ปี

  • Nicholas Carlini นักวิจัยของ Anthropic ใช้ Claude Code เพื่อค้นพบ ช่องโหว่หลายรายการในเคอร์เนล Linux ที่สามารถถูกโจมตีจากระยะไกลได้
    • หนึ่งในนั้นคือ ช่องโหว่ buffer overflow ในไดรเวอร์ NFS (Network File System) ที่ไม่เคยถูกพบมานาน 23 ปี
    • Carlini ระบุว่าเขา “ไม่เคยค้นหาช่องโหว่ประเภทนี้ได้ด้วยตัวเองมาก่อน” และแสดงความประหลาดใจกับประสิทธิภาพของ Claude Code

  • วิธีที่ Claude Code ตรวจจับช่องโหว่

    • Claude Code ตรวจจับช่องโหว่ด้านความปลอดภัยในเคอร์เนล Linux ได้โดย แทบไม่ต้องมีการกำกับดูแล
      • Carlini เพียงให้พรอมป์ตว่า “ช่องโหว่ด้านความปลอดภัยอยู่ที่ไหน?” และตั้งค่าให้มันไล่ตรวจไฟล์ซอร์สของเคอร์เนลทั้งหมด
    • สคริปต์ที่ใช้ถูกตั้งค่าให้ Claude Code วิเคราะห์แต่ละไฟล์โดย สมมติสถานการณ์แบบ CTF (การแข่งขันแฮ็กกิง) และบันทึกช่องโหว่ที่ร้ายแรงที่สุดลงใน /out/report.txt
      • ใช้คำสั่ง find เพื่อค้นหาไฟล์ทั้งหมด แล้วรัน Claude Code ซ้ำสำหรับแต่ละไฟล์เพื่อค้นหาช่องโหว่
    • ระบบถูกออกแบบมาเพื่อไม่ให้มีการรายงานช่องโหว่เดิมซ้ำ ทำให้สามารถวิเคราะห์ไฟล์ทุกไฟล์ในเคอร์เนลแยกกันได้

  • ช่องโหว่ NFS (Network File System)

    • ช่องโหว่สำคัญที่ Claude Code ค้นพบคือ heap buffer overflow ในไดรเวอร์ Linux NFS ซึ่งทำให้ผู้โจมตีสามารถ อ่านหน่วยความจำของเคอร์เนลผ่านเครือข่ายได้
    • สถานการณ์การโจมตีอาศัย NFS client สองตัวที่ทำงานร่วมกัน (Client A, Client B) ต่อ NFS server เดียวกัน
      • Client A ขอ file lock โดยใช้ owner ID ที่ยาว 1024 ไบต์และได้รับการอนุมัติ
      • จากนั้นเมื่อ Client B ขอ lock สำหรับไฟล์เดียวกัน เซิร์ฟเวอร์จะปฏิเสธและสร้างข้อความตอบกลับ
    • ปัญหาคือ บัฟเฟอร์ของข้อความปฏิเสธนี้มีขนาดเพียง 112 ไบต์ แต่ข้อความจริงเมื่อรวม owner ID แล้วมีขนาด รวม 1056 ไบต์
      • ผลลัพธ์คือเคอร์เนลเขียนข้อมูล 1056 ไบต์ลงในบัฟเฟอร์ขนาด 112 ไบต์ ทำให้ ข้อมูลที่ผู้โจมตีควบคุมได้เขียนทับหน่วยความจำของเคอร์เนล
    • ตอนที่ Claude Code รายงานช่องโหว่นี้ มันยังสร้าง ASCII protocol diagram ใส่มาให้อัตโนมัติด้วย

  • เหตุผลที่ไม่ถูกค้นพบมานาน 23 ปี

    • บั๊กนี้มีต้นตอจาก โค้ดที่ถูกนำเข้า Linux kernel ในเดือนมีนาคม 2003
      • ใน commit message ขณะนั้นระบุว่า บัฟเฟอร์คงที่ 112 ไบต์ ชื่อ NFSD4_REPLAY_ISIZE เพียงพอสำหรับการทำงาน NFSv4 เช่น OPEN, CLOSE เป็นต้น
      • ต่อมาเมื่อมีการเพิ่มคำสั่ง LOCK ก็เกิดช่องโหว่ขึ้นเพราะ ไม่ได้คำนึงถึงการจำกัดความยาว owner ID
    • โค้ดส่วนนี้เป็น การเปลี่ยนแปลงก่อนมีการนำ Git มาใช้ (2005) และเก่ามากจนปัจจุบันไม่สามารถลิงก์ตรงไปยังต้นทางได้แล้ว

  • ช่องโหว่เพิ่มเติมอีกหลายร้อยรายการที่ยังไม่ได้ถูกรายงาน

    • Carlini ค้นพบ ช่องโหว่ที่อาจมีอยู่ในเคอร์เนล Linux อีกหลายร้อยรายการ เพิ่มเติม แต่ ส่วนใหญ่ยังไม่ได้รายงาน เพราะติดคอขวดที่ กระบวนการตรวจสอบโดยมนุษย์
      • เขาระบุว่า “เราไม่สามารถส่งผลลัพธ์ที่ยังไม่ผ่านการตรวจสอบไปให้ kernel maintainer ได้ ดังนั้นจึงยังมี crash อีกหลายร้อยกรณีที่ยังไม่ได้ยืนยัน”
    • จนถึงตอนนี้ ช่องโหว่ที่ Carlini แก้ไขหรือรายงานด้วยตัวเองได้รับการยืนยันแล้ว 5 รายการ
      • 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()

  • ความก้าวหน้าของการตรวจจับช่องโหว่ด้วย AI

    • Carlini ใช้ Claude Opus 4.6 (ก่อนเปิดตัว 2 เดือน) เพื่อค้นพบช่องโหว่นี้
      • ในรุ่นก่อนหน้าอย่าง Opus 4.1 (8 เดือนก่อน) และ Sonnet 4.5 (6 เดือนก่อน) ไม่สามารถทำซ้ำผลลัพธ์เดียวกันได้
      • โมเดลล่าสุดสามารถตรวจจับช่องโหว่ได้มากกว่ามาก
    • เขาคาดการณ์ว่า “ภายในไม่กี่เดือนข้างหน้า ทั้งนักวิจัยและผู้โจมตีจะตระหนักถึงพลังของโมเดล AI เหล่านี้ และจะเกิด คลื่นการค้นพบช่องโหว่ด้านความปลอดภัยครั้งใหญ่”

  • การประกาศและข้อมูลอื่น ๆ

    • เนื้อหานี้ถูกนำเสนอในงาน [un]prompted AI security conference 2026
    • กรณีการค้นพบของ Claude Code ถูกประเมินว่าเป็นตัวอย่างที่แสดงให้เห็นว่า AI สามารถเพิ่มผลิตภาพของงานวิจัยด้านความปลอดภัยจริงได้อย่างมาก

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

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

 
m3op0w94 23 일 전

ด้านที่มีความหวัง: พบช่องโหว่ของ Linux
ด้านที่สิ้นหวัง: ยกเลิกการจำกัดขอบเขตของ curl
 
GN⁺ 26 일 전
ความเห็นจาก Hacker News

  • ไม่น่าแปลกใจนัก แต่สิ่งที่บทความไม่ได้พูดถึงคือ Claude Code หา บั๊กปลอม มาได้อีก 1,000 รายการ และนักพัฒนาต้องใช้เวลา 3 เดือนในการคัดกรองสิ่งเหล่านั้น

    • ตอนนี้มันไม่ได้ทำงานแบบนั้นแล้ว LLM จะคัดบั๊กที่ทำซ้ำไม่ได้ออกเองใน pipeline ชั้นที่สอง การตรวจสอบว่ามันเป็นช่องโหว่ที่กระตุ้นให้เกิดขึ้นได้จริงนั้นง่ายกว่าการค้นหาเสียอีก เลยแทบจะเหลือแต่บั๊กจริงด้วยความแม่นยำเกือบ 100% ยังมีคนจำนวนมากที่ปฏิเสธความก้าวหน้าของ LLM แต่ยากที่จะปฏิเสธเรื่อง ความมีประโยชน์
    • อยากรู้แหล่งที่มา ไม่เคยเห็นข้อมูลแบบนั้นเลย จากประสบการณ์ของฉัน อัตรา false positive ในการตรวจหาช่องโหว่ของ Claude Opus 4.6 ต่ำกว่า 20%
    • เครื่องมือวิเคราะห์แบบสถิต/ไดนามิกก็หาช่องโหว่ได้ตลอดเหมือนกัน โปรเจ็กต์ใหญ่ส่วนมากมี backlog ของ issue ที่สแกนเนอร์พ่นออกมาอยู่แล้ว ปัญหาคือการคัดว่าอันไหนอันตรายจริง การที่ Claude หาเจอบั๊กเก่าได้นั้นน่าสนใจ แต่พอมีสแกนเนอร์ใหม่ออกมาก็มักเกิดเรื่องแบบนี้เสมอ
    • ในบทความไม่ได้เขียนว่ามี false positive เยอะ ตรงกันข้าม เขียนว่า “ยังมีบั๊กที่ยังตรวจสอบไม่เสร็จอีกมากเกินไป”
    • บทเรียนไม่ใช่ว่า Claude Code ไร้ประโยชน์ แต่คือถ้าอยู่ในมือคนที่เหมาะสม มันจะเป็น เครื่องมือทรงพลัง

  • การวางโค้ดใหม่จำนวนมากทีเดียวแล้วถาม Claude ว่า “ฉันพลาดอะไรไป? บั๊กอยู่ตรงไหน?” เป็นแนวทางที่น่าเชื่อมากสำหรับนักพัฒนาที่เพิ่งเริ่มใช้ AI โดยเฉพาะมันช่วยหา บั๊กด้าน threading หรือ บั๊กในระบบกระจาย ได้เร็วมาก ตอนนี้คงมีโค้ดคริปโตจำนวนมากกำลังถูกวิเคราะห์อยู่

    • ฉันชอบ ชี้นำ prompt ให้ Claude ตั้งต้นจากสมมติฐานว่า “มีบั๊กอยู่” เช่นถามว่า “โค้ดนี้มีบั๊กนะ หาเจอไหม?” หรือเสริมว่า “บั๊กไม่ได้เห็นได้ชัด” แล้วอัตราความสำเร็จจะสูงขึ้น
    • ฉันเองก็ใช้ CC/codex เกือบจะในลักษณะนี้เหมือนกัน
    • ใช้แบบถามว่า “นี่เป็นโค้ดที่ Codex เขียน มีอะไรดูผิดปกติไหม?”

  • จะเรียกว่าเป็นบั๊กที่ “ซ่อนอยู่” ก็ไม่ค่อยถูกนัก น่าจะเรียกว่า “ไม่มีใครเข้าไปดู” มากกว่า โค้ดมันเขียนข้อมูล 1056 ไบต์ลงในบัฟเฟอร์ขนาด 112 ไบต์ มันเป็นปัญหาที่เครื่องมือวิเคราะห์แบบสถิตก็จับได้ไม่ยาก แต่ถ้าสั่ง LLM ว่า “ให้ตรวจบัฟเฟอร์ขนาดคงที่ทั้งหมด” ก็อาจมี ผลลวง ปนมาด้วย ถึงอย่างนั้นมันก็เป็นจุดเริ่มต้นที่ดี

    • ช่องโหว่ส่วนใหญ่ยังคงอยู่เพราะ “ไม่มีใครเข้าไปดู” ความซับซ้อนของระบบสะสมขึ้นเรื่อยๆ จนมนุษย์ตามไม่ทัน ถ้าแก้ปัญหานี้ได้ก็เป็นข่าวใหญ่ เครื่องมือวิเคราะห์แบบสถิตจะรายงานทุกเส้นทางการคัดลอกบัฟเฟอร์ที่เป็นไปได้ แต่ในความเป็นจริงบางกรณีอินพุตถูกจำกัดอยู่แล้ว จึงไม่ค่อยแม่นใน Linux kernel
    • ที่จริงแล้วคำว่า “ไม่มีใครเข้าไปดู” ก็คือการขาดแคลนกำลังคน คนและเวลาที่จะค้นหาช่องโหว่ในโอเพนซอร์สมีจำกัด แต่ตอนนี้ข้อจำกัดนั้นกำลังถูกทำลายลงเพราะโมเดล เก่งพอแล้ว ปีนี้น่าจะเป็นปีที่น่าตื่นเต้นมาก
    • บอกว่าเครื่องมือวิเคราะห์แบบสถิตหาง่าย แต่ในความเป็นจริงไม่มีใครหาเจอมานานกว่า 20 ปี พอ LLM ทำอะไรเจ๋งๆ ได้ ก็มักจะมีคนตอบว่า “ก็ไม่ได้ยากอะไร” ซึ่งตลกดี

  • ที่น่าสนใจคือ ในบั๊กที่พบ 5 ตัวนั้น มี 3~4 ตัวที่น่าจะถูก บรรเทาผลกระทบ ได้ด้วย แพตช์ linux-hardened เช่น การปิดใช้งาน io_uring, ทำให้ kernel crash เมื่อเกิด UAF, การป้องกันการนำ heap overflow ไปใช้โจมตี เป็นต้น

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

    • นั่นไม่สมเหตุสมผลเลย การเปรียบการค้นหาและรายงานช่องโหว่ว่าเป็น การโปรยอาวุธชีวเคมี มันเกินไปมาก

  • ฉันลองทำซ้ำการทดลองกับโค้ดเบส production หลายแห่งแล้ว พบว่า บั๊กซ้ำ, false positive, และบั๊กที่ใช้โจมตีไม่ได้ มีเยอะ แต่ก็มี ช่องโหว่ร้ายแรงระดับ crit จริงอยู่ไม่น้อยเหมือนกัน

  • ระหว่างช่วง Q&A ของงานเปิดตัว ฉันสงสัยว่าวิดีโอที่เปิดอยู่ด้านหลังคือ วิดีโอ อะไร มันเป็น เดโม exploit ที่ใช้บั๊ก NFS ผ่านเครือข่าย USB หรือเปล่า?

  • นี่คืองานที่เกี่ยวข้องจากห้องแล็บด้านความปลอดภัยของเรา ปีนี้เราเจอ ช่องโหว่ 23 รายการ แล้วด้วย AI security agent

  • คลัง 0-day ของ หน่วยงานสามตัวอักษร (หน่วยข่าวกรอง) น่าจะลดลงอย่างรวดเร็ว

  • แทนที่จะคาดหวังว่าจะมี รายงานช่องโหว่ เพิ่มขึ้น ควรคาดว่าจะมี ความพยายามโจมตี เพิ่มขึ้นมากกว่า