แฮ็ก Python Sandbox ของ Gemini และดึงซอร์สโค้ดบางส่วนออกมาได้

• Lupin และ Justin ตรวจสอบ Python sandbox ของ Gemini preview ในงาน LLM bugSWAT ของ Google ที่ Las Vegas ปี 2024 และดึง /usr/bin/entry/entry_point กับโครงสร้างไฟล์ภายในออกมาได้ พร้อมได้รับรางวัล Most Valuable Hacker จากช่องโหว่นี้
• Sandbox ใช้ gVisor และ GRTE เป็นพื้นฐานและถูกปิดกั้นเครือข่ายภายนอก แต่โค้ดของผู้ใช้สามารถใช้โมดูล os เพื่อไล่ดูไฟล์ซิสเต็มได้ จึงสามารถนำ binary ภายในออกมาผ่าน chunk ของเอาต์พุตคอนโซล
• entry_point ขนาด 579MB หากพิมพ์ออกมาตรง ๆ จะเกิด timeout จึงใช้ seek() และการเข้ารหัส base64 เพื่อสร้าง chunk ขนาด 10MB แล้วใช้ Caido Automate ส่งคำขอซ้ำ ๆ ก่อนนำมาประกอบกลับในเครื่อง
• การวิเคราะห์ด้วย Binwalk เผยให้เห็นไดเรกทอรี google3 และโค้ด Python ที่เกี่ยวข้องกับ Gemini sandbox และต่างจากโค้ดที่ได้รับอนุมัติให้เผยแพร่ได้ classification.proto รวมถึง นิยาม proto ด้านความปลอดภัย หลายรายการเป็นข้อมูลภายในลับที่ถูกใส่มาโดยไม่ได้ตั้งใจ
• พบโครงสร้างที่ sandbox เชื่อมต่อกับเครื่องมืออย่าง Google Flights ผ่าน RPC และความเป็นไปได้ในการเข้าถึง agent sandbox ที่มีสิทธิ์สูงกว่า แต่ handler สำหรับอ่านไฟล์ภายในที่สงสัยนั้นใช้ผ่าน RPC ไม่ได้ และเรียกได้จากภายนอกเท่านั้น

---

bugSWAT 2024 และการเข้าถึง Gemini preview

• Lupin และ Justin ได้สิทธิ์เข้าถึงล่วงหน้า Gemini รุ่น preview สำหรับอัปเดตถัดไปในงาน Google LLM bugSWAT ที่ Las Vegas ปี 2024
• ทีม Google ให้เอกสารที่อธิบายฟีเจอร์ใหม่และพฤติกรรมที่ตั้งใจไว้ โดยเป้าหมายของนักวิจัยคือสำรวจและทดสอบฟีเจอร์ต่าง ๆ จากมุมมองของผู้โจมตี
• เมื่อเริ่มด้วย prompt ง่าย ๆ run hello world in python3 Gemini ก็สร้างโค้ดและแสดงปุ่ม Run in Sandbox ในอินเทอร์เฟซ
• จากผลการวิจัยช่องโหว่นี้ ทั้งสองคนได้รับตำแหน่ง Most Valuable Hacker ในงาน Las Vegas bugSWAT ครั้งนั้น

โครงสร้างพื้นฐานของ Gemini Python sandbox

• ในเวลานั้น Gemini มี Python Sandbox Interpreter สำหรับรันโค้ด Python ที่ AI สร้างขึ้น หรือสคริปต์ที่ผู้ใช้เขียนเอง ภายในสภาพแวดล้อมของ Gemini
• Sandbox ถูกสร้างบนพื้นฐานของ gVisor ของ Google และ GRTE (Google Runtime Environment)
  • gVisor คือ user-space kernel ที่ดักจับ system call ระหว่างแอปพลิเคชันในคอนเทนเนอร์กับระบบปฏิบัติการโฮสต์
  • ไม่ได้พึ่งพาการแยกระดับ OS แบบดั้งเดิมเพียงอย่างเดียว แต่ implement ชุดย่อยของฟังก์ชัน kernel ที่ลดทอนลง เพื่อลด attack surface
