Gemini के Python Sandbox को हैक कर सोर्स कोड का हिस्सा लीक किया

• Lupin और Justin ने Google के 2024 Las Vegas LLM bugSWAT में Gemini preview के Python sandbox की जांच कर /usr/bin/entry/entry_point और internal file structure निकाला, और इस vulnerability के लिए Most Valuable Hacker जीता
• Sandbox gVisor और GRTE पर आधारित था और external network बंद था, लेकिन user code os module से filesystem traverse कर सकता था, इसलिए internal binary को console output chunks के जरिए बाहर निकाला जा सका
• 579MB वाले entry_point को सीधे output करने पर timeout हो रहा था, इसलिए seek() और base64 encoding से 10MB chunks बनाए गए, और Caido Automate से repeated requests भेजकर local machine पर फिर से assemble किया गया
• Binwalk analysis में google3 directory और Gemini sandbox से जुड़ा Python code सामने आया; public exposure के लिए approved code से अलग, classification.proto और कई security proto definitions अनजाने में शामिल confidential internal information थे
• यह confirm हुआ कि sandbox Google Flights जैसे tools से RPC के जरिए जुड़ता है और ज्यादा permissions वाले agent sandbox तक access की संभावना है, लेकिन जिस internal file-read handler पर शक था वह RPC से usable नहीं था और सिर्फ externally callable था

---

bugSWAT 2024 और Gemini preview access

• Lupin और Justin को 2024 में Las Vegas में Google LLM bugSWAT event के दौरान Gemini के अगले update preview का early access मिला
• Google team ने नई features और intended behavior वाले documents दिए, और researchers का लक्ष्य attacker perspective से features को explore और test करना था
• simple prompt run hello world in python3 से शुरू करने पर Gemini ने code generate किया और interface में Run in Sandbox button दिया
• इस vulnerability research के result में दोनों को उस Las Vegas bugSWAT में Most Valuable Hacker title मिला

Gemini Python sandbox की basic structure

• उस समय Gemini, AI-generated Python code या user द्वारा सीधे लिखी scripts को Gemini environment के अंदर run करने के लिए Python Sandbox Interpreter देता था
• Sandbox Google के gVisor और GRTE(Google Runtime Environment) पर आधारित था
  • gVisor एक user-space kernel है, जो containerized application और host operating system के बीच system calls intercept करता है
  • यह सिर्फ traditional OS-level isolation पर निर्भर नहीं रहता, बल्कि minimized kernel features का subset implement कर attack surface घटाता है
• Researchers ने gVisor sandbox escape को अलग high-difficulty problem माना, और sandbox escape अधिकतम $100k bounty के लिए eligible हो सकता था
• इस approach में sandbox escape करने के बजाय यह खोजा गया कि sandbox के अंदर ऐसा data है या नहीं जिसे बाहर expose नहीं होना चाहिए
• मुख्य constraint यह था कि sandbox सिर्फ custom-compiled Python binary चला सकता था

Filesystem mapping और entry_point की खोज

• Frontend में Python code को पूरी तरह rewrite करके sandbox में arbitrary version run कराया जा सकता था
• Shell launch नहीं किया जा सकता था, लेकिन custom Python binary में os module शामिल था, इसलिए filesystem mapping संभव थी
• Researchers ने recursively files और directories list करने और size/permissions print करने वाला Python function लिखा
• lslR("/usr") call के result में /usr/bin/entry/entry_point पर मौजूद binary file मिली
• इस file का size 579MB था, और आगे के analysis का यह main target बनी

Network के बिना binary exfiltrate करने का तरीका

• entry_point को सीधे base64 encode कर frontend पर print करने की कोशिश करने पर sandbox hang हुआ और आखिरकार timeout हो गया
• TCP, HTTP, DNS के जरिए external exfiltration की सभी कोशिशें fail हुईं, और sandbox external network से पूरी तरह isolated दिखा
• External calls blocked होने की स्थिति में researchers ने console output के जरिए binary को टुकड़ों में बाहर निकालने का तरीका चुना
• seek() से binary position move करते हुए read किया, base64 से encode किया और 10MB chunks में output किया
• Caido को proxy की तरह इस्तेमाल कर sandbox call requests और results capture किए, और Automate feature से requests बार-बार भेजीं
  • Automate ऐसा feature है जिससे bulk में requests भेजी जा सकती हैं और specific parameters जल्दी बदले जा सकते हैं
  • सभी base64 chunks इकट्ठा करने के बाद local machine पर पूरी file reconstruct की गई

