ค้นพบ 0-day ระยะไกลโดยใช้ o3 กับการติดตั้งใช้งาน SMB บนลินุกซ์

• แชร์ประสบการณ์การใช้ โมเดล OpenAI o3 เพื่อค้นพบ ช่องโหว่ 0-day ระยะไกล (CVE-2025-37899) ในการติดตั้งใช้งาน SMB ของลินุกซ์เคอร์เนล
• ระหว่างการทำเบนช์มาร์ก ความสามารถในการวิเคราะห์ของ LLM กับโค้ดของ ksmbd ได้ทำการทดลองเปรียบเทียบประสิทธิภาพของ LLM โดยใช้ช่องโหว่ที่เคยค้นพบด้วยตนเองมาก่อนเป็นเกณฑ์อ้างอิง
• ในกระบวนการตรวจหาช่องโหว่ ได้ออกแบบให้ o3 สามารถรับรู้ช่องโหว่ได้ด้วยการ จัดคอนเท็กซ์ตามฟังก์ชันและให้พรอมป์ต์ที่เหมาะสม
• ผลการทดลองพบว่า o3 มีความแม่นยำในการค้นหาช่องโหว่สูงกว่า LLM เดิม 2–3 เท่า และยังค้นพบบั๊ก use-after-free รูปแบบใหม่ได้โดยอัตโนมัติพร้อมกัน
• LLM โดยเฉพาะโมเดลรุ่นใหม่อย่าง o3 แสดงให้เห็นถึง ความยืดหยุ่นและความคิดสร้างสรรค์คล้ายแนวทางของมนุษย์ในการตรวจสอบโค้ดและวิจัยช่องโหว่ ทำให้มีคุณค่าในการนำไปใช้จริงสูงขึ้น

---

บทนำ

บทความนี้อธิบายวิธีใช้โมเดล o3 ของ OpenAI เพื่อค้นพบช่องโหว่ 0-day ระยะไกลใน ksmbd ซึ่งเป็นการติดตั้งใช้งาน SMB ของลินุกซ์เคอร์เนล การทดลองนี้ใช้เพียง o3 API โดยไม่มีเฟรมเวิร์กหรือเครื่องมือเพิ่มเติมใด ๆ ksmbd คือเซิร์ฟเวอร์ที่ทำหน้าที่แชร์ไฟล์ผ่านเครือข่ายโดยติดตั้งใช้งานโปรโตคอล SMB3 ภายในลินุกซ์เคอร์เนล ระหว่างการทำ audit ช่องโหว่เพื่อพักจากงานพัฒนาเกี่ยวกับ LLM ผู้เขียนได้ทำเบนช์มาร์กเพื่อดูว่า o3 สามารถค้นหาบั๊กจริงได้ดีเพียงใด โดยเน้นที่ช่องโหว่ zero-day ที่ o3 ค้นพบ คือ CVE-2025-37899

ช่องโหว่นี้เป็นปัญหา use-after-free ที่เกิดขึ้นระหว่างการประมวลผลคำสั่ง SMB logoff ซึ่งต้องอาศัยความเข้าใจทั้งเรื่อง สถานการณ์การเชื่อมต่อพร้อมกัน กับเซิร์ฟเวอร์ และวิธีที่หลายเธรดแชร์ออบเจ็กต์บางตัวร่วมกัน o3 สามารถตรวจพบช่องโหว่นี้ได้จากการทำความเข้าใจประเด็นด้าน concurrency และความผิดพลาดในการจัดการออบเจ็กต์ภายในบริบท นี่เป็นกรณีสาธารณะแรกที่ LLM ค้นพบช่องโหว่ประเภทนี้

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

การทำเบนช์มาร์ก o3 โดยใช้ CVE-2025-37778

ภูมิหลังและจุดประสงค์ของเบนช์มาร์ก

