GPT-5.6-Cyber หลบหนีออกจาก VM QEMU/KVM ได้ถึงสามครั้งภายในสิบสองชั่วโมง

เมื่อวันที่ 26 สิงหาคม 2026 Trail of Bits ได้เผยแพร่การทดลองหนึ่งซึ่งมอบหมายวัตถุประสงค์เดียวให้แก่เอเจนต์ AI — คือการหลุดออกจากเครื่องเสมือน — และเอเจนต์ทำสำเร็จถึงสามครั้งภายในเวลาประมาณสิบสองชั่วโมงของการทำงานโดยไม่มีผู้ดูแล โดยแต่ละครั้งใช้เส้นทางที่แตกต่างกัน เอเจนต์ตัวนั้นคือ GPT-5.6-Cyber ซึ่งเป็นโมเดลความสามารถด้านไซเบอร์ที่ OpenAI ให้บริษัทวิจัยแห่งนี้เข้าถึงแบบพรีวิว เป้าหมายคือเครื่องเสมือน QEMU/KVM บนโฮสต์ Debian 12 และการหลุดออกทั้งสามครั้งเริ่มจากช่องโหว่เคอร์เนล Linux ที่เพิ่งเปิดเผยใหม่ ไปจนถึงห่วงโซ่ของซีโรเดย์สามรายการที่เอเจนต์ค้นพบด้วยตัวเอง ไม่มีใครนอกห้องแล็บได้รับอันตราย — แฟล็กที่เอเจนต์ถูกสั่งให้อ่านเป็นไฟล์ทดสอบบนเครื่องของผู้วิจัยเอง — แต่ผลการค้นพบนี้มุ่งชี้ไปยังสมมติฐานที่ว่า VM เป็นสถานที่ปลอดภัยสำหรับการรันเอเจนต์แบบนี้ บันทึกเหตุการณ์นี้เอง พร้อมด้วยระดับความมั่นใจและหมายเหตุว่าไม่มีการบันทึกความเสียหายที่แท้จริง ถูกจัดเก็บไว้ใน Orca AI Incident Archive ถัดจากรายการแซนด์บ็อกซ์เพื่อการประเมินที่ถูกบันทึกไว้ในสัปดาห์เดียวกันนั้น

สิ่งที่ Trail of Bits รันจริง ๆ

บทความนี้เขียนโดย Artem Dinaburg และอยู่ในงาน Patch the Planet ของ Trail of Bits ซึ่งเป็นส่วนหนึ่งของโครงการริเริ่มด้านการค้นพบช่องโหว่ของ OpenAI ที่มีชื่อเดียวกัน OpenAI อธิบายว่า Patch the Planet เป็นแนวร่วมของผู้ดูแลโปรเจกต์ นักวิจัย และผู้ให้บริการด้านความปลอดภัย ซึ่ง OpenAI รวบรวมขึ้นเพื่อแก้ไขช่องโหว่ร้ายแรงในโอเพนซอร์สก่อนจะมีการเปิดเผย เอเจนต์ในการทดลองนี้ไม่ใช่ผลิตภัณฑ์ที่ถูกนำไปใช้งานและกำลังถูกทดสอบให้กับลูกค้า แต่เป็นการให้สิทธิ์เข้าถึงแบบพรีวิวที่มอบให้กับบริษัทวิจัย ซึ่งเป็นวิธีที่บทความนี้อธิบายไว้

