ลดช่องทางเจาะระบบถึงระดับ root ลงอีกนับพัน
เราพัฒนาระบบอัตโนมัติสำหรับค้นหาและทดสอบช่องโหว่ รวมถึงสร้างแพตช์แก้ไข โดยการทดสอบด้วยโมเดลด้านความปลอดภัยไซเบอร์ของเราเพียงครั้งเดียว สามารถยืนยันช่องโหว่ LPE ใน Linux ได้ 948 รายการ พร้อมสร้างแพตช์แก้ไข ด้วยเครดิต API มูลค่า 1.2 ล้านดอลลาร์
งานวิจัยด้านความปลอดภัยที่แต่เดิมต้องใช้เวลาตรวจสอบข้อค้นพบแต่ละรายการอย่างละเอียดและต่อเนื่อง ปัจจุบันสามารถดำเนินการอย่างเป็นระบบได้มากขึ้น บทความนี้จะพาไปสำรวจหนึ่งในแนวทางที่เราพัฒนาขึ้นเพื่อบรรลุเป้าหมายดังกล่าว
แม้ปัจจุบันจะสามารถค้นหาช่องโหว่ได้ในวงกว้างมากขึ้น แต่การตัดสินใจว่าควรจัดการกับช่องโหว่ใดก่อน และการตรวจสอบว่าช่องโหว่เหล่านั้นมีอยู่จริงหรือไม่ ยังคงเป็นขั้นตอนที่ทำให้การทำงานล่าช้า เราจึงสร้างระบบต้นแบบเพื่อค้นหาช่องโหว่ด้านความปลอดภัยในเคอร์เนล Linux ภายในสภาพแวดล้อมการวิจัยที่มีการควบคุม ผลปรากฏว่าระบบสามารถค้นหาและวิเคราะห์จุดที่อาจเป็นช่องโหว่ได้ 2,308 รายการ ทดสอบจนยืนยันช่องโหว่ได้ 1,724 รายการและสร้างโค้ดโจมตีเพื่อยกระดับสิทธิ์ภายในเครื่อง (LPE) ได้ 948 รายการ ซึ่งอาจเปิดทางให้ผู้ใช้ทั่วไปที่ไม่มีสิทธิ์พิเศษเข้าถึงระบบด้วยสิทธิ์ root ได้
เราใช้ข้อมูลที่ได้จากการทดสอบมาจัดลำดับความสำคัญของช่องโหว่ที่จะรายงาน พร้อมพัฒนาแพตช์เบื้องต้นเพื่อให้ผู้ดูแลโครงการตรวจสอบ โดยเราเริ่มจากช่องโหว่ที่มีความร้ายแรงระดับวิกฤตตามคำแนะนำของชุมชนผู้พัฒนาเคอร์เนล Linux และขณะนี้กำลังร่วมมือกับพันธมิตรของ Patch the Planet เพื่อจัดทำรายงานและแพตช์แก้ไขสำหรับช่องโหว่อื่นๆ เพิ่มเติม
เมื่อเดือนมิถุนายนที่ผ่านมา เราได้เปิดเผยข้อมูลภายใต้โครงการ Patch the Planet ว่า GPT‑5.5 Cyber สามารถค้นพบช่องโหว่ในเคอร์เนล Linux และพัฒนาโค้ดโจมตีเพื่อยกระดับสิทธิ์ภายในเครื่องจำนวน 24 รายการ เพื่อใช้ตรวจสอบยืนยันและรายงานช่องโหว่เหล่านั้น จากนั้นเราต่อยอดงานดังกล่าวเป็นระบบที่ขับเคลื่อนด้วยโมเดลด้านความปลอดภัยไซเบอร์รุ่นใหม่ที่กำลังจะเปิดตัว โดยครอบคลุมตั้งแต่การค้นหาช่องโหว่ การทดสอบยืนยันแบบไดนามิก การประเมินว่าช่องโหว่สามารถนำไปใช้โจมตีได้จริงหรือไม่ ไปจนถึงการสร้างแพตช์แก้ไข เมื่อระบบทำงานเสร็จสิ้น ผู้วิจัยจะตรวจสอบผลลัพธ์ก่อนรายงานช่องโหว่ที่พบพร้อมส่งแพตช์สำหรับแก้ไข
สรุป
ขั้นตอนและวิธีการวิจัย
กระบวนการทำงานของระบบเราแบ่งเป็นขั้นตอนหลักๆ โดยเริ่มจากการระบุส่วนของเคอร์เนล Linux ที่เกี่ยวข้องกับความปลอดภัย แล้วใช้การวิเคราะห์โค้ดแบบสแตติก (Static Analysis) เพื่อตรวจหาจุดที่อาจมีช่องโหว่ในส่วนที่กำหนดให้ตรวจสอบ จากนั้นใช้การทดสอบแบบไดนามิก (Dynamic Testing) เพื่อจำลองปัญหาที่ตรวจพบให้เกิดขึ้นจริงในสภาพแวดล้อมที่แยกออกจากระบบอื่น พร้อมสร้างโค้ดพิสูจน์แนวคิด (Proof of Concept หรือ PoC) เพื่อแสดงให้เห็นว่าสามารถนำช่องโหว่ไปใช้โจมตีได้จริง ก่อนสร้างแพตช์สำหรับแก้ไขช่องโหว่ และให้ผู้วิจัยด้านความปลอดภัยตรวจสอบผลลัพธ์ในขั้นตอนสุดท้าย
ผลลัพธ์จากกระบวนการนี้ประกอบด้วยการวิเคราะห์สาเหตุที่แท้จริงของช่องโหว่ โค้ดพิสูจน์แนวคิดที่เขียนขึ้นอย่างกระชับเพื่อแสดงให้เห็นว่าช่องโหว่สามารถทำให้ระบบหรือโปรแกรมหยุดทำงานผิดปกติได้ แพตช์ที่เสนอสำหรับแก้ไขช่องโหว่ และโค้ดโจมตีที่ใช้งานได้จริงอย่างสมบูรณ์ ซึ่งช่วยให้ผู้วิจัยด้านความปลอดภัยประเมินความร้ายแรงของช่องโหว่และส่งการแก้ไขกลับไปยังโครงการต้นทางได้
ผลการวิจัย
ในการทดสอบครั้งหนึ่งเมื่อช่วงกลางเดือนตุลาคม 2569 ระบบของเราใช้โมเดลด้านความปลอดภัยไซเบอร์ที่กำลังจะเปิดตัว ทดสอบจนสามารถทำให้เกิดช่องโหว่ขึ้นจริงได้ 1,724 รายการ พร้อมสร้างโค้ดพิสูจน์แนวคิดสำหรับช่องโหว่ที่ทำให้ข้อมูลรั่วไหล 291 รายการ และสร้างโค้ดโจมตีที่ใช้งานได้จริง 948 รายการ สำหรับช่องโหว่ที่ทำให้ผู้ใช้ในระบบสามารถยกระดับสิทธิ์ของตนเอง (Local Privilege Escalation หรือ LPE) บน Linux รุ่นที่ใช้งานกันอย่างแพร่หลาย การทดสอบครั้งนี้ใช้เครดิต API รวม 1,213,430 ดอลลาร์ หรือเฉลี่ย 1,279 ดอลลาร์ต่อโค้ดโจมตี LPE หนึ่งรายการ
เครื่องเสมือนที่ใช้เป็นเป้าหมายในการทดสอบติดตั้งระบบปฏิบัติการสำหรับคอมพิวเตอร์ทั่วไปในสภาพมาตรฐาน ไม่ใช่ระบบที่ถูกลดระดับความปลอดภัยลง โดยใช้แบบจำลองภัยคุกคามเดียวกับการแข่งขันด้านความปลอดภัยไซเบอร์ เช่น Pwn2Own(เปิดในหน้าต่างใหม่) และ TyphoonPWN(เปิดในหน้าต่างใหม่) ในอดีต การแข่งขันทั้งสองรายการเสนอเงินรางวัลสำหรับโค้ดโจมตี LPE ในเคอร์เนล Linux ที่ 20,000 ดอลลาร์และ 70,000 ดอลลาร์ตามลำดับ หากนำอัตราเงินรางวัลในอดีตเหล่านี้มาคำนวณกับโค้ดโจมตีทั้ง 948 รายการ จะได้มูลค่าประเมินตามสมมติฐานที่ 18.9–66.3 ล้านดอลลาร์ หรือประมาณ 16–55 เท่าของต้นทุนการดำเนินงานทั้งหมดของระบบเรา
เมื่อทดสอบระบบของเราในสภาพแวดล้อม kernelCTF(เปิดในหน้าต่างใหม่) ที่ปรับแต่งให้ใช้เคอร์เนล Linux ซึ่งลดช่องทางที่อาจถูกใช้โจมตีลง ระบบสามารถสร้าง PoC สำหรับช่องโหว่ที่ทำให้ข้อมูลรั่วไหลได้ 25 รายการ และโค้ดโจมตี LPE ภายในระบบได้ 21 รายการ เมื่อเทียบกันแล้ว ณ เวลาที่เขียนบทความนี้ kernelCTF ได้รับรองโค้ดโจมตี LPE แบบ 0-day ที่ยืนยันแล้ว 26 รายการในปี 2569
การทดสอบครั้งนี้ใช้เครดิต API คิดเป็นมูลค่าประมาณ 32,936 ดอลลาร์ หากช่องโหว่ทั้ง 21 รายการผ่านเกณฑ์ของโครงการ ก็จะได้รับเงินรางวัลรวมประมาณ 1.5 ล้านดอลลาร์ หรือคิดเป็นประมาณ 45 เท่าของต้นทุนในการสแกนหาช่องโหว่
เท่าที่เราทราบ เอเจนต์ในระบบนี้สามารถค้นพบและนำเทคนิคใหม่ๆ ในการใช้ประโยชน์จากช่องโหว่ของ Linux เพื่อโจมตีระบบมาใช้ได้อย่างน้อย 10 เทคนิค
ข้อสังเกต
ผู้ดูแลโครงการ Linux และชุมชนด้านความปลอดภัยต่างทุ่มเททำงานอย่างหนักเพื่อค้นหาและแก้ไขช่องโหว่ให้ได้โดยเร็วที่สุด ระหว่างที่ระบบของเราสแกนหาช่องโหว่เป็นเวลา 10 วัน เราพบว่าช่องโหว่ LPE ภายในระบบ Linux มากกว่า 100 รายการได้รับการแก้ไขแล้ว หรือมีแพตช์แก้ไขจากผู้ร่วมพัฒนารายอื่นที่อยู่ระหว่างเตรียมนำไปใช้ ขณะที่ช่องโหว่อีกประมาณ 300 รายการกำลังมีการเปิดเผยและพูดคุยกันอย่างเปิดเผย
โมเดล AI ระดับแนวหน้าค้นพบช่องโหว่ได้รวดเร็วขึ้นเรื่อยๆ เราจึงเชื่อว่าการสร้างแพตช์แก้ไขช่องโหว่แบบอัตโนมัติเป็นสิ่งจำเป็น เพื่อให้แก้ไขปัญหาด้านความปลอดภัยได้รวดเร็วเพียงพอ และลดเวลาที่ผู้โจมตีมีโอกาสใช้ช่องโหว่เหล่านั้น เราเชื่อว่าหากมีผู้เชี่ยวชาญคอยให้คำแนะนำและช่วยปรับปรุงแพตช์ที่ AI สร้างขึ้นเป็นระยะ ก็จะสามารถพัฒนาแพตช์ให้ทำงานได้ถูกต้อง ใช้รูปแบบการเขียนโค้ดที่สอดคล้องกับโค้ดเดิม และรับมือกับการโจมตีในรูปแบบต่างๆ ที่อาศัยช่องโหว่เดียวกันได้ ซึ่งเป็นเรื่องสำคัญที่ยังต้องศึกษาวิจัยต่อไป
โมเดลที่มีความสามารถสูงขึ้นสามารถค้นพบช่องโหว่ใหม่ในโค้ดที่มีอยู่เดิมได้ รวมถึงช่องโหว่ที่แฝงอยู่มานานและตรวจพบได้ยากกว่าเดิม ในการทดสอบช่วงกลางเดือนตุลาคม 2569 ระบบวิเคราะห์ของเราที่ใช้โมเดลด้านความปลอดภัยไซเบอร์รุ่นใหม่ สามารถค้นพบ LPE ที่ไม่เคยมีการค้นพบมาก่อนมากกว่า 5 เท่าของการทดสอบด้วย GPT‑5.6 Sol เมื่อเดือนกรกฎาคม แม้จะมีการเสริมความปลอดภัยของระบบอย่างต่อเนื่องตลอด 3 เดือนระหว่างการทดสอบทั้งสองครั้งก็ตาม
โครงการซอฟต์แวร์ขนาดใหญ่ที่มีความซับซ้อนอาจต้องผ่านการสแกนหาช่องโหว่และแก้ไขซ้ำหลายรอบ จึงจะสามารถค้นพบและแก้ไขข้อบกพร่องที่ซ่อนอยู่ได้อย่างครอบคลุมที่สุด ทางที่ดีควรดำเนินกระบวนการนี้ซ้ำทุกครั้งที่มีโมเดล AI ระดับแนวหน้ารุ่นใหม่ออกมา โดยแนวทางนี้ใช้ได้กับทั้งซอฟต์แวร์ที่เป็นกรรมสิทธิ์และซอฟต์แวร์โอเพนซอร์ส
ในระยะสั้นถึงระยะกลาง หากผู้โจมตีที่มีทรัพยากรพร้อมสามารถเข้าถึงบัญชีผู้ใช้ที่มีสิทธิ์ระดับต่ำบนระบบปฏิบัติการที่ยังไม่ได้ติดตั้งแพตช์ล่าสุด ก็ควรมองว่าในทางปฏิบัติผู้โจมตีนั้นสามารถเข้าถึงระบบด้วยสิทธิ์ระดับ root ได้เช่นกัน ดังนั้น การป้องกันหลายชั้นโดยใช้แซนด์บ็อกซ์และเทคนิคแยกสภาพแวดล้อม เช่น Firecracker และ gVisor จึงมีความสำคัญในการจำกัดขอบเขตความเสียหายเมื่อมีการใช้ประโยชน์จากช่องโหว่เพื่อโจมตีระบบ
เราคาดว่าในอีกไม่กี่ปีข้างหน้า โมเดล AI ระดับแนวหน้าจะสามารถค้นพบช่องโหว่ที่มีอยู่ในโครงการซอฟต์แวร์ต่างๆ ได้ และหลังจากมีการเปิดเผยช่องโหว่ แม้แต่โมเดลที่มีความสามารถไม่สูงเท่าก็อาจนำข้อมูลนั้นไปพัฒนาโค้ดโจมตีได้ ในโลกที่ไม่มีช่องโหว่ใดหลุดรอดจากการค้นพบอีกต่อไป การพัฒนาและดูแลรักษาซอฟต์แวร์ให้มีความน่าเชื่อถือด้านความปลอดภัยในระดับสูงจึงเป็นสิ่งสำคัญอย่างยิ่ง โดยเฉพาะซอฟต์แวร์พื้นฐานที่สำคัญ เช่น ระบบปฏิบัติการ เบราว์เซอร์ ไลบรารีสำหรับประมวลผลไฟล์ภาพ และชุดโพรโทคอล TCP/IP นอกจากการค้นหาและแก้ไขช่องโหว่เดิมแล้ว การฝึกโมเดลให้เขียนโค้ดที่ปลอดภัยตั้งแต่แรก การตัดฟีเจอร์ที่ไม่จำเป็นเพื่อลดโอกาสถูกโจมตี และการพิสูจน์ความถูกต้องด้วยวิธีการทางคณิตศาสตร์ ล้วนเป็นแนวทางที่มีศักยภาพในการยกระดับความปลอดภัยของซอฟต์แวร์ให้ครอบคลุมได้มากขึ้นอย่างมีประสิทธิภาพ
ระบบที่ผู้คนหลายพันล้านคนทั่วโลกใช้งาน ตั้งแต่อุปกรณ์ Android และระบบคลาวด์ ไปจนถึงซูเปอร์คอมพิวเตอร์ ล้วนต้องพึ่งพาเคอร์เนล Linux เป็นพื้นฐานสำคัญ เคอร์เนลนี้มีโค้ดมากกว่า 40 ล้านบรรทัด และมีหลายส่วนที่อาจกลายเป็นช่องทางให้ผู้โจมตีใช้เจาะระบบได้ ไม่ว่าจะเป็นการเรียกใช้บริการของระบบ การทำงานของเครือข่าย ระบบไฟล์ หรือไดรเวอร์อุปกรณ์ เราจึงเลือก Linux เป็นกรณีศึกษา เพื่อประเมินว่าโมเดล AI ระดับแนวหน้าจะค้นพบช่องโหว่และพิสูจน์ให้เห็นถึงผลกระทบต่อความปลอดภัยได้ดีเพียงใด เมื่อต้องทำงานกับซอฟต์แวร์ที่ทั้งใหญ่และมีความสำคัญขนาดนี้
ขั้นตอนการค้นหาช่องโหว่เบื้องต้นพบจุดที่อาจเป็นช่องโหว่หลายพันรายการ ซึ่งมีจำนวนมากเกินกว่าที่ผู้วิจัยด้านความปลอดภัยจะตรวจสอบและคัดกรองด้วยตนเองได้ทั้งหมด ความท้าทายหลักของระบบเราไม่ได้อยู่ที่การค้นหาช่องโหว่ แต่อยู่ที่การพิจารณาว่าข้อค้นพบใดสามารถทดสอบให้เกิดปัญหาขึ้นจริงได้ ข้อค้นพบเหล่านั้นละเมิดขอบเขตการรักษาความปลอดภัยใดบ้าง และรายการใดควรได้รับการพิจารณาจากผู้ดูแลโครงการก่อน
ภารกิจของทีม Cyber ของ OpenAI คือการช่วยยกระดับความปลอดภัยของซอฟต์แวร์ที่ผู้คนทั่วโลกต้องพึ่งพา เราจึงเปิดเผยต้นทุนการใช้ API ในแต่ละขั้นตอน เพื่อให้นักวิจัยประเมินได้ว่าต้องใช้ทรัพยากรมากเพียงใดในการทดลองซ้ำและต่อยอดงานวิจัยนี้ โดยต้นทุนที่รายงานสะท้อนถึงโมเดล การตั้งค่าระบบเป้าหมาย และกระบวนการทำงานที่ใช้ในการประเมินครั้งนี้ เป้าหมายที่กว้างกว่านั้นของเราคือการช่วยให้ฝ่ายป้องกันค้นพบและแก้ไขช่องโหว่ เพื่อลดโอกาสในการโจมตีและเพิ่มต้นทุนในการใช้ประโยชน์จากช่องโหว่จนผู้โจมตีลงมือได้ยากขึ้น
สุดท้ายนี้ เราขอเน้นย้ำว่างานวิจัยครั้งนี้มุ่งศึกษาวิธีการและประเมินความสามารถของโมเดลเป็นหลัก ไม่ได้มุ่งเน้นเรื่องต้นทุน เราคาดว่าหากพัฒนาระบบและเครื่องมือที่สนับสนุนการทำงานของโมเดลให้เหมาะสมมากขึ้น ก็จะสามารถลดต้นทุนในแต่ละขั้นตอนได้อย่างมาก ดังนั้น ตัวเลขต้นทุนที่เรารายงานจึงควรมองว่าเป็นค่าประมาณในระดับสูง มากกว่าจะเป็นต้นทุนขั้นต่ำที่จำเป็นต้องใช้จริง
ระบบต้นแบบสำหรับวิจัยช่องโหว่ของเราประกอบด้วยกระบวนการทำงาน 5 ขั้นตอน โดยมีโมเดลด้านความปลอดภัยไซเบอร์รุ่นใหม่ที่กำลังจะเปิดตัวเป็นหัวใจสำคัญ ดังนี้
การค้นหาช่องโหว่: เอเจนต์ระบุส่วนของฐานโค้ดที่เกี่ยวข้องกับความปลอดภัย แล้วสแกนหาประเด็นที่อาจเป็นช่องโหว่
การตรวจสอบยืนยันแบบไดนามิก: เอเจนต์จะทดสอบจุดที่อาจเป็นช่องโหว่แต่ละรายการในสภาพแวดล้อมที่แยกออกจากระบบอื่น เพื่อดูว่าสามารถทำให้เกิดปัญหาตามที่ตรวจพบได้จริงหรือไม่ พร้อมบันทึกหลักฐานที่ได้ระหว่างการรันโปรแกรม ผลลัพธ์จากขั้นตอนนี้คือช่องโหว่ที่สามารถทดสอบให้เกิดขึ้นจริงและผ่านการตรวจสอบยืนยันแล้ว
การประเมินความเป็นไปได้ในการโจมตี: เอเจนต์ทดสอบว่าช่องโหว่ที่ยืนยันแล้วอาจทำให้ข้อมูลรั่วไหลหรือยกระดับสิทธิ์ภายในเครื่องได้หรือไม่
การสร้างแพตช์: เอเจนต์สร้างแพตช์เพื่อแก้ไขช่องโหว่แต่ละรายการที่พบ
การตรวจสอบโดยมนุษย์: นักวิจัยด้านความปลอดภัยตรวจสอบโค้ดโจมตี แพตช์ และระดับความรุนแรงที่เสนอ ก่อนรายงานต่อผู้ดูแล
เมื่อสิ้นสุดกระบวนการ ระบบจะรวบรวมการวิเคราะห์สาเหตุหลัก โค้ดพิสูจน์แนวคิดที่ทำให้ระบบล่มแบบสั้นที่สุด แพตช์ที่เสนอ และโค้ดโจมตีฉบับสมบูรณ์ เพื่อช่วยนักวิจัยที่เป็นมนุษย์ประเมินความรุนแรงของช่องโหว่และส่งการแก้ไขกลับไปยังโครงการต้นทาง
โค้ดในเคอร์เนล Linux ไม่ได้เกี่ยวข้องกับความปลอดภัยทุกบรรทัด กระบวนการของเราใช้ทีมเอเจนต์สำรวจเพื่อระบุเป้าหมายที่คุ้มค่าแก่การตรวจสอบ แล้วส่งต่อให้เอเจนต์วิเคราะห์สแกนหาช่องโหว่
เอเจนต์สำรวจอ่านแต่ละโฟลเดอร์และไฟล์ แล้วเลือกเป้าหมายที่จะตรวจสอบโดยพิจารณาว่าผู้ใช้ที่มีสิทธิ์ต่ำสามารถเข้าถึงได้หรือไม่ และเกี่ยวข้องกับความปลอดภัยเพียงใด
ขั้นตอนนี้ระบุเป้าหมายการตรวจสอบได้ 5,034 รายการ รวมโค้ดประมาณ 2.8 ล้านบรรทัด หรือราว 7% ของฐานโค้ดเคอร์เนล Linux ทั้งหมด ช่วยลดต้นทุนการตรวจสอบความปลอดภัยได้อย่างมากเมื่อเทียบกับการวิเคราะห์ฐานโค้ดทั้งหมด ขั้นตอนนี้ใช้เครดิต API มูลค่า 3,426 ดอลลาร์สหรัฐ
จากนั้น เอเจนต์วิเคราะห์จะวิเคราะห์เป้าหมายแต่ละรายการและรายงานประเด็นที่อาจเป็นช่องโหว่ โดยใช้เวิร์กโฟลว์คล้ายกับปลั๊กอิน Codex Security(เปิดในหน้าต่างใหม่) โดยภาพรวม เอเจนต์วิเคราะห์จะอ่านโค้ดของเป้าหมายที่ได้รับมอบหมายเพื่อทำความเข้าใจการทำงาน ระบุแบบจำลองภัยคุกคาม และค้นหาช่องโหว่ในโค้ดนั้น
ภายใน 12 ชั่วโมง เอเจนต์วิเคราะห์รายงานประเด็นที่อาจเป็นช่องโหว่ได้ 2,308 รายการหลังตัดรายการซ้ำออก ขั้นตอนนี้ใช้เครดิต API มูลค่า 316,549 ดอลลาร์สหรัฐ
สิ่งที่ตรวจพบว่าอาจเป็นช่องโหว่ยังไม่ถือว่าเป็นช่องโหว่ที่ได้รับการยืนยันแล้ว และด้วยจำนวนรายงานที่มากขนาดนี้ ทีมวิจัยของเราจึงไม่สามารถตรวจสอบแต่ละรายงานด้วยตนเองได้ทั้งหมด
เราจึงมุ่งตรวจสอบยืนยันเฉพาะจุดที่อาจเป็นช่องโหว่ซึ่งเข้าเงื่อนไข 3 ข้อ ได้แก่ ก) ผู้ใช้ที่มีสิทธิ์ระดับต่ำสามารถเข้าถึงได้ ข) ไม่จำเป็นต้องมีสิทธิ์หรือความสามารถพิเศษใดๆ และ ค) มีหลักฐานที่ตรวจวัดได้ว่าข้อมูลในหน่วยความจำเกิดความเสียหาย
สำหรับแต่ละจุดที่อาจเป็นช่องโหว่ เอเจนต์คัดกรองจะสร้าง PoC และนำไปทดสอบในเครื่องเสมือนที่แยกออกจากระบบอื่น โดยใช้เคอร์เนล Linux ที่ติดตั้ง Kernel Address Sanitizer (KASAN) เอเจนต์จะตรวจสอบทั้งผลลัพธ์จากโปรแกรมและข้อความที่แสดงบนคอนโซลของระบบ จากนั้นปรับปรุง PoC และทดสอบซ้ำจนกว่าจะสามารถทำให้เกิดพฤติกรรมตามที่รายงานไว้ได้จริง หรือลองทุกวิธีที่อาจกระตุ้นให้เกิดพฤติกรรมนั้นแล้ว
ในเวลาเพียง 30 ชั่วโมง ระบบของเราสามารถทดสอบจนยืนยันช่องโหว่ได้ 1,724 รายการ คิดเป็นประมาณ 74.7% ของจุดที่อาจเป็นช่องโหว่ทั้งหมด 2,308 รายการ เนื่องจากการวิเคราะห์โค้ดโดยไม่รันโปรแกรมอาจทำให้ตรวจพบช่องโหว่ที่ไม่มีอยู่จริงได้ เราจึงรู้สึกประทับใจกับความแม่นยำของเอเจนต์วิเคราะห์ รวมถึงความสามารถของเอเจนต์คัดกรองในการสร้าง PoC ที่ทำงานได้จริงด้วยตนเอง สำหรับข้อค้นพบเบื้องต้นเกือบสามในสี่ของทั้งหมด
สำหรับจุดที่อาจเป็นช่องโหว่ส่วนใหญ่ที่ยังยืนยันไม่ได้ บางกรณีจำเป็นต้องใช้สิทธิ์ระดับสูง หรือไม่สามารถทดสอบให้เกิดปัญหาขึ้นจริงได้ภายในเวลาที่กำหนด เพราะมีเงื่อนไขซับซ้อนเกี่ยวกับการทำงานพร้อมกันของโปรแกรม ต้องอาศัยเงื่อนไขเฉพาะในการกระตุ้นให้เกิดปัญหา (เช่น การจัดสรรหน่วยความจำต้องล้มเหลวที่โค้ดบรรทัดใดบรรทัดหนึ่งโดยเฉพาะ) หรือมีขั้นตอนการตรวจสอบยืนยันที่ใช้เวลานาน (ตัวนับจำนวนการอ้างอิงเพิ่มจนเกินค่าสูงสุดและวนกลับไปเริ่มใหม่) มีเพียง 3.1% เท่านั้นที่เกิดจากการวิเคราะห์ผิดพลาดของโมเดล โดยโมเดลระบุว่ามีช่องโหว่จากเงื่อนไขที่ไม่สามารถเกิดขึ้นได้จริง
เราใช้เครดิต API มูลค่ารวม 73,330 ดอลลาร์ในการตรวจสอบยืนยันช่องโหว่ โดยพบว่าการสร้าง PoC เพื่อทดสอบว่าจุดที่ตรวจพบนั้นเป็นช่องโหว่จริงหรือไม่ มีค่าใช้จ่ายสูงกว่าการวิเคราะห์โค้ดโดยไม่รันโปรแกรมแล้วประเมินผลจากข้อมูลที่พบเพียงอย่างเดียว นอกจากนี้ ไม่ว่าผลการตรวจพบจะเป็นช่องโหว่จริงหรือเป็นการตรวจพบผิดพลาด ค่าใช้จ่ายในการทดสอบยืนยันก็แทบไม่ต่างกัน การคัดกรองผลการตรวจพบที่ผิดพลาดออกตั้งแต่เนิ่นๆ จึงช่วยให้ระบบทำงานได้คุ้มค่ากับต้นทุนมากขึ้นอย่างชัดเจน
การตรวจสอบยืนยันช่วยให้ทราบว่าช่องโหว่นั้นมีอยู่จริง แต่ยังไม่สามารถบอกได้ว่าจำเป็นต้องแก้ไขเร่งด่วนเพียงใด ตัวอย่างเช่น ช่องโหว่ที่อาจทำให้ผู้โจมตียกระดับสิทธิ์ภายในระบบได้ควรได้รับความสำคัญมากกว่าช่องโหว่ที่ทำได้เพียงขัดขวางการให้บริการภายในระบบ เมื่อเราตรวจสอบยืนยันช่องโหว่ได้แล้ว 1,724 รายการ ขั้นตอนต่อไปจึงเป็นการคัดเลือกช่องโหว่ที่อาจส่งผลกระทบต่อความปลอดภัยร้ายแรงที่สุด
ในขั้นตอนคัดกรองเบื้องต้น เอเจนต์จะตรวจสอบรายงานแต่ละฉบับ บันทึกการหยุดทำงานผิดปกติของโปรแกรม และโค้ดที่เกี่ยวข้องโดยไม่ต้องรันโปรแกรม เราตั้งใจให้การคัดกรองในขั้นตอนนี้ไม่เข้มงวดจนเกินไป เพื่อป้องกันไม่ให้ช่องโหว่ที่อาจมีความร้ายแรงถูกตัดออก ขณะเดียวกันก็คัดกรองกรณีที่ไม่มีแนวทางที่เป็นไปได้ในการใช้ช่องโหว่โจมตีออกไป ทำให้เหลือจุดที่อาจเป็นช่องโหว่ข้อมูลรั่วไหล 313 รายการ และจุดที่อาจเป็นช่องโหว่ซึ่งนำไปสู่การยกระดับสิทธิ์ในเครื่องอีก 1,238 รายการ
ในขั้นตอนถัดไป เอเจนต์ ExploitDev จะทดสอบจุดที่อาจเป็นช่องโหว่ในเครื่องเสมือนที่แยกจากระบบอื่น โดยตั้งค่าให้เปิดใช้ระบบป้องกันตามปกติของ Linux ได้แก่ Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) และ HARDENED_USERCOPY วิธีนี้ช่วยป้องกันไม่ให้ผลการประเมินคลาดเคลื่อนจากความเป็นจริงเพียงเพราะทดสอบภายใต้เงื่อนไขที่ปิดมาตรการป้องกันเหล่านี้
เอเจนต์สร้างโค้ดพิสูจน์แนวคิดสำหรับข้อมูลรั่วไหล 291 รายการ และโค้ดโจมตีเพื่อยกระดับสิทธิ์ภายในเครื่องที่ใช้งานได้จริง 1,169 รายการ ซึ่งอาจทำให้ผู้ใช้ภายในเครื่องที่ไม่มีสิทธิ์พิเศษได้รับสิทธิ์ root
เราได้วิเคราะห์วิธีโจมตีรูปแบบต่างๆ ที่อาศัยช่องโหว่เดียวกัน และพัฒนาแพตช์แก้ไข 948 รายการสำหรับช่องโหว่ที่ถูกนำไปใช้ในการโจมตีเหล่านั้น โดยแต่ละแพตช์แก้ไขช่องโหว่ที่แตกต่างกัน เราจึงใช้จำนวนแพตช์ดังกล่าวในการนับจำนวนช่องโหว่ LPE ที่ไม่ซ้ำกันทั้งหมด ทั้งนี้ การพัฒนาโค้ดโจมตีที่ใช้งานได้สำเร็จมีต้นทุนเฉลี่ย 359 ดอลลาร์ในรูปของเครดิต API จึงถือว่าฝ่ายป้องกันสามารถทดสอบว่าช่องโหว่ที่ค้นพบนั้นนำไปใช้โจมตีได้จริงหรือไม่ด้วยต้นทุนที่ค่อนข้างต่ำ
การคัดกรองช่องโหว่เบื้องต้นโดยเอเจนต์ใช้เครดิต API คิดเป็นมูลค่า 44,194 ดอลลาร์ ขณะที่ขั้นตอนการทดสอบนำช่องโหว่ไปใช้โจมตีมีค่าใช้จ่ายรวม 775,929 ดอลลาร์ โดยเป็นค่าใช้จ่ายในการทดสอบจุดที่อาจทำให้ข้อมูลรั่วไหล 84,929 ดอลลาร์ และจุดที่อาจนำไปสู่ LPE อีก 691,000 ดอลลาร์
การนำจุดที่อาจเป็นช่องโหว่ LPE มาทดสอบเพื่อพัฒนาโค้ดโจมตีมีค่าใช้จ่ายเฉลี่ย 558 ดอลลาร์ต่อรายการ ซึ่งสูงกว่าการทดสอบกรณีที่อาจทำให้ข้อมูลรั่วไหลที่มีค่าใช้จ่ายเฉลี่ย 271 ดอลลาร์เกือบสองเท่า เนื่องจาก PoC สำหรับช่องโหว่ข้อมูลรั่วไหลสามารถนำมาจากขั้นตอนการตรวจสอบยืนยันก่อนหน้าได้เลย และปรับแก้เพิ่มเติมเพียงเล็กน้อยก็สามารถนำไปใช้ในการโจมตีได้ ต่างจากการพัฒนาโค้ดโจมตีจากจุดที่อาจเป็นช่องโหว่ LPE ซึ่งต้องดำเนินการอีกหลายขั้นตอน ทั้งการวางแผนกลยุทธ์การโจมตี การระบุออบเจ็กต์ที่มีช่องโหว่เพื่อนำมาใช้ และการหาวิธีหลบเลี่ยงมาตรการป้องกันต่างๆ เรายังพบด้วยว่าการพยายามโจมตีแล้วไม่สำเร็จมีค่าใช้จ่ายสูงกว่าการโจมตีที่สำเร็จมาก โดย 69 กรณีที่ไม่สำเร็จมีต้นทุนเฉลี่ย 3,922 ดอลลาร์ต่อกรณี ขณะที่ 1,169 กรณีที่สำเร็จมีต้นทุนเฉลี่ยเพียง 360 ดอลลาร์ต่อกรณี สาเหตุหลักมาจากช่องโหว่บางรายการที่โจมตีได้ยาก เช่น ปัญหาที่ต้องอาศัยจังหวะการทำงานพร้อมกันของโปรแกรม หากเราตั้งเงื่อนไขให้หยุดพยายามเมื่อไม่มีความคืบหน้าเป็นเวลา 1 ชั่วโมง ก็จะช่วยประหยัดต้นทุนในการทำงานของ ExploitDev ได้มาก
ระบบของเรายังสร้างแพตช์สำหรับแก้ไขช่องโหว่แต่ละรายการที่ผ่านการตรวจสอบยืนยันแล้วด้วย โดยเราจะให้โมเดลเข้าถึงซอร์สโค้ดที่เกี่ยวข้อง พร้อมคำแนะนำเกี่ยวกับแนวทางปฏิบัติที่ดีในการเขียนแพตช์ เช่น การตรวจสอบแพตช์โดยไม่ต้องรันโปรแกรม การเขียนโค้ดให้สอดคล้องกับแนวทางการพัฒนาที่ใช้ในโค้ดส่วนใกล้เคียง และการวิเคราะห์รูปแบบอื่นๆ ของช่องโหว่ เพื่อให้มั่นใจว่าแพตช์สามารถแก้ไขปัญหาได้อย่างครอบคลุม
เราได้นำคำแนะนำจากชุมชนเคอร์เนล Linux มาปฏิบัติ โดยเริ่มจากการส่งรายงานและแพตช์แก้ไขช่องโหว่ระดับวิกฤตไปแล้วหลายร้อยรายการ ขณะเดียวกันก็กำลังทำงานร่วมกับพาร์ทเนอร์ของ Patch the Planet เพื่อทยอยส่งแพตช์สำหรับช่องโหว่ที่เหลือ การดำเนินงานนี้เป็นส่วนหนึ่งของพันธกิจ Daybreak ที่เรามุ่งสนับสนุนโครงการโอเพนซอร์สต่างๆ
ในส่วนนี้ เราจะแบ่งปันสิ่งที่ได้เรียนรู้ ข้อสังเกต และการวิเคราะห์เพิ่มเติมจากงานวิจัยนี้
งานวิจัยครั้งนี้ทำให้เราเห็นว่า ผู้ดูแลโครงการ Linux กำลังเร่งแก้ไขช่องโหว่เพื่อปกป้องผู้ใช้งานอย่างเต็มที่ เราเริ่มสแกนหาช่องโหว่ในเคอร์เนล Linux รุ่นล่าสุดเมื่อช่วงกลางเดือนตุลาคม 2569 และเมื่อการสแกนอัตโนมัติและการวิเคราะห์โดยผู้วิจัยเสร็จสิ้นในอีก 10 วันต่อมา ช่องโหว่ LPE จำนวน 61 รายการก็ได้รับการแก้ไขในโค้ดต้นทางแล้ว อีก 43 รายการมีแพตช์ที่อยู่ระหว่างเตรียมนำไปรวมกับโค้ดต้นทาง ส่วนอีก 299 รายการอยู่ระหว่างการรายงานและหารือกันอย่างเปิดเผย
เราขอขอบคุณผู้ดูแลโครงการ Linux ทุกคนที่เร่งแก้ไขช่องโหว่ที่ตรวจพบอย่างเต็มที่ ตลอดจนสมาชิกในชุมชนด้านความปลอดภัยที่ร่วมแบ่งปันสิ่งที่ค้นพบ เพราะการร่วมมือกันเช่นนี้คือสิ่งสำคัญที่จะช่วยให้ซอฟต์แวร์ทั่วโลกปลอดภัยยิ่งขึ้น นอกจากนี้ การเปิดเผยช่องโหว่และการออกแพตช์แก้ไขอย่างรวดเร็วยังตอกย้ำว่าการอัปเดตซอฟต์แวร์ให้เป็นเวอร์ชันล่าสุดอยู่เสมอมีความสำคัญอย่างยิ่งต่อทั้งผู้ใช้งานและองค์กร
ข้อคิดสำคัญ: การคัดกรองช่องโหว่โดยอัตโนมัติควรคำนึงถึงการออกแพตช์แก้ไขที่เกิดขึ้นอย่างรวดเร็วด้วย โดยต้องนำข้อค้นพบมาตรวจสอบยืนยันอีกครั้งกับโค้ดเวอร์ชันล่าสุด รวมถึงโค้ดใหม่ที่เพิ่มเข้ามาหลังการสแกนครั้งแรก เพื่อหลีกเลี่ยงการรายงานช่องโหว่ซ้ำหรือรายงานปัญหาที่ได้รับการแก้ไขไปแล้ว วิธีนี้ช่วยให้มุ่งเน้นไปที่ช่องโหว่ที่ยังไม่ได้รับการแก้ไข และช่วยให้ผู้ดูแลโครงการมีหลักฐานที่นำไปใช้ดำเนินการต่อได้ทันที โดยไม่เพิ่มภาระในการตรวจสอบโดยไม่จำเป็น
ระหว่างที่เรากำลังพัฒนาระบบนี้ในช่วงปลายเดือนกรกฎาคม 2569 GPT‑5.6 Sol สามารถค้นพบช่องโหว่ LPE ที่ไม่ซ้ำกัน 166 รายการ และนำช่องโหว่เหล่านั้นไปใช้โจมตีได้จริง โดยกระบวนการทั้งหมดตั้งแต่ต้นจนจบใช้เครดิต API มูลค่ารวม 513,690 ดอลลาร์
ในการสแกนครั้งที่สองช่วงกลางเดือนตุลาคม 2569 โมเดลด้านความปลอดภัยไซเบอร์รุ่นใหม่สามารถค้นพบช่องโหว่ LPE ที่ไม่ซ้ำกัน 948 รายการ และนำช่องโหว่เหล่านั้นไปใช้โจมตีได้จริง โดยใช้เครดิต API มูลค่ารวม 1,213,430 ดอลลาร์ตลอดกระบวนการ สำหรับการทดสอบทั้งสองครั้ง เราใช้โค้ดจาก master branch เวอร์ชันล่าสุดของเคอร์เนล Linux ณ เวลาที่ทำการสแกนแต่ละครั้ง
ข้อคิดสำคัญ: เมื่อโมเดลมีความสามารถมากขึ้น ก็ควรนำโค้ดที่เคยตรวจสอบแล้วกลับมาสแกนซ้ำ เพราะโมเดลรุ่นใหม่ที่เก่งกว่าอาจมองเห็นช่องโหว่ที่รุ่นก่อนๆ มองข้ามไป แม้จะใช้เครื่องมือและกระบวนการวิจัยแบบเดียวกัน
เราสุ่มเลือกโค้ดโจมตี 166 รายการที่เอเจนต์พัฒนาขึ้นมาวิเคราะห์เทคนิคที่ใช้ในการโจมตี เท่าที่เราทราบ เอเจนต์ใช้เทคนิคการโจมตีรูปแบบใหม่ถึง 10 เทคนิคในโค้ดโจมตีที่สุ่มเลือกมา เราได้นำเทคนิคเหล่านี้ไปให้ผู้เชี่ยวชาญภายนอกด้านการโจมตีช่องโหว่ในเคอร์เนลตรวจสอบ และพบว่าเทคนิคดังกล่าวเป็นสิ่งที่ผู้เชี่ยวชาญเหล่านั้นไม่เคยพบมาก่อนเช่นกัน
เทคนิคใหม่ทั้ง 10 เทคนิคแบ่งออกเป็นหลายรูปแบบ โดย 2 เทคนิคใช้สร้างออบเจ็กต์ชนิดใหม่ที่สามารถปรับขนาดและคงอยู่ในหน่วยความจำ เพื่อกระจายออบเจ็กต์จำนวนมากไว้ในแคชเป้าหมายของเคอร์เนล อีก 2 เทคนิคเป็นวิธีใหม่ในการจัดการตำแหน่งและรูปแบบการจัดวางเพจหน่วยความจำ เพื่อให้การโจมตีมีโอกาสสำเร็จมากขึ้น ขณะที่อีก 5 เทคนิคอาศัยการแก้ไขข้อมูลโดยไม่ต้องเปลี่ยนเส้นทางการทำงานของโปรแกรม เพื่อยกระดับสิทธิ์โดยตรงหรือผ่านการเขียนข้อมูลลงในตำแหน่งหน่วยความจำที่เลือกได้ ส่วนเทคนิคที่เหลือใช้ประโยชน์จากการตีความชนิดข้อมูลผิดพลาด เราจึงเลือกไม่เปิดเผยรายละเอียดทางเทคนิคทั้งหมดของเทคนิคเหล่านี้ในบทความด้วยเหตุผลด้านความปลอดภัย
ข้อคิดสำคัญ: โมเดลระดับแนวหน้าไม่ได้เพียงจับคู่รูปแบบโค้ดที่ทราบว่ามีช่องโหว่ หรือใช้เฉพาะเทคนิคโจมตีที่เป็นที่รู้จักเท่านั้น แต่ยังแสดงความคิดสร้างสรรค์และแนวทางใหม่ๆ ด้วย
ภารกิจสำคัญอย่างหนึ่งของทีมเราคือการศึกษาว่าการค้นหาช่องโหว่และนำไปใช้โจมตีมีต้นทุนเท่าไร แล้วนำข้อมูลที่ได้มาใช้ประกอบการตัดสินใจลงทุนด้านการป้องกัน เป้าหมายของเราคือการช่วยให้ฝ่ายป้องกันแก้ไขช่องโหว่ได้ก่อนที่ผู้โจมตีจะนำไปใช้ และทำให้การโจมตีผ่านช่องโหว่มีต้นทุนสูงจนไม่คุ้มค่าที่จะลงมือ การวัดต้นทุนในการโจมตีจึงช่วยให้เราประเมินได้ว่าความท้าทายนี้เปลี่ยนแปลงไปอย่างไรเมื่อโมเดลมีความสามารถสูงขึ้น ในส่วนนี้ เราจะเปรียบเทียบต้นทุนการทดสอบระบบของเรากับเงินรางวัลที่โครงการให้รางวัลสำหรับการค้นพบช่องโหว่กำหนดไว้สำหรับช่องโหว่ที่ตรวจพบ
เครื่องเสมือนที่ใช้เป็นเป้าหมายในการทดลองของเราติดตั้งระบบปฏิบัติการเดสก์ท็อปตามมาตรฐานทั่วไป ไม่ใช่ระบบที่จงใจลดระดับความปลอดภัยลง โดยใช้แบบจำลองภัยคุกคามเดียวกับการแข่งขันด้านความปลอดภัยไซเบอร์ เช่น Pwn2Own(เปิดในหน้าต่างใหม่) และ TyphoonPWN(เปิดในหน้าต่างใหม่) ซึ่งในอดีตเคยเสนอเงินรางวัลโค้ดโจมตีเพื่อยกระดับสิทธิ์ภายในเครื่องผ่านเคอร์เนล Linux ที่ 20,000 ดอลลาร์และ 70,000 ดอลลาร์ตามลำดับ หากนำอัตราเงินรางวัลในอดีตเหล่านี้มาประเมินมูลค่าโค้ดโจมตีทั้ง 948 รายการ จะได้มูลค่ารวมตามสมมติฐานที่ 18.9–66.3 ล้านดอลลาร์ หรือประมาณ 16–55 เท่า ของต้นทุนระบบที่เราใช้ในการทดลอง
เรายังได้นำระบบไปทดสอบกับโครงการให้รางวัลสำหรับการค้นพบช่องโหว่ kernelCTF(เปิดในหน้าต่างใหม่) ของ Google ซึ่งใช้เคอร์เนล Linux ที่ผ่านการเสริมความปลอดภัยและลดช่องทางที่อาจถูกใช้โจมตีเป็นเป้าหมาย โดยเราทดสอบระบบกับเคอร์เนล Linux เวอร์ชันล่าสุดในสภาพแวดล้อมของ kernelCTF แต่เนื่องจากเคอร์เนลเวอร์ชันดังกล่าวไม่รองรับมาตรการป้องกัน SLAB_VIRTUAL ของ kernelCTF เราจึงนำมาตรการนี้ออกจากการตั้งค่า ผลการทดสอบพบว่าระบบสามารถสร้าง PoC สำหรับช่องโหว่ที่อาจทำให้ข้อมูลรั่วไหลได้ 25 รายการ และโค้ดโจมตี LPE อีก 21 รายการ เมื่อเทียบกับผลการดำเนินงานของ kernelCTF ในปี 2569 ซึ่ง ณ เวลาที่เขียนบทความนี้ได้ตรวจสอบและรับรองโค้ดโจมตี LPE ผ่านช่องโหว่ 0-day แล้ว 26 รายการ การทดสอบของเราใช้เวลาทั้งหมด 112 ชั่วโมง และมีค่าใช้จ่ายในรูปของเครดิต API ประมาณ 32,936 ดอลลาร์ โดยขั้นตอนการค้นหาช่องโหว่คิดเป็น 83.7% ของค่าใช้จ่ายทั้งหมด หากช่องโหว่ทั้ง 21 รายการผ่านเกณฑ์ของโครงการ ก็อาจได้รับเงินรางวัลรวมราว 1.5 ล้านดอลลาร์ ซึ่งสูงกว่าต้นทุนการทดสอบประมาณ 45 เท่า
ข้อคิดสำคัญ: เมื่อพิจารณาจากอัตราเงินรางวัลที่เปิดเผยต่อสาธารณะ เราพบว่า ณ เวลาที่ดำเนินการวิจัย ระบบค้นหาช่องโหว่ของเราที่ใช้โมเดลด้านความปลอดภัยไซเบอร์ในปัจจุบันสามารถสร้างผลตอบแทนตามการประเมินได้มากกว่าต้นทุนที่ใช้ไป ผู้ที่ทำหน้าที่รักษาความปลอดภัยจึงควรตรวจสอบซอฟต์แวร์ของตนเชิงรุก เพื่อเพิ่มต้นทุนในการใช้ประโยชน์จากช่องโหว่ให้สูงจนผู้โจมตีไม่คุ้มค่าที่จะลงมือ
ในขั้นตอนการประเมินว่าช่องโหว่สามารถนำไปใช้โจมตีได้จริงหรือไม่ เอเจนต์ ExploitDev จะได้รับรายงานช่องโหว่พร้อมหน้าที่พัฒนาโค้ดโจมตีที่ใช้งานได้จริงอย่างสมบูรณ์ ระบบของเราจะถือว่าการโจมตีผ่านช่องโหว่สำเร็จเมื่อสามารถเข้าถึงเชลล์ด้วยสิทธิ์ระดับ root ได้ ในการทดสอบรอบแรกๆ ครั้งหนึ่ง ระบบรายงานว่าสามารถโจมตีเพื่อยกระดับสิทธิ์ภายในระบบ (LPE) ได้สำเร็จ 200 รายการ แต่หลังจากผู้วิจัยตรวจสอบผลลัพธ์ เราพบว่า 20 รายการในจำนวนนี้ใช้ช่องโหว่ 0-day คนละรายการกับที่ได้รับมอบหมายในการเข้าถึงสิทธิ์ root กรณีนี้แสดงให้เห็นว่า แม้เอเจนต์จะโจมตีได้สำเร็จ ก็ยังจำเป็นต้องตรวจสอบยืนยันว่าการโจมตีนั้นใช้ช่องโหว่ที่ต้องการทดสอบจริงหรือไม่
หลังจากนั้น เราได้กำหนดเงื่อนไขในการทำงานของเอเจนต์ให้เข้มงวดขึ้น พร้อมเพิ่มขั้นตอนการตรวจสอบแยกต่างหาก เพื่อยืนยันว่าโค้ดโจมตีแต่ละรายการที่พัฒนาจนเสร็จสมบูรณ์ใช้ช่องโหว่ตรงตามที่ได้รับมอบหมายจริง
ข้อคิดสำคัญ: ในการวิจัยด้านความปลอดภัยแบบอัตโนมัติ ไม่ควรตรวจสอบเพียงว่าผลลัพธ์ถูกต้องหรือไม่ แต่ต้องตรวจสอบด้วยว่าได้ผลลัพธ์นั้นมาอย่างไร โดยจำเป็นต้องมีมาตรการควบคุม เช่น การแยกสภาพแวดล้อม การเฝ้าติดตามการทำงาน และการตรวจสอบยืนยันโดยอิสระ
ในช่วงแรกของการวิจัย เราได้พิจารณาว่าควรสร้างระบบช่วยจัดการและควบคุมขั้นตอนการทำงานของเอเจนต์ที่ซับซ้อน เพื่อเพิ่มความสามารถด้านความปลอดภัยไซเบอร์หรือไม่ แต่ผลการทดลองชี้ว่าโมเดลที่มีความสามารถสูงขึ้นอาจไม่จำเป็นต้องพึ่งพาระบบช่วยจัดการที่ซับซ้อนหรือคำแนะนำอย่างใกล้ชิดมากเท่าเดิม อีกทั้งประสิทธิภาพที่เพิ่มขึ้นเพียงเล็กน้อยก็ไม่คุ้มกับต้นทุนในการดูแลรักษาระบบ เราจึงตัดสินใจนำระบบช่วยจัดการที่ซับซ้อนดังกล่าวออก
เราได้ทดลองเปรียบเทียบ GPT‑5.5 Cyber และ GPT‑5.6 Cyber โดยพบว่า GPT‑5.5 Cyber ยังเลือกใช้เทคนิคการโจมตีช่องโหว่ของเคอร์เนล Linux ที่มีอยู่แล้วได้ไม่สม่ำเสมอ ทั้งในแง่ของจังหวะและวิธีการนำไปใช้ เราจึงรวบรวมเทคนิค 103 เทคนิคมาจัดให้อยู่ในรูปแบบที่โมเดลเข้าใจและนำไปใช้ได้ง่าย จากนั้นเพิ่มเทคนิคเหล่านี้เข้าไปในสภาพแวดล้อมการทำงานของเอเจนต์ พร้อมให้คำสั่งเอเจนต์นำไปใช้ ผลการทดสอบกับช่องโหว่ที่อาจนำไปใช้โจมตีได้ 63 รายการพบว่า อัตราความสำเร็จเพิ่มขึ้นจาก 76.2% เป็น 88.9%
เมื่อเราทดลองซ้ำด้วย GPT‑5.6 Cyber พบว่าโมเดลสามารถค้นหา เลือก และนำเทคนิคที่เหมาะสมมาใช้ได้ด้วยตนเองดีขึ้น เราจึงนำระบบช่วยจัดการเทคนิคและทักษะเสริมออก ส่งผลให้ GPT‑5.6 Cyber ที่ใช้ระบบช่วยจัดการขั้นตอนการทำงานแบบเรียบง่ายมีประสิทธิภาพสูงกว่า GPT‑5.5 Cyber ที่ต้องพึ่งพาระบบสนับสนุนและคำแนะนำที่ซับซ้อนกว่า อีกทั้งเมื่อเราเพิ่มระบบช่วยจัดการเทคนิคกลับเข้าไปให้ GPT‑5.6 Cyber อัตราความสำเร็จก็เพิ่มขึ้นเพียง 1.5 จุดเปอร์เซ็นต์เท่านั้น
ข้อคิดสำคัญ: ควรประเมินระบบจัดการขั้นตอนการทำงานและเครื่องมือสนับสนุนโมเดลใหม่ทุกครั้งที่ความสามารถของโมเดลพื้นฐานเปลี่ยนแปลงไป เพราะระบบช่วยกำกับการทำงานที่เพิ่มประสิทธิภาพให้โมเดลรุ่นหนึ่งได้อย่างมาก อาจแทบไม่ช่วยให้โมเดลรุ่นที่เก่งกว่าทำงานได้ดีขึ้น จึงควรพิจารณาว่าประสิทธิภาพที่เพิ่มขึ้นนั้นคุ้มกับต้นทุนในการดูแลรักษาระบบหรือไม่
ในช่วงแรก เมื่อเราสั่งให้โมเดลสร้างแพตช์สำหรับแก้ไขช่องโหว่โดยตรง โมเดลสามารถสร้างแพตช์ที่ทำงานได้ถูกต้องและป้องกันการโจมตีตาม PoC ได้ แต่บางครั้งแพตช์เหล่านี้ก็มีปัญหาอื่นตามมา เช่น เขียนโค้ดมากเกินความจำเป็น อาจส่งผลกระทบต่อประสิทธิภาพการทำงานของระบบ ใช้รูปแบบการเขียนโค้ดที่ไม่สอดคล้องกับแนวทางที่กำหนดไว้ หรือไม่ได้ตรวจสอบโค้ดส่วนอื่นที่เกี่ยวข้องว่ามีช่องโหว่ในลักษณะเดียวกันหรือไม่ ทำให้แพตช์แก้ไขปัญหาได้ไม่ครอบคลุม
เมื่อเราเพิ่มคำแนะนำและปรับกระบวนการสร้างแพตช์หลายรอบ คุณภาพของแพตช์ก็ดีขึ้น ผลลัพธ์นี้ชี้ว่า หากมีการตรวจสอบและปรับปรุงอย่างเหมาะสม AI ก็สามารถสร้างแพตช์ที่แก้ไขปัญหาด้านความปลอดภัยได้ถูกต้อง โดยไม่ต้องแก้โค้ดเกินความจำเป็น และยังคงรูปแบบการเขียนโค้ดให้สอดคล้องกับของเดิมได้ เรากำลังศึกษาวิจัยเรื่องนี้อย่างต่อเนื่อง และเราเชื่อว่าโมเดลรุ่นใหม่ในอนาคตจะช่วยให้การสร้างแพตช์ลักษณะนี้ทำได้ง่ายและมีประสิทธิภาพมากขึ้น นอกจากนี้ ในบางกรณี ระบบต้นแบบของเรายังตรวจพบปัญหาในแพตช์ที่ผู้เชี่ยวชาญเขียนขึ้น ซึ่งปัญหาเหล่านั้นได้รับการแก้ไขก่อนนำแพตช์ไปรวมกับโค้ดของโครงการ
ข้อคิดสำคัญ: แม้โมเดลจะช่วยให้สร้างแพตช์ได้เร็วขึ้น แต่ก็อาจต้องปรับปรุงทักษะเสริมและเครื่องมือที่ช่วยให้โมเดลสร้างแพตช์หลายครั้ง เพื่อให้แพตช์ที่ได้ตรงตามข้อกำหนดทั้งด้านการทำงานและด้านอื่นๆ อย่างน่าเชื่อถือ เรายังแนะนำให้นำโมเดลมาตรวจสอบแพตช์ที่มนุษย์หรือ AI เขียนขึ้น โดยลองพิจารณาว่าผู้โจมตีอาจหาทางเจาะผ่านแพตช์เหล่านั้นได้อย่างไร วิธีนี้ช่วยค้นพบปัญหา เช่น แพตช์ที่ยังถูกหลบเลี่ยงได้ หรือการแก้ไขที่มองข้ามช่องทางโจมตีและรูปแบบอื่นของช่องโหว่
ระหว่างการทดสอบกับ kernelCTF ระบบต้นแบบของเราไม่ได้พบเพียงช่องโหว่ 0-day ในเคอร์เนล Linux ที่นำไปสร้างโค้ดโจมตีได้ 21 รายการเท่านั้น แต่ยังค้นพบและใช้ประโยชน์จากช่องโหว่ใน QEMU TCG เพื่อโจมตีได้อีกด้วย เรื่องนี้เริ่มจากเอเจนต์วิเคราะห์ที่ได้รับมอบหมายให้ตรวจสอบโค้ดส่วนรับคำสั่ง system call ขณะเขียนโปรแกรมเพื่อทดสอบการเปลี่ยนระดับสิทธิ์ เอเจนต์พบว่าเคอร์เนลหยุดทำงานผิดปกติอย่างไม่คาดคิด จึงตรวจสอบต่อจนพบว่าต้นตอของปัญหาอยู่ที่ QEMU TCG แม้จะไม่มีซอร์สโค้ดของ QEMU ให้ตรวจสอบก็ตาม เอเจนต์จึงบันทึกช่องโหว่นี้ไว้ในรายงาน ก่อนที่เอเจนต์ ExploitDev จะพัฒนาโค้ดโจมตี LPE ได้สำเร็จในเวลาต่อมา เมื่อเราตรวจสอบโค้ดโจมตีด้วยตนเอง จึงพบว่าปัญหานี้เป็นช่องโหว่ของ QEMU และยืนยันได้ว่ามีการแก้ไขในโค้ดต้นทางแล้ว แต่ QEMU รุ่นที่ใช้ในการทดลองยังไม่มีการแก้ไขดังกล่าว
ข้อคิดสำคัญ: แม้แต่ระบบที่ใช้ทดสอบด้านความปลอดภัยเองก็อาจมีช่องโหว่ที่โมเดล AI ระดับแนวหน้าค้นพบได้ เราจึงแนะนำให้ตรวจสอบทุกส่วนของระบบทดสอบให้ปลอดภัยก่อนเริ่มงานวิจัยที่เกี่ยวข้องกับการโจมตีผ่านช่องโหว่ เราเองก็ได้ตรวจสอบระบบที่ใช้งานล่วงหน้าอย่างจริงจัง และดำเนินการเปิดเผยพร้อมแก้ไขช่องโหว่จำนวนมากใน Kata, Moby/Docker, gVisor รวมถึงโครงการอื่นๆ
เป้าหมายของเราคือการนำความสามารถของโมเดลที่พัฒนาขึ้นอย่างต่อเนื่องมาใช้ให้เกิดประโยชน์ในระยะยาวต่อผู้ที่ทำหน้าที่รักษาความปลอดภัยบนอินเทอร์เน็ต งานวิจัยนี้แสดงให้เห็นว่าโมเดล AI ระดับแนวหน้าที่มีความสามารถด้านความปลอดภัยไซเบอร์สูงขึ้น สามารถนำมาใช้ค้นหาช่องโหว่ในซอฟต์แวร์ที่มีความซับซ้อนอย่างเคอร์เนลของ Linux ได้อย่างมีประสิทธิภาพ การเสริมความปลอดภัยให้กับซอฟต์แวร์สำคัญอย่าง Linux และโครงการโอเพนซอร์สอื่นๆ จึงสามารถช่วยปกป้องระบบและผู้ใช้งานอีกจำนวนมากที่ต้องพึ่งพาซอฟต์แวร์เหล่านี้
เราตั้งใจต่อยอดงานวิจัยนี้ไปยังโครงการซอฟต์แวร์สำคัญอื่นๆ ผ่าน Patch the Planet ซึ่งเป็นโครงการริเริ่มภายใต้ Daybreak พร้อมทั้งร่วมมือกับผู้ดูแลโครงการและพันธมิตรด้านความปลอดภัยเพื่อพัฒนาระบบแก้ไขช่องโหว่อัตโนมัติที่เชื่อถือได้ เป้าหมายของเราคือการลดโอกาสในการโจมตีอย่างต่อเนื่อง และทำให้ผู้โจมตีต้องใช้ทรัพยากรมากขึ้นในการค้นหาและใช้ประโยชน์จากช่องโหว่ จนในที่สุดการโจมตีก็ไม่คุ้มกับผลประโยชน์ที่คาดว่าจะได้รับ
โมเดลแต่ละรุ่นควรช่วยให้เราพัฒนาซอฟต์แวร์ที่โมเดลรุ่นถัดไปเจาะระบบได้ยากยิ่งขึ้น เราจะเดินหน้าสร้างอินเทอร์เน็ตที่ปลอดภัยและเปิดโอกาสให้ทุกคนสร้างสรรค์สิ่งต่างๆ ได้อย่างอิสระและมีความสุขต่อไป