entry_point analysis के results

• file command ने इस file को ELF 64-bit LSB shared object, x86-64, version 1 (SYSV) format की dynamically linked binary के रूप में identify किया
• strings command output में Google के internal repository की ओर इशारा करने वाले google3 references कई बार दिखे
• इन references ने internal data paths और code fragments की मौजूदगी का संकेत दिया, और दिखाया कि binary में Google proprietary software के traces मौजूद थे
• Binwalk ने decisive clue दिया
  • Binary के अंदर से पूरी file structure extract की गई
  • Extraction result में sandbox layout और internal components सामने आए

google3 directory और Gemini-related Python code

• Binwalk से extract की गई directory के अंदर google3 directory थी, जिसमें assistant, base, devtools, file, google, net, pyglib, testing, third_party, util जैसी subdirectories शामिल थीं
• assistant directory में YouTube, Google Flights, Google Maps जैसे tool requests handle करने में इस्तेमाल होने वाला RPC-related Gemini code मिला
• खास तौर पर google3/assistant/boq/lamda/execution_box/ के नीचे sandbox execution, image processing, tool usage और RPC interface से जुड़ी Python files थीं
• google3/assistant/boq/lamda/execution_box/images/py_interpreter.py में unauthorized script dump detection के लिए string जैसी दिखने वाली code शामिल थी
  • String "3AVp#dzcQj$U?uLOj+Gl]GlY<+Z8DnKh" थी
• बाद की review में Google Security Team ने यह निष्कर्ष निकाला कि इस Python code का internal Google3 inclusion, release से पहले public exposure के लिए Google द्वारा approved choice था
• इस code में dump-prevention mechanism जैसे elements थे, लेकिन public exposure itself approved था

Sandbox और Google tools RPC structure

• गहरे analysis में confirm हुआ कि sandbox Google Flights जैसी Google service data लाने के लिए external Google servers से communicate करता है
• यह communication google3.assistant.boq.lamda.execution_box.sandbox_interface की Python classes के जरिए implement था
• _set_reader_and_writer जैसे functions RPC के लिए reader और writer handles set करते हैं
  • default behavior /dev/fd/3 और /dev/fd/4 इस्तेमाल करने जैसा दिखा
• run_tool(name, operation_id, parameters) tool name, operation ID और parameters लेकर RunToolRequest बनाता है और उसे RPC request के रूप में pass करता है
• Functions data को protobuf-compatible format में serialize कर local file descriptor 5 पर write करते हैं, और response file descriptor 7 से read करते हैं
• बड़े binary में मिले proto का उपयोग कर researchers RPC server के साथ exchange होने वाले messages बना सके और Google tools को directly call कर सके

Agent sandbox और permission differences

• सभी sandboxes Google services के same set तक access नहीं कर सकते थे
• Difference इस बात पर निर्भर था कि sandbox frontend में Python source code run करने के लिए बनाया गया था या Google Agent ने बनाया था
• Google team ने Gemini के underlying research के रूप में REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS दिखाया
• ReAct approach में language model reasoning traces generate करने और specific actions execute करने की process को alternately perform करता है
  • Model problem solve करते हुए plan बनाता है और required data लाने के लिए external sources से interact करता है
  • इसे question answering, fact verification, text-based games और web navigation जैसे tasks पर लागू होने वाले framework के रूप में introduce किया गया
• अगर user Toronto और New York के बीच सबसे early flight पूछे, तो Gemini का roughly यह flow हो सकता है
  • User intent को flight search के रूप में interpret करना
  • Google Flights tool से connect करने वाला Python code plan करना
  • YYZ से JFK तक आज से अगले हफ्ते तक की flights ढूंढने और date-wise sort करने वाला code generate करना
  • आवश्यक permissions वाला sandbox बनाना और code execute करना
  • Output process कर user को response देना

Secondary prompt injection experiments और limits