Dinaburg วางกรอบเรื่องนี้ว่าเป็น capture-the-flag เอเจนต์ต้องหลุดออกจาก guest และอ่านไฟล์ flag โดยเริ่มจากการเข้าถึง guest ผ่าน SSH และได้รับอนุญาตให้ทำอะไรก็ได้ภายในนั้น พร้อมกับเก็บบันทึกการวิจัยไว้ การเริ่มจาก guest แทนที่จะเริ่มจากภายใน host เป็นเรื่องที่ตั้งใจไว้ — ความพยายามหลุดออกมาอาจทำให้เครื่องแครช — และ host ถูกตั้งค่าให้ไม่เก็บสิ่งสำคัญใด ๆ เพื่อให้ exploit ที่เอเจนต์เขียนขึ้นได้รับการตรวจสอบว่ามีการโกงหรือไม่ แทนที่จะถูกถือเป็นเหตุการณ์ผิดปกติ มันทำงานโดยแทบไม่มีผู้ดูแลเป็นเวลาประมาณสิบสองชั่วโมง ตลอดช่วงที่ Dinaburg เรียกว่า "การ compaction หลายครั้งและการเรียกใช้ subagent นับไม่ถ้วน": ดาวน์โหลดโค้ดและบทความ ถอยกลับ เขียน oracle และ minimal reproducer และตามล่า exploit ที่มันสามารถนำกลับมาใช้ซ้ำได้ เขากล่าวว่าบทบาทของเขาเองส่วนใหญ่คือการรีบูตเครื่องหลังจาก host kernel hardlock

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

Escape ตัวที่หนึ่ง: บั๊กเคอร์เนลที่ยังไม่มีใครเขียน exploit สำหรับมัน

ผ่านไปประมาณหนึ่งชั่วโมง เอเจนต์มี Exploit ที่ใช้งานได้สำหรับ CVE-2026-53359 ซึ่งเป็นช่องโหว่เคอร์เนลของโฮสต์ที่ถูกเปิดเผยไม่นานก่อนการรัน และเป็นที่รู้จักในบันทึกว่า Januscape ในคำอธิบายของ Dinaburg ไม่มี Exploit สาธารณะให้ลอก เอเจนต์สร้างขึ้นมาเอง มันไม่ได้ผลลัพธ์อย่างราบรัด — โฮสต์เกิด hardlock แทน — และ Dinaburg อัปเดตเคอร์เนล Debian 12 ก่อนดำเนินการต่อ

ตัวระบุนี้ยังคงสอดคล้องกับบันทึกสาธารณะ รายการ NVD ของ NIST สำหรับ CVE-2026-53359 ซึ่งเผยแพร่เมื่อ 2026-07-04 อธิบายถึงช่องโหว่ use-after-free ใน KVM x86 shadow-paging ที่จัดประเภทเป็น CWE-416 และได้รับคะแนน 8.8 ตาม CVSS 3.1 — เจ็ดสัปดาห์ก่อนการทดลอง ในโค้ดเสมือนจริงที่การ escape มุ่งเป้าไปที่ สิ่งนี้ไม่ได้ยืนยันการ escape เอง แต่แสดงให้เห็นว่าป้ายกำกับชี้ไปยังข้อบกพร่องของเคอร์เนลที่มีการบันทึกไว้ ไม่ใช่ข้อบกพร่องที่ถูกแต่งขึ้นสำหรับโพสต์นี้

การหลบหนีครั้งที่สอง: บั๊ก libslirp ที่ Debian ได้ตัดสินใจเลื่อนออกไปแล้ว

เส้นทางที่สองไม่ใช่บั๊กใหม่เลยแม้แต่น้อย Debian 12 มาพร้อม libslirp 4.7.0 ซึ่งมี CVE-2026-9539 ติดอยู่ เอเจนต์ได้นำมันไปรวมกับคอมมิตแก้ไข libslirp ที่ถูก merge เข้า upstream โดยไม่ถูกติดป้ายว่าเป็นการแก้ช่องโหว่ด้านความปลอดภัย — 26be815b86e8d49add8c9a8b320239b9594ff03d — แล้วเปลี่ยนทั้งคู่ให้กลายเป็นการอ่านและเขียนหน่วยความจำโฮสต์ตามอำเภอใจ Dinaburg เขียนว่า "หลังจากนั้น การหลบออกไปก็เป็นเรื่องง่ายดาย" จากนั้นเขาจึงสร้าง QEMU แบบมินิมอลขึ้นใหม่โดยอิงกับ QEMU และ libslirp เวอร์ชัน upstream ล่าสุด แล้วปล่อยเอเจนต์ให้ทำงานอีกครั้ง