เริ่มจากใช้ CVE-2025-37778 ซึ่งเป็นช่องโหว่ที่ค้นพบด้วยตนเองมาก่อน (ต่อไปจะเรียกว่าช่องโหว่การยืนยันตัวตน kerberos) เป็นจุดอ้างอิงในการประเมินความสามารถของ o3 ในการตรวจจับช่องโหว่ นี่เป็นปัญหาที่ use-after-free เกิดขึ้นในกระบวนการยืนยันตัวตนของไคลเอนต์เมื่อสถานะของเซสชันตรงตามเงื่อนไขบางอย่าง

• ปล่อยออบเจ็กต์ผู้ใช้ออกจากหน่วยความจำเมื่อสถานะเซสชันเป็น SMB2_SESSION_VALID
• หลังจากนั้นหากการยืนยันตัวตนล้มเหลว ออบเจ็กต์ผู้ใช้จะไม่ถูกเริ่มต้นใหม่อีก และยังสามารถถูกเข้าถึงในสภาพเดิมได้ จึงเกิด use-after-free
• การทำความเข้าใจเส้นทางที่เกี่ยวข้องทั้งหมดต้องไล่ตามโค้ดราว 3,300 บรรทัด จึงเป็นโจทย์เบนช์มาร์กที่มีระดับความยากพอเหมาะ

การจัดคอนเท็กซ์สำหรับการวิเคราะห์

ในการทดลองนี้ ได้ออกแบบคอนเท็กซ์ (ช่วงของโค้ด) ที่จะส่งให้ LLM อย่างรอบคอบจากมุมมองของระบบตรวจหาช่องโหว่อัตโนมัติจริง โดยจัดตามหน่วยของ SMB command handler และรวมฟังก์ชันหลักกับฟังก์ชันย่อยลึกลงไปถึง 3 ระดับของ call depth เพื่อป้อนโค้ดทั้งหมดที่มีความสัมพันธ์ทางตรรกะเข้าไป (รวม 3.3k LoC, ประมาณ 27k โทเคน) เพื่อให้ได้ผลลัพธ์ที่เชื่อถือได้ จำเป็นต้องรวมฟังก์ชันที่เกี่ยวข้องกับการแยกวิเคราะห์ข้อมูล การแตกแขนงคำขอ การตัดการเชื่อมต่อ และอื่น ๆ ด้วย

พรอมป์ต์และข้อมูลนำเข้าที่ใช้จริงสามารถดูได้ใน GitHub repository ที่เกี่ยวข้อง โดยให้เงื่อนไขกับ LLM ดังนี้:

• สั่งอย่างชัดเจนให้ตรวจหาช่องโหว่ use-after-free
• อธิบายโครงสร้างพื้นฐานและ threat model ของ ksmbd แบบย่อ
• ใช้พรอมป์ต์ชี้นำเพื่อลด false positive

คำสั่งจริงถูกเรียกซ้ำผ่านเครื่องมือบรรทัดคำสั่ง llm เพื่อเก็บผลการทดลอง (N=100)

ผลการทดลองเบนช์มาร์ก

• o3 : จาก 100 ครั้ง ตรวจพบช่องโหว่การยืนยันตัวตน kerberos 8 ครั้ง, ไม่พบ 66 ครั้ง, รายงาน false positive 28 ครั้ง
• Claude Sonnet 3.7 : ตรวจพบเพียง 3 ครั้ง
• Claude Sonnet 3.5 : ตรวจไม่พบทั้ง 100 ครั้ง

สุดท้าย o3 ทำความแม่นยำได้สูงกว่า LLM เดิมมากกว่า 2–3 เท่า นอกจากนี้ เอาต์พุตของ o3 ยังสั้นกระชับคล้ายรายงานสรุปที่นักวิจัยความปลอดภัยเขียนขึ้นเอง ขณะที่ผลลัพธ์ของ Sonnet 3.7 ให้ความรู้สึกคล้ายบันทึกการทำงานที่เน้นกระบวนการ ซึ่งมีทั้งข้อดีและข้อเสีย

การค้นพบ 0-day จริง (CVE-2025-37899) ผ่าน o3

การทดลองในสภาพแวดล้อมที่ป้อนโค้ดปริมาณมาก

