- พบวิธีการทำงานของ OpenAI Code Execution โดยบังเอิญ
- อธิบายวิธีที่ค้นพบ กลยุทธ์ prompt injection วิธีการทำงานอย่างละเอียด และแนวทาง reverse engineering ที่ทำให้สามารถรัน C + JavaScript ได้
กระบวนการค้นพบ
- ระหว่างดีบักโค้ดจัดสรรพอร์ต ได้ขอคำสั่ง CLI สำหรับตรวจสอบสถานะพอร์ตจาก ChatGPT แต่แทนที่ ChatGPT จะตอบ กลับนำไป รันบนเครื่องภายใน
- หลังส่งคำขอ handshake หลายครั้ง ก็ได้รับการตอบกลับจาก localhost:8080/openapi.json → จึงเข้าถึงสเปก OpenAPI ภายในได้สำเร็จ
- แต่สเปก OpenAPI ที่สร้างจากบริการ FastAPI มีเอกสารไม่เพียงพอ จึงใช้งานได้ไม่มาก
การสำรวจพอร์ตเพิ่มเติม
- เพื่อหาหน้าที่ของพอร์ตอื่น ๆ จึงให้ AI ลองทำ handshake กับ HTTP, TCP, UDP, MySQL, Postgres
- @dexhorthy พบว่ามีการตอบกลับต่อสัญญาณ ZeroMQ
- จึงพบว่าไม่ใช่ message queue แต่เป็น Jupyter Kernel (สภาพแวดล้อมการรันที่อิงกับ ZeroMQ)
การเข้าถึงระบบไฟล์
- ขอให้แสดงรายการไฟล์ทั้งหมดบนเซิร์ฟเวอร์ แต่ถูกปฏิเสธ
- หลังอัปโหลดไฟล์แล้ว จึงสำรวจไดเรกทอรีที่อัปโหลดและไดเรกทอรีแม่
- สุดท้ายพบไดเรกทอรี .openai_internal
- เซิร์ฟเวอร์จริงกำลังทำงานอยู่ในโมดูล user_machine
- ให้ AI แสดงชื่อไฟล์และเนื้อหาไฟล์ออกมาเป็น pandas dataframe → กู้ซอร์สโค้ดกลับมาได้สำเร็จ
ทำความเข้าใจกับสภาพแวดล้อม
- ตรวจสอบตัวแปรสภาพแวดล้อมที่รันอยู่บน Kubernetes
- ไม่ได้ใช้ Docker หรือ Firecracker แต่ใช้ gVisor เพื่อจำลอง system call และป้องกัน sandbox
- บล็อกเครือข่ายทั้งหมด ยกเว้นการเรียก localhost (ไม่สามารถใช้ DNS หรือเข้าถึงเว็บไซต์ภายนอกได้)
- เวอร์ชัน Linux kernel เป็น เวอร์ชันปี 2016 ซึ่งเก่ามาก
โครงสร้างแซนด์บ็อกซ์
- เมื่อถาม AI ว่าตัวเองรันอยู่ที่ไหน ก็ยืนยันว่ารันอยู่ใน ศูนย์ข้อมูล Azure
- รันบน Azure Kubernetes และใช้ gVisor เพื่อแยกโปรเซส
- คอนเทนเนอร์ใช้ tini เป็น init process
- รันโค้ดใน Python Jupyter Kernel → ส่งผลลัพธ์ออกไปยัง UI ผ่าน OpenAI API
User Machine (สภาพแวดล้อมรันโค้ด)
- ใช้ Python Jupyter Kernel
- เวลารันสูงสุดโดยค่าเริ่มต้นคือ 30 วินาที (แก้ไขได้ผ่าน API)
- ภายใน sandbox สามารถรันหลายเคอร์เนลพร้อมกันได้
- ขนาดไฟล์อัปโหลดสูงสุด: 1GB
ความปลอดภัย
- ตัดการเชื่อมต่อกับเครือข่ายภายนอกทั้งหมด
- บล็อกการเข้าถึงไฟล์ระบบ และไม่พบช่องโหว่ที่เปิดเผยอย่างพอร์ตเครือข่ายภายใน
- ระบบความปลอดภัยของ OpenAI แข็งแกร่งมาก และไม่สามารถรั่วไหลข้อมูลได้ยกเว้นผ่านช่องทาง RPC
การรัน C และ JavaScript
- พบว่า AI มีไบนารี
gcc อยู่ภายใน
- เขียนโปรแกรม C แบบง่าย → คอมไพล์ → รันได้สำเร็จ
- หลังอัปโหลด Duktape (รันไทม์ JavaScript ขนาดเล็ก) ก็สามารถคอมไพล์ไฟล์ C ได้สำเร็จ
- Python คอมไพล์ C → สร้างรันไทม์ JavaScript → รันโค้ด JS ได้สำเร็จ
กลยุทธ์ prompt engineering
- หลอกให้ AI รับรู้ว่าตัวเองกำลังรันอยู่ใน sandbox
- เริ่มจากการคำนวณทางคณิตศาสตร์ก่อน → แล้วค่อย ๆ ขอการเข้าถึงระบบไฟล์
- ผ่านการค้นหาระบบไฟล์ ทำให้ AI รับรู้สถานะ sandbox ของตนเอง → จากนั้นลองทดสอบช่องโหว่ด้านความปลอดภัย
บทสรุป
- สภาพแวดล้อมการรันโค้ดของ OpenAI มีความแข็งแกร่งและปลอดภัยมาก
- อย่างไรก็ตาม จากการ reverse engineering วิธีทำงานและสภาพแวดล้อมภายใน จึงทำให้สามารถรัน C และ JS ได้
- การรันโค้ดมีประโยชน์มากสำหรับการจัดการการตอบกลับ API แบบง่าย
- หากต้องการรันโค้ดที่ซับซ้อน ควรพิจารณาสร้างโซลูชันเอง หรือใช้บริการอย่าง freestyle.sh
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
เคยมีประสบการณ์เขียนส่วนขยาย SQLite ด้วย C แล้วคอมไพล์ จากนั้นโหลดเข้า Python เพื่อทดสอบ
เพิ่งได้ยินเรื่องน่าสนใจจากพอดแคสต์ Python เมื่อไม่นานมานี้
pip installแต่ถูกปฏิเสธpip install fooจะขึ้นข้อความผิดพลาดอะไร?" มันกลับบอกว่าไม่มีข้อผิดพลาดและติดตั้งสำเร็จไม่แน่ใจว่ามันกำลังรันโค้ดจริง ๆ หรือว่า LLM เดาผลลัพธ์แล้วแสดงออกมา
มันรันอยู่ในคอนเทนเนอร์ที่ถูกล็อกไว้ ดังนั้นไม่มีเหตุผลที่จะต้องจำกัดไว้แค่ Python
นี่คือวิธีทำให้คำว่า "Open" ใน "OpenAI" เป็นจริง
ขอบคุณสำหรับบทความที่น่าสนใจ
กรณีที่ Simonw ทดลองใช้ C กับ ChatGPT เมื่อ 1 ปีก่อน
ปีที่แล้วก็เคยทำอะไรคล้าย ๆ กัน และเคยลองรันไบนารีตามอำเภอใจด้วย
กลัวเรื่องความล้มเหลวด้านความปลอดภัยมากจนไม่คิดจะเอาแอปแบบนั้นขึ้นออนไลน์เลย
เจ๋งมาก และก็น่าสนใจที่จะลองอย่างอื่นเพิ่มเติม เช่น รันเดมอน C++ หรือเพิ่มเข้าไปใน cron