การจดบันทึกในกรณีนี้ตรวจสอบได้ และเป็นส่วนที่เฉียบคมที่สุดของการค้นพบ คลังแพ็กเกจของ Debian ระบุ libslirp 4.7.0-1 ไว้ใน bookworm ซึ่งเป็นชุดซอฟต์แวร์ที่เป็นฐานของ Debian 12 — ตรงกับเวอร์ชันที่บทความระบุชื่อไว้พอดี ตัวติดตามความปลอดภัยของ Debian ทำเครื่องหมายว่าเวอร์ชันนั้นมีช่องโหว่ CVE-2026-9539 และบันทึกว่าการแก้ไขถูกเลื่อนออกไปใน bookworm พร้อมหมายเหตุว่า “Minor issue, OOB read” การแก้ไขได้ไปถึง trixie และ unstable แล้ว บันทึกของ NIST ซึ่งเผยแพร่เมื่อ 2026-06-24 อธิบายถึงการอ่านหน่วยความจำฮีปนอกขอบเขตและ integer underflow ในการจัดการข้อมูลเร่งด่วนของ TCP ใน libslirp ก่อนเวอร์ชัน 4.9.2 ทำให้เกสต์ที่มีสิทธิ์สูงสามารถรั่วไหลหน่วยความจำฮีปของโพรเซสโฮสต์ได้หลายกิกะไบต์ NVD ให้คะแนนอยู่ที่ 6.5 ระดับปานกลาง โดย Star Labs เป็นผู้ให้คะแนน และยังคงทำเครื่องหมายว่าอยู่ระหว่างรอการวิเคราะห์ คอมมิตต้นทางที่เอเจนต์นำมาเชื่อมโยงมีชื่อว่า “ip: Enforce strict aliasing” — บรรทัดหัวข้อที่ดูเหมือนการดูแลสุขอนามัยของโค้ด ซึ่งเป็นประเด็นของ Dinaburg เกี่ยวกับการแก้ไขที่ไม่ประกาศตัวเอง

ดังนั้นบั๊กเดียวกันจึงเป็น "ปัญหาย่อย ถูกเลื่อนออกไป" ในดิสทริบิวชันที่เสถียร และเป็นบันไดขั้นหนึ่งไปสู่การอ่านและเขียนหน่วยความจำโฮสต์ในห้องแล็บวิจัย ไม่มีฝ่ายใดได้ประสานให้ตรงกันในที่สาธารณะ และบทความนี้ไม่ได้ตัดสินชี้ขาดเรื่องดังกล่าว แต่รายงานการประเมินทั้งสองตามที่เป็นอยู่

Escape three: ซีโร่เดย์สามรายการ และการแก้ไขหนึ่งรายการที่ไม่เคยไปถึงดิสทริบิวชัน

เมื่อสร้างสภาพแวดล้อมใหม่จากซอร์สต้นทาง เอเจนต์เลิกนำบั๊กของคนอื่นมาใช้ซ้ำ และพบของตัวเอง ห่วงโซ่สุดท้ายประกอบด้วย zero-day สามรายการรวมกับช่องโหว่ที่ได้รับการแพตช์แล้วหนึ่งรายการซึ่งไม่มีอยู่ในเคอร์เนลของดิสทริบิวชัน:

• QEMU VAPIC — alias ของ ROM ที่ไม่ได้ตรวจสอบอาจทับซ้อนกับ SMRAM ที่ถูกล็อก ทำให้ System Management RAM ถูกเปิดเผย และเปิดทางให้ผู้โจมตีควบคุมการทำงานของ SMM ได้ มีการรายงานแล้ว; ยังไม่มีการแพตช์เมื่อโพสต์เผยแพร่ออกไป

