Copilot को root करने का तरीका

• अप्रैल 2025 में, Copilot Enterprise में real-time Python sandbox (Jupyter Notebook आधारित) अपडेट किया गया, जिससे backend code execution संभव हो गया
• Jupyter Notebook के %command syntax के जरिए underlying system पर arbitrary code execution आसान था, और Linux commands भी ubuntu user (miniconda environment) के रूप में चलाई जा सकती थीं
• /app/miniconda/bin path ubuntu user के लिए writable था, और root के $PATH में भी इसे प्राथमिकता मिली हुई थी, जिससे pgrep जैसे महत्वपूर्ण commands को overwrite किया जा सकता था — यह एक security vulnerability थी
• इसका दुरुपयोग करके root privileges हासिल किए गए, लेकिन container के भीतर isolation बहुत सख्त था, इसलिए container escape संभव नहीं था, और कोई अतिरिक्त information leak भी नहीं हुआ
• इस vulnerability की रिपोर्ट अप्रैल में की गई थी और जुलाई में इसे मध्यम जोखिम के रूप में patch किया गया; कोई reward नहीं मिला, केवल researcher list में नाम जोड़ा गया

---

Microsoft Copilot Enterprise Jupyter Sandbox vulnerability analysis

Copilot Enterprise Jupyter environment overview

• अप्रैल 2025 से Copilot Enterprise में Jupyter Notebook आधारित Python sandbox पेश किया गया
• उपयोगकर्ता Jupyter के %command syntax के जरिए Linux system commands चला सकते थे
• environment miniconda-आधारित ubuntu user permissions पर चलता था, और sudo binary मौजूद नहीं थी
• environment variables, network, file system, process information आदि को अलग-अलग तरीकों से inspect किया जा सकता था

Container के अंदर का behavior और structure

• Copilot, ChatGPT sandbox जैसा है, लेकिन इसमें नया kernel और Python 3.12 इस्तेमाल होता है
• मुख्य processes: Jupyter Notebook, Go में लिखा गया goclientapp (port 6000 पर चलता है), httpproxy आदि
• network में केवल loopback और सीमित link-local interfaces सक्रिय थे
• file system OverlayFS पर आधारित था, /legion path को base के रूप में उपयोग करता था, और /app में custom scripts मौजूद थीं

Download और file manipulation

• text/command output files सामान्य रूप से डाउनलोड किए जा सकते थे, लेकिन binary files के corrupt होने का जोखिम था, इसलिए base64 encoding की जरूरत पड़ती थी
• files /mnt/data में स्थित थीं, और external download links blob URL के रूप में बनते थे

goclientapp/httpproxy structure

• goclientapp: बाहर से /execute endpoint पर मिले code (JSON format) को Jupyter environment में चलाता है और result लौटाता है
• httpproxy: Jupyter से बाहर जाने वाले HTTP traffic को proxy करता है (ENABLE_EGRESS=false होने पर disabled)

entrypoint.sh script vulnerability

• container की entrypoint script entrypoint.sh में कई services (goclientapp, httpproxyapp) ubuntu user permissions पर चलाई जाती थीं
• केवल keepAliveJupyterSvc.sh लगातार root के रूप में चलती रहती थी
• line 28 पर pgrep -f "jupyter notebook --ip=0.0.0.0 --port=8888" command, $PATH में directory priority के अनुसार execute होती थी
• /app/miniconda/bin, root और ubuntu user दोनों के PATH में /usr/bin से पहले था → pgrep जैसे commands को मनचाहे तरीके से replace किया जा सकता था

Root privileges हासिल करने की प्रक्रिया और सीमाएँ

• attacker ने /app/miniconda/bin में एक malicious pgrep script बनाई, ताकि entrypoint.sh इसे समय-समय पर root permissions के साथ execute करे
• यह script /mnt/data/in file को पढ़ती थी, उसे shell command के रूप में चलाती थी, और output को /mnt/data/out में सेव करती थी
• इस तरीके से container के भीतर root privileges हासिल करने में सफलता मिली, लेकिन /root files जैसी sensitive information, logs आदि तक पहुँच संभव नहीं थी, और container escape भी नहीं किया जा सका
• container में अलग-अलग breakout scenarios पहले से ही patch किए जा चुके थे

Microsoft की प्रतिक्रिया और परिणाम