• นักวิจัยมองว่าการ escape จาก gVisor sandbox เป็นโจทย์ยากอีกเรื่องหนึ่ง และการ escape sandbox อาจเข้าข่าย bounty สูงสุด $100k
• แนวทางครั้งนี้ไม่ใช่การ escape sandbox แต่เป็นการค้นหาว่าภายใน sandbox มีข้อมูลที่ไม่ควรถูกเปิดเผยออกไปหรือไม่
• ข้อจำกัดสำคัญคือ sandbox สามารถรันได้เฉพาะ Python binary ที่คอมไพล์แบบ custom เท่านั้น

การ map ไฟล์ซิสเต็มและการพบ entry_point

• จาก frontend สามารถเขียนโค้ด Python ใหม่ทั้งหมดและรันเวอร์ชันใด ๆ ใน sandbox ได้
• แม้จะเปิด shell ไม่ได้ แต่ Python binary แบบ custom มีโมดูล os รวมอยู่ด้วย จึงสามารถ map ไฟล์ซิสเต็มได้
• นักวิจัยเขียนฟังก์ชัน Python ที่ไล่แสดงรายชื่อไฟล์และไดเรกทอรีแบบ recursive พร้อมพิมพ์ขนาดและสิทธิ์
• ผลจากการเรียก lslR("/usr") ทำให้พบไฟล์ binary ที่ /usr/bin/entry/entry_point
• ไฟล์นี้มีขนาด 579MB และกลายเป็นเป้าหมายหลักของการวิเคราะห์ต่อมา

วิธีดึง binary ออกมาโดยไม่มีเครือข่าย

• เมื่อพยายามเข้ารหัส entry_point เป็น base64 แล้วพิมพ์ออกไปยัง frontend โดยตรง sandbox ก็ค้างและสุดท้าย timeout
• ความพยายามดึงข้อมูลออกภายนอกผ่าน TCP, HTTP และ DNS ล้มเหลวทั้งหมด และ sandbox ดูเหมือนถูกแยกจากเครือข่ายภายนอกอย่างสมบูรณ์
• เมื่อการเรียกออกภายนอกถูกบล็อก นักวิจัยจึงเลือกวิธีแบ่ง binary เป็นชิ้น ๆ แล้วดึงออกผ่านเอาต์พุตคอนโซล
• ใช้ seek() เพื่อเลื่อนตำแหน่งใน binary แล้วอ่าน เข้ารหัสเป็น base64 จากนั้นพิมพ์ออกมาเป็น chunk ขนาด 10MB
• ใช้ Caido เป็น proxy เพื่อจับคำขอเรียก sandbox และผลลัพธ์ แล้วใช้ฟีเจอร์ Automate ส่งคำขอซ้ำ ๆ
  • Automate เป็นฟีเจอร์สำหรับส่งคำขอจำนวนมากและเปลี่ยนพารามิเตอร์บางตัวได้อย่างรวดเร็ว
  • หลังจากรวบรวม chunk base64 ทั้งหมดแล้ว จึงประกอบไฟล์เต็มกลับในเครื่อง

ผลการวิเคราะห์ entry_point

• คำสั่ง file ระบุว่าไฟล์นี้เป็น binary แบบ dynamic link ในรูปแบบ ELF 64-bit LSB shared object, x86-64, version 1 (SYSV)
• เอาต์พุตของคำสั่ง strings พบการอ้างอิงถึง google3 ซึ่งชี้ไปยัง repository ภายในของ Google หลายครั้ง
• การอ้างอิงเหล่านี้บ่งชี้ถึงเส้นทางข้อมูลภายในและการมีอยู่ของชิ้นส่วนโค้ด และแสดงให้เห็นว่า binary มีร่องรอยซอฟต์แวร์กรรมสิทธิ์ของ Google อยู่
• Binwalk ให้เบาะแสสำคัญ
  • แยกโครงสร้างไฟล์ทั้งหมดออกจากภายใน binary
  • ผลการแยกเผยให้เห็น layout ของ sandbox และองค์ประกอบภายใน

ไดเรกทอรี google3 และโค้ด Python ที่เกี่ยวข้องกับ Gemini

