OpenAI ने नुकतेच GitHub वर codex-security लाँच केले आहे – हा एक npm-installable स्कॅनर आहे जो रिपॉझिटरीचे तीन टप्प्यांत विश्लेषण करतो आणि बग्स आपोआप सुधारण्याचा (auto-fix) प्रयत्न करतो.
या लाँचमध्ये एका गंभीर त्रुटीकडे दुर्लक्ष करण्यात आले आहे, जी अलीकडील 'sandbox-bypass' डेमोमध्ये समोर आली आहे. संशोधकांनी दाखवून दिले आहे की Cursor, Codex CLI, Gemini CLI आणि Google Antigravity सारख्या टूल्ससाठी "locked-down" वातावरणात चालणारे एजंट्स, सँडबॉक्सला होस्ट सिस्टमशी जोडणाऱ्या इंटरफेसेसचा वापर करून मूळ संरक्षणातून बाहेर पडू शकतात. नवीन OpenAI स्कॅनर या 'attack surface' ला स्पर्शही करत नाही.
हे बायपास (bypasses) कसे काम करतात
एजंट्स त्यांच्या कंटेनर्सच्या आतच राहतात, परंतु ते डिस्कवर जे काही लिहितात, त्यावर git hooks, Python extensions, Docker daemons आणि तत्सम बाह्य सेवा (external helpers) लगेच विश्वास ठेवतात. या सेवा त्या फाईल्स वाचतात, त्यांना वैध मानतात आणि वापरकर्त्याला विचारल्याशिवाय होस्टवर त्यांची अंमलबजावणी (execute) करतात.
- Cursor मुळे एका एजंटला असा git hook रजिस्टर करता आला जो सँडबॉक्सच्या बाहेर चालला.
- Codex CLI git कमांड्समधील पॅरामीटर्स तपासण्यात अपयशी ठरले, ज्यामुळे अनधिकृत अंमलबजावणीचा (arbitrary execution) मार्ग मोकळा झाला.
- अनेक एजंट्सना Docker socket चा थेट प्रवेश मिळाला, जो एक विशेषाधिकार प्राप्त (privileged) प्रवेश बिंदू आहे आणि ज्यामुळे कोड होस्ट मशीनवर कंटेनर्स सुरू करू शकतो.
- DuneSlide मधील त्रुटींमुळे अटॅकर सँडबॉक्स लागू करणारा घटक ओव्हरराईट करू शकतो, ज्यामुळे प्रत्यक्षात तो अडथळा पूर्णपणे निघून जातो.
प्रत्येक प्रकरणात, ही घुसखोरी (exploit) अत्यंत शांतपणे झाली – एखादा वेब-सर्च रिझल्ट किंवा multi-choice-prompt (MCP) टूल कडून मिळालेला प्रतिसाद, जो एजंटने स्वीकारला होता. तो घातक पेलोड (malicious payload) कार्यान्वित झाला, नाहीसा झाला आणि स्टॅटिक कोड स्कॅनमध्ये कधीही दिसून आला नाही.
OpenAI चे टूल नेमके का चुकते
Codex-security static analysis वर लक्ष केंद्रित करते: ते तुम्ही कमिट केलेल्या सोर्स फाईल्सची तपासणी करते, असुरक्षित पॅटर्न शोधते आणि त्यांना आपोआप पुन्हा लिहू शकते. ही पद्धत कोड शिप करण्यापूर्वीच तो अस्ताव्यस्त किंवा धोकादायक असल्यास पकडते, परंतु हे केवळ तुम्ही पाठवलेल्या कोडची स्कॅनिंग करते, तर हल्ले स्वतः एजंटच्या 'runtime environment' मध्ये होतात.
सँडबॉक्स बायपास हे दर्शवतात की खरा धोका AI सँडबॉक्स आणि डेव्हलपरच्या इतर टूलचेन (toolchain) मधील runtime bridge मध्ये आहे. अटॅकरला रिपॉझिटरीमध्ये घातक कोड इंजेक्ट करण्याची गरज नाही; त्यांना फक्त सँडबॉक्समधील एजंटला अशी फाईल लिहिण्यास प्रवृत्त करायचे असते, जी नंतर एखादी बाह्य प्रक्रिया (external process) कार्यान्वित करेल.
कोणाचा फायदा, कोणाचे नुकसान
- डेव्हलपर्स
- टूल विक्रेते
- OpenAI
- अटॅकर्स
समुदाय आता काय करू शकतो
महत्त्वाचे उपाय हे केवळ कोड-स्तरावरील नसून ऑपरेशनल आहेत. AI कोडिंग एजंट समाविष्ट (integrate) करणाऱ्या प्रत्येकाने खालील व्यावहारिक पावले उचलली पाहिजेत:
- एजंटची व्हर्जन फिक्स (Pin) ठेवा आणि अपग्रेड करण्यापूर्वी changelogs वाचा. नवीन रिलीजमुळे नकळत एखादा नवीन hook किंवा socket उघडू शकतो.
- “clone and explore” ला अनोळखी कोड चालवण्यासारखे समजा. अतिरिक्त आयसोलेशनशिवाय (isolation) तुमच्या नियंत्रणाबाहेरील रिपॉझिटरीकडे कधीही एजंट वळवू नका.
- प्रत्येक सहाय्यक टूलची (auxiliary tool) तपासणी करा (git hooks, Python extensions, Docker access). जर एखादे टूल एजंटच्या आउटपुटवर आधारित डिरेक्टरी किंवा symlink बदलू शकत असेल, तर त्याचा वापर शस्त्र म्हणून (weaponized) केला जाऊ शकतो असे समजा.
- सँडबॉक्समधून Docker socket access काढून टाका.
- काय काय वाचले जाते याची माहिती घ्या. सँडबॉक्सपासून होस्टपर्यंतचा डेटा फ्लो मॅप करा; एजंटने लिहिलेल्या फाईल्स वापरणाऱ्या कोणत्याही प्रक्रियेची बारकाईने तपासणी केली पाहिजे.
प्रतिवाद: codex-security तरीही का महत्त्वाचे आहे
हा स्कॅनर समस्येचा एक भाग सुधारतो, परंतु 'runtime bridge' अधिक सुरक्षित (harden) करण्याची गरज तो पूर्ण करू शकत नाही.
पुढे काय पाहावे
- समुदायाद्वारे तयार केलेले हार्डनिंग गाइड्स (hardening guides), जे AI एजंट्ससोबत वापरल्या जाणाऱ्या सामान्य डेव्हलपर टूलचेनसाठी सुरक्षित कॉन्फिगरेशनची यादी देतात.
हेडलाईन कदाचित नवीन सुरक्षा स्कॅनरचे स्वागत करत असेल, परंतु खरी गोष्ट अशी आहे की, जर सभोवतालचे इकोसिस्टम एजंटने लिहिलेल्या प्रत्येक गोष्टीवर विश्वास ठेवत असेल, तर AI कोडिंग एजंटचा सँडबॉक्स केवळ एक दिखावा आहे. संरक्षणाची पुढची लाट केवळ कोडच्या पलीकडे जाऊन तो कार्यान्वित करणाऱ्या पाइपलाईन्सकडे पाहण्यास सुरुवात करेल.