• 18 अप्रैल 2025: Eye Security ने MSRC को vulnerability report भेजी
• 25 जुलाई 2025: Microsoft ने इसे मध्यम जोखिम (moderate severity) के रूप में वर्गीकृत किया, patch के बाद issue बंद किया और researcher list में नाम जोड़ा (bug bounty नहीं दी गई)

संदर्भ और परिशिष्ट

• Eye Security यूरोप-आधारित cyber security कंपनी है, जो 24/7 threat monitoring, incident response, cyber insurance आदि प्रदान करती है

• इस vulnerability सहित internal Microsoft services (Entra OAuth आदि) में intrusion के मामले BlackHat USA 2025 में प्रस्तुत किए जाने की योजना है

• Timeline

  • 18 अप्रैल 2025 – MSRC को रिपोर्ट
  • 25 जुलाई 2025 – patch और case बंद, blog प्रकाशित

[GN⁺]

Hacker News राय

• मैं समझता हूँ कि इस कमजोरी का सार यह था कि मूल डिज़ाइन में कंटेनर के अंदर केवल सामान्य user privileges देने का इरादा था, लेकिन एक ट्रिक का उपयोग करके root privileges के साथ code execution संभव हो गया। लेकिन वास्तव में कंटेनर खुद इतनी सख्ती से isolate किया गया था कि न network access था और न escape संभव था, इसलिए root privileges के साथ किया भी जा सकने वाला काम बस अपने ही कंटेनर को खराब करना था
  • मानना पड़ेगा कि Microsoft ने security configuration सचमुच बहुत सख्ती से की थी। ज़्यादातर कंपनियाँ इस स्तर की isolation नहीं करतीं
  • मुझे नहीं पता कि यह कंटेनर ठीक किस तरह implement किया गया था। Microsoft Python sandbox को isolate करने के लिए standard तरीका (Azure container-apps session) इस्तेमाल कर रहा है, इसलिए उम्मीद है कि इस feature में भी वही या उससे मिलता-जुलता तरीका इस्तेमाल हुआ होगा
  • यह थोड़ा अजीब लगता है कि Copilot कभी code execution को मना करता है और कभी अनुमति देता है। यह ठीक कहाँ तक जाना चाहता है, यह जानने की जिज्ञासा है
  • आजकल vulnerabilities एक stack की तरह जमा होती हैं, इसलिए “container सुरक्षित है” का मतलब अक्सर बस इतना होता है कि attacker को अभी कमजोरी नहीं मिली है। Container escape और VM escape पहले से ज्ञात attack techniques हैं, और configuration mistake या virtio driver में bug जैसी एक छोटी गलती से भी breach हो सकता है। यह मामला वास्तव में महत्वपूर्ण परिणाम है
• “How We Rooted Copilot” जैसा शीर्षक देखकर लगा था कि सचमुच Copilot के core VM को भेद दिया गया होगा, लेकिन असल में बस एक बेहद सीमित Python sandbox container में root privileges हासिल किए गए थे। ज़्यादा सही शीर्षक “How We Rooted the Copilot Python Sandbox” होता
  • इसे “पूरी तरह isolated sandbox में सामान्य user से root तक privilege escalation में सफलता” जैसा संक्षेप दिया जा सकता है। व्यवहार में इसका विशेष मतलब नहीं, लेकिन उलटे यह दिखाता है कि sandboxing ने defense में कितनी प्रभावी भूमिका निभाई
• पूरा hacking process यहाँ देखा जा सकता है
• मैंने इस घटना को Python sandbox से निकलकर container तक breach करने के रूप में समझा था। शायद इसी संदर्भ में Microsoft ने इसकी severity को moderate माना
• शायद मैं कुछ मिस कर रहा हूँ, लेकिन क्या local network के रास्ते भी बाहर network connection की कोशिश नहीं की जा सकती? Microsoft ग्राहकों के लिए ऐसे कंटेनर में root privileges तक की अनुमति देकर भी क्या सचमुच data exfiltration या आगे के attack का कोई जोखिम नहीं मानता था, यह सोचने वाली बात है
  • पहले जब openai ने Python interpreter feature जारी किया था, तब भी स्थिति मिलती-जुलती थी। बाहरी network access बंद था, और दिलचस्प चीज़ें बस कुछ internal configuration files और developers के coding style से जुड़ी थोड़ी जानकारी ही थीं। यह मामला भी लगभग वैसा ही है