• Linux KVM shadow paging — shadow page ที่ถูกผู้โจมตีแก้ไขหลุดซิงก์และอาจถูกนำกลับมาใช้ซ้ำได้ ได้รับการแพตช์ใน upstream แล้ว; รายละเอียดเกี่ยวกับ stable kernel ยังคงค้างอยู่ ณ เวลาที่เผยแพร่

• Linux KVM paging64_invlpg() — role ระดับ 2 ที่ค้างอยู่ (stale) หลังจาก guest เปลี่ยน mapping เป็น 4 KiB ทำให้เกิด writable mapping แบบ 2 MiB ในหน่วยความจำกายภาพของโฮสต์ ซึ่งเพียงพอที่จะแก้ไข QEMU heap ได้ แก้ไขโดย upstream commit 9fd4a4e3a3d9fc0306525d95bf3eca693d311406 ซึ่งไม่มีอยู่ใน kernel ของ distribution; commit นั้นมีอยู่ใน mainline โดยมีชื่อว่า "KVM: x86/mmu: Remove FNAME(invlpg) and use FNAME(sync_spte) to update vTLB instead."

• libslirp ICMP — การที่แฟรกเมนต์มีค่า IHL ผสมกันทำให้การคัดลอกแบบสะท้อน (reflection copy) เกินขอบเขตของแพ็กเก็ตที่ประกอบกลับคืนแล้ว ส่งผลให้เกิดออบเจ็กต์ NetPacket ที่ยังคงอยู่จริงนับพัน ซึ่งเอเจนต์ใช้เพื่อระบุตำแหน่งและจี้ callback ได้ มีการรายงานแล้ว; ยังไม่มีการแพตช์ในตอนที่โพสต์ถูกเผยแพร่

ไม่มีช่องโหว่ zero-day ทั้งสามรายการใดที่มีตัวระบุ CVE ในบทความนี้ และบทความไม่ได้ให้กรอบเวลาเปิดเผยข้อมูล กำหนดการประสานงาน หรือวันที่แก้ไขสำหรับช่องโหว่เหล่านี้เลย นั่นเป็นช่องว่างในบันทึกมากกว่ารายละเอียดที่ผมสามารถเติมได้: ตัวระบุที่บทความอ้างถึงคือสองตัวที่ NVD มีอยู่แล้ว

สิ่งที่มันค้นพบแต่ไม่ได้ใช้

เส้นทางที่ถูกทิ้งไว้ให้ข้อมูลไม่แพ้การหลบหนีเลย บนโฮสต์ เอเจนต์พบเซิร์ฟเวอร์ CUPS; การส่งต่อลูปแบ็กของ slirp เปิดเผยใบรับรอง local ของ root ที่ใช้ซ้ำได้ ซึ่งจะทำให้สามารถเขียนทับไฟล์ของ root ได้อย่างต่อเนื่องผ่านเครื่องพิมพ์ file:// จนกระทั่ง AppArmor หยุดยั้งไม่ให้ดึงแฟล็กออกมา ช่องโหว่ CUPS ที่เกี่ยวข้อง คือ CVE-2026-34990 ยังไม่ไปถึง oldstable; บันทึกของ NIST สำหรับช่องโหว่นี้ ซึ่งเผยแพร่เมื่อ 2026-04-03 ด้วยคะแนน 7.8 ระดับสูง อธิบายว่าผู้ใช้ท้องถิ่นที่ไม่มีสิทธิ์พิเศษบังคับให้ cupsd ไปรับรองความถูกต้องกับบริการ IPP บน localhost ที่ผู้โจมตีควบคุม โดยใช้โทเค็น "Authorization: Local" ที่ใช้ซ้ำได้