• ในไดเรกทอรีที่แยกด้วย Binwalk มีไดเรกทอรี google3 ซึ่งมีไดเรกทอรีย่อยอย่าง assistant, base, devtools, file, google, net, pyglib, testing, third_party, util
• ในไดเรกทอรี assistant พบ โค้ด Gemini ที่เกี่ยวข้องกับ RPC ซึ่งใช้จัดการคำขอเครื่องมืออย่าง YouTube, Google Flights และ Google Maps
• โดยเฉพาะใต้ google3/assistant/boq/lamda/execution_box/ มีไฟล์ Python ที่เกี่ยวข้องกับการรัน sandbox, การประมวลผลภาพ, การใช้เครื่องมือ และอินเทอร์เฟซ RPC
• ใน google3/assistant/boq/lamda/execution_box/images/py_interpreter.py มีโค้ดที่ดูเหมือนเป็นสตริงสำหรับตรวจจับการ dump สคริปต์โดยไม่ได้รับอนุญาต
  • สตริงคือ "3AVp#dzcQj$U?uLOj+Gl]GlY<+Z8DnKh"
• จากการตรวจสอบภายหลัง การรวมโค้ด Python นี้จาก Google3 ภายในถูกสรุปว่าเป็นตัวเลือกที่ Google Security Team อนุมัติให้เปิดเผยต่อสาธารณะก่อนการเปิดตัว
• แม้โค้ดดังกล่าวมีองค์ประกอบที่ดูเหมือนกลไกป้องกันการ dump แต่การเปิดเผยตัวโค้ดเองได้รับการอนุมัติแล้ว

โครงสร้าง RPC ระหว่าง sandbox กับเครื่องมือของ Google

• การวิเคราะห์เชิงลึกยิ่งขึ้นพบว่า sandbox มีโครงสร้างที่สื่อสารกับเซิร์ฟเวอร์ภายนอกของ Google เพื่อดึงข้อมูลบริการ Google เช่น Google Flights
• การสื่อสารนี้ implement ผ่านคลาส Python ใน google3.assistant.boq.lamda.execution_box.sandbox_interface
• ฟังก์ชันอย่าง _set_reader_and_writer ตั้งค่า handle สำหรับ reader และ writer ของ RPC
  • พฤติกรรมพื้นฐานดูเหมือนใช้ /dev/fd/3 และ /dev/fd/4
• run_tool(name, operation_id, parameters) รับชื่อเครื่องมือ, ID งาน และพารามิเตอร์ เพื่อสร้าง RunToolRequest แล้วส่งเป็นคำขอ RPC
• ฟังก์ชันต่าง ๆ ทำงานโดย serialize ข้อมูลเป็นรูปแบบที่เข้ากันได้กับ protobuf แล้วเขียนไปยัง file descriptor ในเครื่องหมายเลข 5 และอ่านคำตอบจาก file descriptor หมายเลข 7
• ด้วย proto ที่พบใน binary ขนาดใหญ่ นักวิจัยสามารถสร้างข้อความสำหรับสื่อสารกับ RPC server และเรียกเครื่องมือของ Google ได้โดยตรง

Agent sandbox และความแตกต่างของสิทธิ์

• ไม่ใช่ sandbox ทุกตัวจะเข้าถึงชุดบริการ Google ชุดเดียวกันได้
• ความแตกต่างขึ้นอยู่กับว่า sandbox ถูกสร้างขึ้นเพื่อรันซอร์สโค้ด Python จาก frontend หรือถูกสร้างโดย Google Agent
• ทีม Google แสดงงานวิจัยที่ Gemini ใช้เป็นพื้นฐานคือ REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS
• แนวทาง ReAct เป็นโครงสร้างที่ให้ language model สลับกันระหว่างการสร้างร่องรอยการให้เหตุผลและการดำเนินการบางอย่าง
  • โมเดลแก้ปัญหาโดยสร้างแผนและโต้ตอบกับแหล่งข้อมูลภายนอกเพื่อดึงข้อมูลที่จำเป็น
  • ถูกนำเสนอเป็นเฟรมเวิร์กสำหรับงานอย่างถามตอบ, ตรวจสอบข้อเท็จจริง, เกมแบบข้อความ และการท่องเว็บ
• หากผู้ใช้ถามหาเที่ยวบินที่ออกเร็วที่สุดระหว่าง Toronto กับ New York Gemini อาจมีลำดับการทำงานโดยคร่าว ๆ ดังนี้
  • ตีความเจตนาของผู้ใช้ว่าเป็นการค้นหาเที่ยวบิน
  • วางแผนโค้ด Python ที่จะเชื่อมต่อกับเครื่องมือ Google Flights
  • สร้างโค้ดที่ค้นหาเที่ยวบินจาก YYZ ไป JFK ตั้งแต่วันนี้ถึงสัปดาห์หน้า และเรียงตามวันที่
  • สร้าง sandbox ที่มีสิทธิ์ที่จำเป็นและรันโค้ด
  • ประมวลผลเอาต์พุตแล้วตอบกลับผู้ใช้