นอกเหนือจากช่องโหว่ kerberos แล้ว ยังได้ลองให้ o3 ตรวจหาช่องโหว่ในภาพรวมโดยใส่ SMB command handler ทั้งหมด (ประมาณ 9,000 บรรทัด) รวมถึงโค้ดเชื่อมต่อ/ยกเลิกการเชื่อมต่อ และส่วนอื่น ๆ รวมแล้วประมาณ 12k LoC (ราว 100,000 โทเคน) ในครั้งเดียว เมื่อรันซ้ำ 100 ครั้ง ช่องโหว่การยืนยันตัวตน kerberos ถูกตรวจพบเพียง 1 ครั้งเท่านั้น แสดงให้เห็นถึงประสิทธิภาพที่ลดลงอย่างชัดเจน แต่เป้าหมายหลักคือการทดลองความเป็นไปได้ของการใช้ LLM กับโค้ดในขอบเขตที่ใหญ่ขึ้น

ช่องโหว่ใหม่ที่ค้นพบในการทดลองครั้งนี้

ระหว่างนั้น o3 พบว่ามีบั๊ก use-after-free ตัวใหม่ที่ไม่ใช่ช่องโหว่การยืนยันตัวตน kerberos โดยเป็นปัญหา concurrency ใน logoff handler ของเซสชัน ซึ่งในสถานะที่มีการเชื่อมต่อพร้อมกัน สองเธรดแชร์/เข้าถึงออบเจ็กต์ user ของเซสชันเดียวกัน และหลังจากเธรดหนึ่งปล่อยออบเจ็กต์ไปแล้ว อีกเธรดก็ยังอ้างอิงมันต่อได้

สรุปรายงานช่องโหว่อัตโนมัติจาก o3

• worker thread สองตัวทำงานร่วมกัน โดยตัวหนึ่งทำการยกเลิกเซสชัน (logoff) และปล่อยออบเจ็กต์ user ออกจากหน่วยความจำ ขณะที่อีกตัวหนึ่งยังคงใช้ออบเจ็กต์ user จากเซสชันเดิมต่อไป
• หากมีการ dereference จากอีกเส้นทางหนึ่งทันทีหลังการปล่อยหน่วยความจำ (ก่อนจะถูกตั้งค่าเป็น NULL) ก็จะเกิด use-after-free แบบคลาสสิก
• ขึ้นอยู่กับจังหวะเวลา อาจเกิด NULL dereference จนนำไปสู่ DoS ได้ด้วย
• อาจลุกลามไปสู่ความเสียหายของหน่วยความจำเคอร์เนลและการรันโค้ดตามอำเภอใจได้

อินไซต์ที่ได้จากรายงานอัตโนมัติ

จากรายงานอัตโนมัตินี้ ทำให้เห็นว่าวิธีแก้ของช่องโหว่การยืนยันตัวตน kerberos ที่มีอยู่เดิม (ตั้งค่าเป็น NULL ทันทีหลัง free) ไม่ใช่วิธีแก้เชิงรากฐานสำหรับกระบวนการ logoff กล่าวคือ ต้องคำนึงถึงการผูกเซสชันและเวกเตอร์โจมตีระหว่างเธรด จึงจะรับประกันความปลอดภัยได้ o3 เองก็สามารถมองทะลุประเด็นนี้ได้ในบางรายงาน และพิสูจน์ว่าสามารถเสนอแนวทางแก้ที่ “แข็งแรงกว่า” ได้

สรุป