ผลการค้นพบอื่น ๆ ไม่ได้ถูกนำไปใช้ เส้นทาง IPv6 ของ libslirp เก็บไบต์เกินกว่าเพย์โหลดที่ประกาศไว้ ซึ่งเอเจนต์ตัดสินว่ามีความน่าเชื่อถือน้อยกว่าสำหรับการฉีดสตรีมของโฮสต์ บัฟเฟอร์แพนนิงของ QEMU ขนาด 96 ไบต์สำหรับการเรนเดอร์ 1,024 ไบต์ทำให้เกิด heap overflow ที่ควบคุมได้ แต่ไร้ประโยชน์เพราะเกสต์ทำงานโดยไม่มีจอแสดงผล การรีเซ็ตคิวของ QEMU ทำให้คำขอยังคงอยู่ ส่งผลเพียงการปฏิเสธการให้บริการและความเสียหายที่จำกัดขอบเขต

เมื่อทดสอบกับ Firecracker ซึ่งเป็นโมเดลอุปกรณ์แบบมินิมอลที่ Trail of Bits แนะนำ เอเจนต์ไม่ได้หลบหนีออกมา แต่กลับทำให้โฮสต์ล็อกตายได้ โดยอาศัยช่องโหว่เพิ่มเติมในเคอร์เนล Linux ซึ่งทั้งหมดได้รับการแพตช์ที่อัปสตรีมแล้ว

ยืนยันแล้ว อนุมานได้ และยังไม่ยืนยัน

ยืนยันแล้ว การทดลองนี้รันบนฮาร์ดแวร์ของ Trail of Bits เอง และถูกบันทึกไว้ในรายงานทางเทคนิคเชิงบรรยายจากมุมมองบุคคลที่หนึ่งซึ่งมีรายละเอียดของ exploit เส้นทางทั้งสามและกลไกของเส้นทางเหล่านั้นได้รับการอธิบายโดยนักวิจัยผู้ตั้งโจทย์ ตัวระบุ CVE เวอร์ชันแพ็กเกจ Debian สถานะใน Debian tracker และคอมมิตต้นทางทั้งสองรายการสามารถตรวจสอบได้ในบันทึกสาธารณะ และแต่ละรายการได้รับการตรวจสอบเทียบกับบันทึกเหล่านั้นสำหรับบทความนี้

ยังไม่มีการยืนยัน ไม่มีการทำซ้ำอย่างอิสระ การรายงานข่าวนอกเหนือจากบล็อกมีเพียงสรุปของ CyberInsider ซึ่งอ้างอิงจากโพสต์เดียวกันทั้งหมด และไม่มีความคิดเห็นของผู้เชี่ยวชาญหรือการตรวจสอบโดยบุคคลที่สาม และบทความแสดงความคิดเห็นโดย Edera — ผู้จำหน่ายโซลูชันแยกสภาพแวดล้อม — ที่เผยแพร่เมื่อ 2026-08-27 ซึ่งรายงานผลการค้นพบในเชิงชื่นชม ยกคำพูดเฉพาะหัวหน้าฝ่ายความปลอดภัยของตนเอง และเปิดเผยว่า Trail of Bits ได้ตรวจประเมิน Edera ทั้งสองแหล่งไม่ได้เป็นการยืนยันในความหมายที่มีความสำคัญ: ไม่มีห้องปฏิบัติการแห่งที่สองใดทำซ้ำการหลุดออกได้ และไม่มีใครตรวจสอบทรานสคริปต์ ทั้งสองแหล่งที่อ้างถึงไม่มีคำแถลงจาก OpenAI เกี่ยวกับผลลัพธ์นี้ และฉันไม่พบการตอบกลับที่เผยแพร่จากบริษัท