การทดลอง prompt injection ขั้นที่สองและข้อจำกัด

• นักวิจัยทดลองทำ secondary prompt injection ในขั้นตอนการวางแผนของ Gemini เพื่อดูว่าสามารถเข้าถึง sandbox ที่มีสิทธิ์สูงกว่าได้หรือไม่
• จากการทดสอบด้วยความช่วยเหลือของ Google Security Team พบว่าบางครั้งสามารถเข้าถึงสภาพแวดล้อมที่ดูเหมือน sandbox สิทธิ์สูงกว่าได้ ขึ้นอยู่กับปัจจัยเชิงความน่าจะเป็นอย่าง generation seed และ temperature
• sandbox ที่มีสิทธิ์สูงกว่าในที่นี้หมายถึงสภาพแวดล้อมที่ใช้ file descriptor ใหม่สองตัวสำหรับเข้าถึง extension ได้
  • file descriptor เองมีอยู่เสมอ แต่ไม่ได้มีสิ่งที่ listen อยู่จริงเสมอไป
  • เมื่อ agent เรียก sandbox จะสามารถเฝ้าดูการเรียก extension ของบริการ Google และโต้ตอบกับ API ได้
  • หากเข้าถึงจาก Python interpreter จะเข้าถึง extension ดังกล่าวไม่ได้
• นักวิจัยคาดหวังความเป็นไปได้ระดับ P0 เพราะมองว่า message handler บางตัวอาจอนุญาตให้อ่านไฟล์จากโครงสร้างพื้นฐานภายในของ Google ได้
• ผลการตรวจสอบของ Google Security Team ยืนยันว่า handler ที่สงสัยนั้นใช้ผ่าน RPC ไม่ได้ และเรียกได้จากภายนอกเท่านั้น
• แม้การทดลองจะมีข้อจำกัด แต่การรันโค้ดสามารถเปิดความเป็นไปได้ต่อไปนี้
  • Reliability: การรันโค้ดช่วย trigger พฤติกรรมได้สม่ำเสมอกว่า
  • Chaining/Complexity: สามารถจัดโครงสร้างการควบคุมเครื่องมือหลายตัวหรือการปรับพารามิเตอร์ได้ซับซ้อนกว่าข้อความ
  • Tool Output Poisoning: สามารถพยายามบิดเบือนเอาต์พุตของเครื่องมือได้มีประสิทธิภาพกว่า
  • Leaks: หากส่วนที่ซ่อนอยู่ของสภาพแวดล้อมถูกเปิดเผย อาจให้ข้อได้เปรียบเพิ่มเติม

ไฟล์ proto ที่ถูกเปิดเผยจริง

• นักวิจัยยืนยันได้ว่าสามารถดึง ไฟล์ proto ออกมาได้หลายวิธี
• ไฟล์ proto คือไฟล์ Protocol Buffer ที่ทำหน้าที่เป็น blueprint สำหรับกำหนดโครงสร้างข้อความของระบบและวิธีแลกเปลี่ยนข้อมูล
• หลังรัน strings entry_point > stringsoutput.txt แล้วค้นหา Dogfood ก็พบ proto ภายในบางส่วน
• เนื้อหาบางส่วนที่แยกออกมามีคำอธิบาย metadata ของ proto ที่อ่อนไหวมาก
  • ไม่ได้มีข้อมูลผู้ใช้โดยตรง
  • เป็นหมวดหมู่ภายในที่ Google ใช้ในการ จำแนกประเภท ข้อมูลผู้ใช้
• Dogfood หมายถึงแนวปฏิบัติของ Google ในการใช้ผลิตภัณฑ์และ prototype ของตนเองเป็นการภายในก่อนเปิดตัวสู่สาธารณะ เพื่อทดสอบและปรับปรุง
• หนึ่งในไฟล์ที่ถูกเปิดเผยคือ privacy/data_governance/attributes/proto/classification.proto
  • ไฟล์นี้กล่าวถึงวิธีที่ข้อมูลถูกจำแนกประเภทภายใน Google
  • มีการอ้างอิงเอกสารที่เกี่ยวข้องด้วย แต่เอกสารเหล่านั้นเป็นความลับและไม่ใช่สิ่งที่สาธารณะเข้าถึงได้