LLM โดยเฉพาะโมเดลรุ่นใหม่อย่าง o3 แสดงสมรรถนะที่ ใกล้เคียงนักวิจัยความปลอดภัยที่เป็นมนุษย์มากกว่าวิธีเดิมอย่างชัดเจน ในด้านการวิเคราะห์โค้ดอย่างยืดหยุ่นและสร้างสรรค์ ก่อนหน้านี้สิ่งนี้ยังถูกพูดถึงในเชิงทฤษฎีเป็นหลัก แต่ o3 เป็นกรณีแรกที่แสดงให้เห็นในตัวอย่างจริงว่าไปถึงระดับที่ “ใช้งานช่วยได้จริง” แล้ว แน่นอนว่า o3 ยังมีโอกาสเกิด false positive และการพลาดตรวจพบอยู่ แต่ตอนนี้ก็มาถึงจุดที่ มีความเป็นไปได้สูงขึ้นว่าจะสร้างผลลัพธ์ที่มีประโยชน์จริง จนคุ้มค่ากับการนำไปใช้ในงานปฏิบัติ แล้ว นี่จึงเป็นช่วงเวลาที่นักวิจัยด้านช่องโหว่และนักพัฒนาควรเริ่มหาวิธีผสาน LLM เข้ากับ workflow ของตนอย่างมีประสิทธิภาพ

[GN⁺]

ความเห็นจาก Hacker News

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

  • ที่น่าขำคือผู้เขียนก็ยอมรับอย่างตรงไปตรงมาว่า "จริง ๆ แล้ว system prompt ทั้งหมดของฉันตั้งอยู่บนการคาดเดา และห่างไกลจากความเป็นวิทยาศาสตร์หรือวิศวกรรม"

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

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

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

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

  • พอนึกดูเมื่อไม่กี่วันก่อน ก็สงสัยว่าเราจะใช้ประวัติทั้งหมดใน Linux kernel เช่นทุกการเปลี่ยนแปลงใน git รายชื่ออีเมล และอื่น ๆ มาพัฒนาเป็นโมเดลที่ fine-tune แล้วได้ไหม
    ถ้าเป็น LLM แบบนั้น ก็น่าจะได้เวอร์ชันสังเคราะห์ที่ใกล้เคียงกับสัญชาตญาณของนักพัฒนาที่อยู่กับโค้ดมานานจริง ๆ
    แค่ high-context อย่างเดียวก็น่าจะครอบคลุมได้มาก และบาง codebase เองก็มีตัวโค้ดเกิน 200,000 โทเคนอยู่แล้ว เลยคิดว่ามีความเป็นไปได้

  • อัตรา 1:50 ถือว่ายอดเยี่ยมมากสำหรับสถานการณ์แบบ ‘งมเข็มในกองฟาง’

  • ถ้า LLM เขียนทั้ง harness สำหรับพิสูจน์ข้อสันนิษฐานของแต่ละช่องโหว่ และเขียนการทดสอบ proof of concept ได้เอง อัตราส่วนสัญญาณต่อสัญญาณรบกวนน่าจะดีขึ้นมาก
    แต่ตอนนี้ระบบอัตโนมัติแบบนั้นยังมีต้นทุนค่อนข้างสูง น่าเสียดายอยู่

• สิ่งที่น่าประทับใจที่สุดคือผู้เขียนเองรันการค้นหาช่องโหว่ซ้ำถึง 100 ครั้งต่อ LLM แต่ละโมเดล
  ทรัพยากรที่ทุ่มในระดับนี้สูงมากเมื่อเทียบกับปัญหาส่วนใหญ่ที่ฉันเคยให้ LLM ช่วยจัดการ จนตอนนี้เริ่มคิดแล้วว่าอาจต้องลองให้โมเดลทำแบบ ‘วนซ้ำแบบไม่คิดมาก’ ดูบ้าง

  • สุดท้ายก็คือสรุปว่าต้องใช้เงินเยอะ

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

  • การรัน 100 ครั้งต่อโมเดลก็หมายถึงการใช้พลังงานไม่น้อยเช่นกัน
    การหาช่องโหว่แบบที่พบได้บ่อยในโค้ด C ด้วยการทุ่มทรัพยากรขนาดนี้ ทำให้ความหมายของมันดูจางลง และยิ่งเน้นภาพของความสิ้นเปลืองกับความฟุ่มเฟือยมากกว่า
    เมื่อคิดว่าตอนนี้เราอยู่ท่ามกลางวิกฤตสภาพภูมิอากาศระดับโลก ก็อดกังวลไม่ได้ว่ามนุษย์กำลังเผาทรัพยากรไปกับเรื่องที่ไม่ได้มีคุณค่ามาก เหมือนในยุค 1950 อีกครั้ง