• Researchers ने Gemini के planning stage में secondary prompt injection लगाकर यह test किया कि अधिक permissions वाले sandbox तक access मिल सकता है या नहीं
• Google Security Team की मदद से testing में पता चला कि generation seed और temperature जैसे probabilistic factors के आधार पर कभी-कभी ज्यादा permissions वाले sandbox जैसा environment access किया जा सकता था
• यहां अधिक permissions वाले sandbox का मतलब ऐसा environment है जिसमें extensions access करने वाले दो नए file descriptors उपलब्ध होते हैं
  • File descriptors खुद हमेशा मौजूद होते हैं, लेकिन हमेशा वास्तव में listen नहीं करते थे
  • जब agent sandbox call करता है, तो Google service extension calls को monitor कर API से interact किया जा सकता है
  • Python interpreter से access करने पर वे extensions accessible नहीं थे
• Researchers को लगा कि कोई specific message handler Google internal infrastructure से file read की अनुमति दे सकता है, इसलिए उन्होंने P0 possibility की उम्मीद की
• Google Security Team review में confirm हुआ कि संदिग्ध handler RPC से usable नहीं है और केवल externally callable है
• Experiment सीमित था, लेकिन code execution से ये possibilities खुल सकती थीं
  • Reliability: code execute करने से actions ज्यादा consistently trigger किए जा सकते हैं
  • Chaining/Complexity: कई tools control या parameter adjustments को text की तुलना में अधिक complex तरीके से compose किया जा सकता है
  • Tool Output Poisoning: tool output manipulation को ज्यादा effectively attempt किया जा सकता है
  • Leaks: environment के hidden parts expose हों तो additional advantage मिल सकता है

वास्तव में expose हुई proto files

• Researchers ने confirm किया कि कई तरीकों से proto files exfiltrate की जा सकती हैं
• Proto files Protocol Buffer files होती हैं, जो system की message structure और information exchange methods define करने वाली blueprint का काम करती हैं
• strings entry_point > stringsoutput.txt चलाने के बाद Dogfood search कर internal proto के कुछ हिस्से मिले
• Extracted कुछ content में बहुत sensitive proto के metadata descriptions शामिल थे
  • इसमें user data itself शामिल नहीं था
  • ये Google द्वारा user data को classify करने में इस्तेमाल होने वाली internal categories थीं
• Dogfood Google में public release से पहले अपने products और prototypes को internally use कर test और improve करने की practice को कहते हैं
• Exposed files में से एक privacy/data_governance/attributes/proto/classification.proto थी
  • यह file Google के अंदर data कैसे classify होता है, उससे deal करती है
  • इसमें related documentation references भी थे, लेकिन वे documents confidential थे और public access के लिए नहीं थे

Internal security proto definitions exposure

• उसी strings output में कई internal proto files भी दिखीं जिन्हें public नहीं होना चाहिए था
• cat stringsoutput.txt| grep '\.proto' | grep 'security' command से ये sensitive file paths सामने आए
  • 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
• Binary strings में security/credentials/proto/authenticator.proto देखने से confirm हो सकता था कि वह data सच में expose हुआ था

Proto binary में क्यों गया

• Google Security Team ने sandbox के contents review किए थे और public disclosure को approval दिया था
• लेकिन sandbox binary compile build pipeline में एक automatic step था, जो internal rule enforcement के लिए आवश्यक माना जाए तो security proto files को binary में जोड़ देता था
• इस case में वह step जरूरी नहीं था, लेकिन result में highly confidential internal proto अनजाने में शामिल हो गए
• Researchers जानते थे कि Google इन proto को ऐसी highly confidential information मानता है जिसे public नहीं होना चाहिए, इसलिए उन्होंने इसे bug के रूप में report किया
• Target organization के business rules और security priorities की गहरी understanding होने पर ही ऐसी subtle exposure identify और report की जा सकती है

Conclusion और practical implications

• Release से पहले advanced AI systems को सिर्फ feature behavior नहीं, बल्कि internal artifacts तक thoroughly test करना चाहिए
• Simple दिखने वाला sandbox भी कई extensions से जुड़ने पर unexpected exposure paths बना सकता है
• कई components साथ काम करें तो छोटी omission भी नया problem path बना सकती है
• इस case में public-approved internal code और गलती से शामिल confidential proto के बीच distinction किया गया, और बाद वाला actual security report का core बना
• AI agents, sandbox execution, tool calls और internal RPC के combined environment में execution isolation के साथ-साथ sandbox internal assets और build artifacts की भी review जरूरी है