การเปิดเผยนิยาม proto ด้านความปลอดภัยภายใน

• ในเอาต์พุต strings เดียวกัน ยังพบไฟล์ proto ภายในหลายรายการที่ไม่ควรถูกเปิดเผย
• คำสั่ง cat stringsoutput.txt| grep '\.proto' | grep 'security' แสดง path ของไฟล์อ่อนไหวดังต่อไปนี้
  • security/thinmint/proto/core/thinmint_core.proto
  • security/thinmint/proto/thinmint.proto
  • security/credentials/proto/authenticator.proto
  • security/data_access/proto/standard_dat_scope.proto
  • security/loas/l2/proto/credstype.proto
  • security/credentials/proto/end_user_credentials.proto
  • security/loas/l2/proto/usertype.proto
  • security/credentials/proto/iam_request_attributes.proto
  • security/util/proto/permission.proto
  • security/loas/l2/proto/common.proto
  • ops/security/sst/signalserver/proto/ss_data.proto
  • security/credentials/proto/data_access_token_scope.proto
  • security/loas/l2/proto/identity_types.proto
  • security/credentials/proto/principal.proto
  • security/loas/l2/proto/instance.proto
  • security/credentials/proto/justification.proto
• เมื่อดู security/credentials/proto/authenticator.proto ในสตริงของ binary ก็เห็นได้ว่าข้อมูลดังกล่าวถูกเปิดเผยจริง

ทำไม proto จึงเข้าไปอยู่ใน binary

• Google Security Team ตรวจสอบเนื้อหาภายใน sandbox และอนุมัติการ disclosure ต่อสาธารณะแล้ว
• อย่างไรก็ตาม pipeline สำหรับ build binary ของ sandbox มีขั้นตอนอัตโนมัติที่เพิ่ม ไฟล์ security proto เข้าไปใน binary หากพิจารณาว่าอาจจำเป็นต่อการบังคับใช้กฎภายใน
• ในกรณีนี้ขั้นตอนนั้นไม่จำเป็น แต่ผลลัพธ์คือ proto ภายในที่เป็นความลับสูงมากถูกใส่เข้ามาโดยไม่ได้ตั้งใจ
• นักวิจัยรู้ว่า Google ถือว่า proto เหล่านี้เป็นข้อมูลลับระดับสูงที่ไม่ควรถูกเปิดเผย จึงรายงานเป็น bug
• การระบุและรายงานการรั่วไหลที่ละเอียดอ่อนเช่นนี้จำเป็นต้องเข้าใจกฎทางธุรกิจและลำดับความสำคัญด้านความปลอดภัยขององค์กรเป้าหมายอย่างลึกซึ้ง

บทสรุปและข้อคิดเชิงปฏิบัติ

• ระบบ AI ล้ำสมัยก่อนเปิดตัวต้องถูกทดสอบอย่างละเอียด ไม่ใช่เฉพาะพฤติกรรมของฟีเจอร์ แต่รวมถึง artifact ภายในด้วย
• แม้ sandbox ที่ดูเรียบง่ายก็อาจมีเส้นทางเปิดเผยข้อมูลที่คาดไม่ถึงเมื่อเชื่อมต่อกับ extension หลายตัว
• เมื่อองค์ประกอบหลายส่วนทำงานร่วมกัน การตกหล่นเล็กน้อยอาจสร้างเส้นทางปัญหาใหม่ได้
• ในกรณีนี้มีการแยกความแตกต่างระหว่างโค้ดภายในที่ได้รับอนุมัติให้เผยแพร่ กับ proto ลับที่ถูกใส่มาโดยไม่ได้ตั้งใจ และส่วนหลังคือแกนหลักของรายงานความปลอดภัยจริง
• ในสภาพแวดล้อมที่รวม AI agent, การรันใน sandbox, การเรียกเครื่องมือ และ RPC ภายในเข้าด้วยกัน ต้องตรวจสอบไม่เพียงการแยกการรันเท่านั้น แต่รวมถึง ทรัพยากรภายใน sandbox และ artifact จากการ build ด้วย