• เพราะ Claude ไม่ได้ให้ scratchpad (พื้นที่จดความคิดระหว่างทาง) แยกต่างหาก จึงดูเหมือนว่าผลลัพธ์มีทั้งกระบวนการคิดและรายงานปนกันอยู่
  เลยอยากทดลองว่าถ้าอนุญาตให้ Claude มีพื้นที่จัดระเบียบความคิดอย่างเป็นทางการแล้ว มันจะเปลี่ยนไปแค่ไหน
  ในขณะที่ o3 กลั่นเอาเฉพาะเนื้อหาสำคัญออกมาในลักษณะคล้ายรายงานบั๊กที่มนุษย์เขียน ผลลัพธ์ของ Sonnet 3.7 กลับยังมีความเป็นกระแสความคิดหรือ log การทำงานหลงเหลืออยู่ ซึ่งก็น่าจะมาจากสาเหตุเดียวกัน

  • ฉันลองใช้ทั้ง o3, 3.7 และ Gemini 2.5 pro มาเองแล้ว และรู้สึกว่า o3 อยู่คนละชั้นแบบเทียบไม่ได้
    คะแนน benchmark อาจดูไม่ได้ห่างกันมาก แต่ยิ่งงานซับซ้อน ความหมายของช่องว่างนี้ก็ยิ่งชัด
    สงสัยว่าทำไมประกาศตั้งแต่พฤศจิกายนปีที่แล้ว แต่เพิ่งออกจริงเมื่อประมาณเดือนก่อนเท่านั้น (เดาว่าน่าจะเพื่อเคลียร์เรื่องความปลอดภัย) และตอนนี้ก็รอ o4 อยู่เหมือนกัน

  • อยากรู้ว่ามีเคส งานวิจัย หรือบทความที่ใช้ "scratchpad" ในการวิจัย พร้อมลิงก์แนะนำบ้างไหม

• ชอบมากที่มันสรุปแก่นของกระบวนการ prompt engineering ได้ตรงเหลือเกิน
  โดยเฉพาะช่วงที่บอกว่า "ฉันพยายามอย่างเต็มที่เพื่อชี้นำไม่ให้มันทำเครื่องหมายช่องโหว่ผิด ๆ เป็น false positive แต่จริง ๆ แล้วฉันไม่มีทางรู้ว่ามันช่วยได้ไหม แค่หวังว่ามันจะช่วย ยังประเมินได้ไม่พอว่าจะได้ผลหรือเปล่า ดังนั้นมันจึงไม่ใช่ทั้งวิทยาศาสตร์และวิศวกรรม แล้วจะมาแชร์ผลการประเมินทีหลัง" ซึ่งเหมือนกับวิธีพัฒนาพรอมป์ต์ของฉันมาก

• รู้สึกว่านี่อาจเป็น use case ที่เหมาะกับ LLM มากที่สุดก็ได้ คือเรื่องการตรวจหาช่องโหว่อัตโนมัติ
  ในทางทฤษฎี เราสามารถทำทั้งกระบวนการให้เป็นอัตโนมัติ และใช้ LLM เหมือน fuzzer ที่ก้าวหน้ามาก ๆ โดยคอยรันเป้าหมายใน VM อย่างต่อเนื่อง แล้วถ้าตรวจพบพฤติกรรมผิดปกติก็ระบุได้ว่าอาจเป็นช่องโหว่จริง
  (นึกถึงว่าการ exploit ระยะแรกจำนวนมากมักเริ่มจากการทำให้เครื่องล่มหรือเกิด crash ก่อน แล้วค่อยพัฒนาต่อ)
  การใช้ LLM แบบนี้ด้านหนึ่งก็ดูมีประสิทธิภาพมาก แต่อีกด้านก็ชวนให้คิดว่า "แค่เราทำการทดสอบแบบนี้ได้ ไม่ได้แปลว่าเราได้ค้นพบบางสิ่งที่ใหม่หรือชี้ขาดอย่างยิ่งใหญ่"

