AI ของ OpenAI เจอช่องโหว่ Linux ที่ยกสิทธิ์เป็น root ได้ 948 จุดในรอบเดียว ย้ำต้องอัปเดตเคอร์เนลให้ไว
OpenAI เผยระบบ AI อัตโนมัติสแกนเคอร์เนล Linux แล้วสร้างช่องทางเจาะสิทธิ์ root ที่ใช้ได้จริง 948 ช่องโหว่ ส่งรายงานพร้อมแพตช์ให้ผู้ดูแลแล้ว และเตือนว่าเครื่องที่ไม่อัปเดตเสี่ยงสูง
การทดลองนี้รันช่วงกลางเดือนตุลาคม 2569 บนเคอร์เนล Linux รุ่นล่าสุด โดยใช้โมเดลด้านไซเบอร์รุ่นใหม่ที่ OpenAI ยังไม่เปิดตัว เอเจนต์ AI หลายตัวแบ่งงานกันเลือกส่วนของโค้ดที่ผู้ใช้สิทธิ์ต่ำเข้าถึงได้ราว 2.8 ล้านบรรทัด หรือประมาณ 7% ของเคอร์เนลทั้งหมด แล้วหาจุดน่าสงสัยได้ 2,308 จุดภายใน 12 ชั่วโมง จากนั้นลองทำให้เกิดขึ้นจริงในเครื่องเสมือนที่แยกไว้ ยืนยันได้ 1,724 ช่องโหว่
ขั้นต่อมา AI ลองเขียนโค้ดเจาะบนระบบเดสก์ท็อป Linux ทั่วไปที่เปิดระบบป้องกันมาตรฐานไว้ครบ ได้โค้ดเจาะที่ให้ผู้ใช้ธรรมดากลายเป็น root ได้จริง 1,169 ชุด เมื่อจัดกลุ่มตัวที่ซ้ำกันแล้วเหลือ 948 ช่องโหว่ไม่ซ้ำ ระบบยังเขียนแพตช์แก้ให้ทุกจุด และมีนักวิจัยมนุษย์ตรวจก่อนส่งให้ผู้ดูแล Linux ค่าใช้จ่ายทั้งรอบอยู่ที่ราว 1.21 ล้านดอลลาร์สหรัฐ หรือเฉลี่ยราว 1,279 ดอลลาร์ต่อช่องโหว่ OpenAI บอกด้วยว่า AI ใช้เทคนิคเจาะแบบใหม่อย่างน้อย 10 แบบ ซึ่งจะไม่เปิดเผยรายละเอียดด้วยเหตุผลด้านความปลอดภัย
ตอนการสแกนจบ มีช่องโหว่ 61 จุดได้รับการแก้ในเคอร์เนลต้นทางแล้ว 43 จุดมีแพตช์รอเข้า และอีก 299 จุดอยู่ระหว่างรายงานและพูดคุยกันในที่สาธารณะ OpenAI บอกว่าส่งรายงานพร้อมแพตช์ไปแล้วหลายร้อยรายการ โดยเริ่มจากตัวที่ร้ายแรงที่สุดตามคำแนะนำของชุมชน Linux ส่วนที่เหลือจะทยอยส่งต่อ ยังไม่มีรายงานว่ามีใครนำช่องโหว่ชุดนี้ไปโจมตีจริง
ช่องโหว่ทั้งหมดเป็นแบบยกระดับสิทธิ์ในเครื่อง คือผู้โจมตีต้องเข้าเครื่องได้ก่อนในฐานะผู้ใช้ธรรมดา เช่น ผ่านบัญชีที่รหัสหลุดหรือเว็บแอปที่ถูกเจาะ แล้วจึงใช้ช่องโหว่ยึดเครื่องทั้งเครื่อง OpenAI เตือนว่าช่วงนี้บัญชีสิทธิ์ต่ำบนเครื่องที่ไม่ได้อัปเดตแพตช์ล่าสุด ควรถือว่าเท่ากับสิทธิ์ root สำหรับผู้โจมตีที่มีทรัพยากรมาก ข่าวนี้กระทบเซิร์ฟเวอร์ Linux คลาวด์ และอุปกรณ์ที่ใช้เคอร์เนล Linux ซึ่งองค์กรไทยใช้กันมาก
ควรทำอะไร
- ตั้งรอบอัปเดตเคอร์เนลของเซิร์ฟเวอร์ Linux ให้ถี่ขึ้น และรีบูตเข้าเคอร์เนลใหม่ทุกครั้งหลังติดตั้ง
- ลดจำนวนบัญชีผู้ใช้บนเซิร์ฟเวอร์ เปิด MFA สำหรับการเข้าระบบ และอัปเดตเว็บแอปที่อาจเป็นทางเข้าแรก
- จำกัด unprivileged user namespaces ถ้าระบบไม่จำเป็นต้องใช้ และพิจารณาแยกงานเสี่ยงไว้ในแซนด์บ็อกซ์ เช่น gVisor หรือ Firecracker
- ติดตามประกาศความปลอดภัยของดิสโทรที่ใช้ (Ubuntu, Debian, RHEL) เพราะแพตช์จากชุดนี้จะทยอยออกมาต่อเนื่อง