• Copilot ने जो जवाब बताया वह सच है या hallucination, यह कैसे पता चले? मैं वहीं काम करता हूँ, लेकिन मैंने ऐसा process कभी नहीं देखा। संदर्भ के लिए, public repository में keepAliveJupyterSvc.sh नाम की एक script मिली
  • वह repository और उसके contributors वास्तव में MS/Azure से जुड़े लगते हैं और कंटेनर के अंदर Python code execution service विकसित कर रहे हैं। यह किसी personal account पर क्यों है, पता नहीं। कहा जाता है कि यह Office project का fork है, लेकिन original नहीं मिल रहा
  • यह hallucination न भी हो सकता है। संभव है Copilot का code github training dataset से generate हुआ हो
  • यह तो सचमुच hallucination जैसा लगता है। Chatbot ज़्यादातर token generators ही होते हैं। वे वास्तव में program चलाकर जवाब नहीं देते, बल्कि GPU पर tokens बनाकर उन्हें अंग्रेज़ी में बदलकर भेजते हैं
• पहले कहा जाता था कि शुरुआती LLMs private company documents को training data में लेकर company secrets अच्छी तरह उजागर कर देते थे। अब लगता है कि ज़्यादातर data साफ़ कर दिया गया है
  • मैंने ऐसा कोई मामला नहीं देखा जहाँ LLM ने किसी एक बार दिखाई गई private जानकारी को याद रखा हो, या जहाँ private data का बड़े पैमाने पर training हुआ हो। इसलिए यह अवास्तविक लगता है। LLM की hallucination बस ऊपर-ऊपर देखने पर उसे असली secret leak जैसा दिखा सकती है
  • मेरे अनुभव में company secret दूसरी कंपनियों के नज़रिए से अक्सर उतने मायने नहीं रखते
  • जिज्ञासा है कि क्या ऐसे मामलों के ठोस उदाहरण हैं। मैंने तो नहीं देखे
  • पहले (non-technical) कंपनियाँ भी बिना guidelines के इसे अपना रही थीं, इसलिए कभी-कभी उद्देश्य से हटकर content भी बन जाता था। उदाहरण के लिए, एक boba (bubble tea) कंपनी ने बिना signup वाला free LLM जारी किया था, और मैंने ChatGPT free version आने से पहले उससे कुछ bash scripts बनवाकर इस्तेमाल किए थे
  • स्रोत जानने की इच्छा है
• यह वस्तुतः vulnerability जैसा नहीं लगता। इस system का मकसद ही container में code चलाने देना है
  • बेशक, इसका मतलब तभी है जब container isolated हो
• लगता है Copilot को sudo binary base64 में देकर फिर उसका उपयोग करने के तरीके से और आसानी से bypass किया जा सकता था
  • लेकिन फिर file owner को भी root में बदलना पड़ता
• Microsoft को vulnerability report की गई, और इसे moderate के रूप में classify किया गया, इसलिए bug bounty नहीं मिला, सिर्फ acknowledgement मिला। इतनी बड़ी कंपनी का इनाम तक न देना समझ से बाहर है। ऐसे माहौल में बुरी चीज़ें होने से कैसे बचें, यह सवाल है
  • मूल रूप से हासिल कुछ भी नहीं हुआ। Root privileges मिलने पर भी बस कंटेनर के उस छोटे हिस्से को explore किया जा सका जहाँ पहले पहुँच नहीं थी, लेकिन /root में भी कोई files नहीं थीं, और काम की logs भी नहीं बची थीं। सभी ज्ञात escape techniques पहले से patch थीं। अगर Microsoft ऐसे हर bypass किए गए तरीके पर इनाम देने लगे, तो इसका अंत नहीं होगा, इसलिए जोखिम न होने पर अलग से reward न देना कुछ हद तक समझ आता है
  • सच कहूँ तो समझ नहीं आता कि लोग trillion-dollar बड़ी कंपनियों को मुफ्त में bug reports क्यों देते हैं
  • अगर Microsoft पैसे नहीं देने वाला, तो कम-से-कम कुछ swag तो देना चाहिए। हैकर्स को अच्छे goodies देने से अपने-आप प्रचार होता है, और उलटे वहाँ काम करने की इच्छा भी हो सकती है। Hacker community culture का उपयोग करना चाहिए
  • “root” हासिल करने के बाद भी वास्तव में कुछ नहीं मिलता। कई कोशिशों के बाद भी कोई खास नतीजा नहीं निकला