• ฝากสไลด์ที่ตัวเองเคยนำเสนอเรื่องการทำ automation targeting สำหรับ zk bug (เกี่ยวกับ zero-knowledge proof) ไว้ที่ลิงก์ YouTube

  • ขอแชร์ลิงก์แบบสะอาด ของวิดีโอ YouTube ด้านบนอีกครั้ง โดยตัดพารามิเตอร์ติดตามออก
    เข้าใจว่าพารามิเตอร์เพิ่มเติมพวกนั้นมีไว้เพื่อติดตามลิงก์

• หวังจริง ๆ ว่ามันจะไม่กลายเป็นแบบเดียวกับปัญหาที่ระเบิดใส่ curl อยู่เรื่อย ๆ
  ดูบริบทที่เกี่ยวข้องได้จากบทความของ Daniel Stenberg

• เท่าที่ฉันรู้ ksmbd เป็น SMB server ใน kernel space ที่มุ่งเน้นความเบาและประสิทธิภาพสูง มากกว่าจะเป็น Samba server แบบดั้งเดิม
  Q1: อยากรู้ว่าในทางปฏิบัติมีใครใช้ ksmbd ใน production บ้าง
  Q2: แล้วใช้เพราะอะไร

  • 1. คิดว่าผู้ใช้หลักน่าจะเป็นคนที่เคยใช้ SMB server ที่ฝังอยู่ใน kernel บน Solaris หรือ Windows

2. ประสิทธิภาพของ Samba ยังด้อยกว่านั้นมาก จนแม้ในปี 2025 ก็ยังมีคนจำนวนมากรัน Windows เป็นไฟล์เซิร์ฟเวอร์อยู่
   มีใครรู้ไหมว่ามันรองรับ ACL แบบเนทีฟเหมือนบน Windows หรือเปล่า
   (นี่เป็นเหตุผลสุดท้ายที่ยังทำให้ Solaris มีค่าอยู่สำหรับฉัน โดยเข้าใจว่า ZFS รองรับสิ่งนี้)
   Samba ยังติดอยู่กับโครงสร้างล้าสมัยที่ต้องซิงก์กับ UID/GID และโมเดลความปลอดภัยแบบ Unix
   แต่ SMB server ใน kernel เองก็เคยมีช่องโหว่ remote root ร้ายแรงบน Windows เกิดขึ้นจริงมาแล้ว จึงต้องชั่งน้ำหนัก trade-off ให้ชัด

• สาเหตุมาจากเรื่องไลเซนส์
  Samba เป็น GPLv3 แต่ Linux ใช้ได้แค่ GPLv2

• เดาว่าใช้เพราะมันเบาและประสิทธิภาพสูงล้วน ๆ

• คิดว่าคล้ายกับเหตุผลที่คนใช้ kmod-trelay แทน relayd

• คิดว่าโจทย์ใหญ่ระยะสั้นที่สุดของ LLM (Alignment Problem) กลับสะท้อนออกมาผ่านการทำ automation ช่องโหว่แบบนี้
  ไม่นานมานี้ฉันใช้ LLM หาเจอช่องโหว่ร้ายแรงมากในเซิร์ฟเวอร์เฉพาะทางตัวหนึ่งที่ฉันใช้อยู่เป็นครั้งคราว โดยแทบไม่ต้องออกแรงอะไรเลย
  ถ้าตลาดนี้ถูกทำให้เป็นอัตโนมัติ ก็อดกังวลไม่ได้ว่าซอฟต์แวร์กลุ่ม long tail จำนวนมากที่เมื่อก่อนยังไม่คุ้มค่าจะเจาะด้วยมือ อาจเริ่มมีปัญหาร้ายแรงโผล่ออกมาเป็นจำนวนมาก

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

  • ผู้โจมตีอาจใช้ automation ตรวจหาช่องโหว่ได้ แต่ฝั่งป้องกันก็มีความสามารถนี้ได้เหมือนกัน
    สามารถเอาไปผูกกับกระบวนการอนุมัติคอมมิตหรือรันเป็นระบบป้องกันอัตโนมัติในทุก ๆ build ได้