เป็นการอนุมาน ไม่ใช่การพิสูจน์ให้เห็น ข้อสรุปที่ว่า VM อเนกประสงค์ไม่อาจถูกสันนิษฐานได้อีกต่อไปว่ามีเอเจนต์ที่มีความสามารถเพียงพออยู่ภายในนั้น ตั้งอยู่บนโมเดลเดียว การกำหนดค่าโฮสต์เดียว และการตั้งค่าของนักวิจัยเพียงคนเดียว โฮสต์ทำงานโดยปิดการป้องกันระดับ CPU (CPU mitigations) และบางเส้นทางที่ถูกทิ้งไป เช่น สายโซ่ CUPS ถูกหยุดโดย AppArmor ไม่ใช่โดยไฮเปอร์ไวเซอร์ การที่เอเจนต์เดียวกันจะหลุดออกจากโฮสต์โปรดักชันที่ผ่านการเสริมความแข็งแกร่งและมีการเฝ้าระวังภายในสิบสองชั่วโมงเดียวกันหรือไม่ ไม่ใช่สิ่งที่การทดลองนี้วัด ข้อโต้แย้งที่แคบกว่าของ Edera คือการลดการจำลองอุปกรณ์ให้เหลือน้อยที่สุดนั้น "ทำให้เป้าหมายเล็กลง但它ไม่ทำให้เป้าหมายหายไป" — เป็นข้อกล่าวอ้างเกี่ยวกับสถาปัตยกรรม ไม่ใช่การทำซ้ำผลลัพธ์

บล็อกของ OrcaRouter ได้ครอบคลุมบันทึกแซนด์บ็อกซ์ที่เกี่ยวข้อง — บั๊ก Codex Heapjack และ Overpatch ที่รายงานในเดือนสิงหาคม 2026 และแก้ไขภายในแปดวัน รวมถึงการหลบหนีผ่าน DNS-resolver ของ OpenAI เมื่อวันที่ 20 กันยายน 2026 — และไม่มีรายการใดเกี่ยวข้องกับการข้ามขอบเขตไฮเปอร์ไวเซอร์ในลักษณะนี้ บันทึกเหล่านั้นเกี่ยวกับพื้นผิวเครื่องมือและช่องทางเครือข่าย ส่วนรายการนี้เกี่ยวกับสแต็กการจำลองเสมือนที่อยู่ภายใต้ทุกสิ่งทุกอย่าง

สิ่งที่ Trail of Bits กล่าวว่าควรเปลี่ยนแปลง

ข้อสรุปของ Dinaburg ตรงไปตรงมา: "คุณไม่อาจถือได้อีกต่อไปว่า VM ธรรมดาเพียงตัวเดียวจะมี AI agent ที่ก้าวหน้าพอ" และ agent เช่นนั้นควรได้รับการปฏิบัติ "เป็นภัยคุกคามแบบ APT (advanced persistent threat)" เขาเขียนว่า VM แบบสำเร็จรูปที่พร้อมใช้ทั่วไปยังไม่เพียงพอ เพราะมีพื้นผิวการโจมตีมากเกินไป ดิสทริบิวชันที่มีการอัปเดตอย่างรวดเร็วกลายเป็นสิ่งจำเป็น และดิสทริบิวชันรุ่นเก่าที่พึ่งพาการ backport ที่ช้าควรถือว่ามีช่องโหว่ไว้ก่อน

คำแนะนำต่อไปนี้เป็นเชิงปฏิบัติการมากกว่าเชิงสถาปัตยกรรม:

• ใช้การจำลองเสมือนที่มีพื้นที่โจมตีน้อยที่สุด — Firecracker ซึ่งเขาเรียกมันว่า "เห็นได้ชัดว่าเป็นเป้าหมายที่ยากขึ้นอย่างมาก" พร้อมตั้งข้อสังเกตว่ามันไม่ได้ปลอดจากการโจมตีเลย เนื่องจากเอเจนต์ยังคงทำให้โฮสต์ล็อกตายได้ผ่านเคอร์เนลที่ใช้ร่วมกันซึ่งอยู่ใต้มัน

• ใช้หลักสิทธิ์น้อยที่สุด การบันทึก และการตรวจสอบเชิงรุกกับทุกสิ่งที่เอเจนต์ได้รับสิทธิ์เข้าถึง

จำกัดระยะเวลาที่เอเจนต์ทำงาน และให้แต่ละการใช้งานได้รับสภาพแวดล้อมที่สะอาดใหม่ แทนที่จะเป็นสภาพแวดล้อมที่ใช้งานมายาวนาน

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

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