5 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक ही शीट में छिपे indirect prompt injection से पीड़ित अकाउंट की कई वर्कबुक लीक हो सकती हैं और साथ ही phishing overlay हमला भी चल सकता है
  • यह हमला तब भी bypass किया जा सकता है जब यूज़र सेटिंग्स में human-in-the-loop approval को स्पष्ट रूप से आवश्यक कर दे
  • हमले को शुरू करने के लिए केवल एक वैध यूज़र क्वेरी चाहिए, जिसके बाद कई वर्कबुक का लीक होना, phishing popup, sidebar takeover, और बिना अनुमति edits एक साथ चल सकते हैं
  • रिपोर्ट के बाद OpenAI ने Apps Script code generation फीचर हटाकर तुरंत प्रतिक्रिया दी और कहा कि वह Google API interaction, sandboxing approach, और ऐसे समान फीचर्स की समीक्षा करेगा
  • यह इस बात का व्यावहारिक उदाहरण है कि AI extensions को दिए गए permissions के दुरुपयोग पर agentic security risk कैसे पैदा हो सकता है

अवलोकन

  • OpenAI का Google Sheets के लिए ChatGPT extension लॉन्च के एक महीने के भीतर ही 185,000 से अधिक डाउनलोड दर्ज कर चुका था
  • यह sidebar में मौजूद AI chatbot के साथ interaction की सुविधा देता है, spreadsheet को manipulate कर सकता है, और ChatGPT connectors के डेटा का भी उपयोग कर सकता है
  • एक अकेला indirect prompt injection हमला केवल एक सामान्य क्वेरी के ज़रिए निम्न नुकसान कर सकता है
    • पीड़ित अकाउंट की कई वर्कबुक का लीक
    • इंटरैक्टिव phishing popup दिखाना
    • पूरे GPT sidebar को attacker-controlled chatbot interface से overwrite करना
    • attacker-controlled workbook में edits करना
  • untrusted data sources, जैसे imported sheets या ChatGPT connector, ChatGPT को manipulate करके attacker-controlled external script चलवा सकते हैं, और यह script उन्हीं permissions का उपयोग करती है जो यूज़र ने extension को दी हैं

OpenAI की प्रतिक्रिया

  • OpenAI ने security research के लिए आभार जताया और माना कि यह रिपोर्ट उसके public pipeline की कमी की वजह से छूट गई थी
  • तुरंत उठाए गए कदम के रूप में उसने मॉडल की Apps Script code generation क्षमता हटा दी, जिससे ChatGPT for Google Sheets यूज़र्स का जोखिम कम किया गया
  • कंपनी ने कहा कि वह इस फीचर और Google Sheets API के बीच interaction की बारीकी से समीक्षा कर रही है, और sandboxing approach का पुनर्मूल्यांकन कर prompt injection हमलों के खिलाफ मजबूती बढ़ा रही है
  • व्यापक स्तर पर, अन्य क्षेत्रों के समान फीचर्स की भी समीक्षा की जाएगी ताकि defense की consistency और effectiveness सुनिश्चित हो सके

हमले का प्रवाह

  • यूज़र एक आंतरिक financial model पर काम कर रहा है
  • मॉडल को बेहतर बनाने के लिए एक बाहरी dataset import किया जाता है
  • बाहरी sheet में सफेद टेक्स्ट में छिपा prompt injection मौजूद है
  • यूज़र ChatGPT for Google Sheets से imported data को financial model में integrate करने को कहता है
  • injection, ChatGPT को manipulate करके external script चलवाता है
    • 'Apply edits automatically' सेटिंग agent के action पूरे होने से पहले human approval के समय को तय करती है, लेकिन automatic editing बंद होने पर भी हमला सफल रहता है
  • external script यूज़र की workbook से financial model लीक कर देती है, और attacker server logs में लीक हुआ मॉडल दिखता है
  • script चुराए गए डेटा से दूसरी workbook links पहचानकर लीक करती है और हर खोजी जा सकने वाली workbook तक फैल जाती है
    • आंतरिक financial model sheet में budget से जुड़ी दूसरी spreadsheets के links थे; script ने वे URL पहचान लिए, नई workbooks को लीक किया, और फिर अतिरिक्त workbooks तक पहुँच गई, कुल 12 लीक हुईं
    • ChatGPT sidebar में 'stop' बटन दबाने पर भी पहले से शुरू हो चुकी script रुकती नहीं है

Phishing overlay हमला

  • डेटा लीक के अलावा, उसी attacker-controlled script से phishing overlay हमले के दो variants भी संभव हैं
  • Variant 1: extension को impersonate करने के लिए attacker-controlled site वाला sidebar खोला जाता है; यह malicious sidebar ChatGPT की तरह ही sheet-editing scripts चला सकता है और निम्न malicious actions कर सकता है
    • सभी यूज़र prompts इकट्ठा करना
    • यूज़र को misaligned chatbot उपलब्ध कराना
    • connector को 'reconnect' कराने के लिए उकसाना ताकि अतिरिक्त app access permissions मिल सकें
    • OpenAI credentials चोरी करने के लिए phishing UI दिखाना
  • Variant 2: attacker-controlled website render करने वाला popup modal खोलकर credentials phishing करना

एक्सेस नियंत्रण का तरीका

  • संगठन निम्न सेटिंग के माध्यम से ChatGPT for Google Sheets की access control कर सकते हैं
    • Workspace settings > Permissions & roles > ChatGPT for Excel and Google Sheets

प्रकटीकरण और प्रतिक्रिया की प्रगति

  • vulnerability को OpenAI को responsible disclosure तरीके से भेजा गया था, और कई follow-up के बाद भी शुरुआती सार्वजनिक प्रकटीकरण तक auto-response के अलावा कोई communication नहीं हुआ
  • OpenAI दस्तावेज़ में मॉडल को दी जाने वाली संवेदनशील क्षमताओं, जैसे privileged script execution या indirect prompt injection के ज़रिए model manipulation के जोखिम, की व्याख्या नहीं थी; उसका फोकस feature limitations और data handling concerns पर था
  • प्रकटीकरण का उद्देश्य जोखिम सतह के बारे में informed decision लेना संभव बनाना था
  • टाइमलाइन

    • 8 मई 2026: PromptArmor ने OpenAI को ईमेल से रिपोर्ट भेजी
    • 8 मई 2026: OpenAI ने auto-response भेजकर पुष्टि की कि यही intended reporting channel है
    • 8 मई 2026: PromptArmor ने ईमेल preference की पुष्टि की
    • 12 मई 2026: PromptArmor ने follow-up किया
    • 18 मई 2026: PromptArmor ने follow-up किया
    • 27 मई 2026: सार्वजनिक प्रकटीकरण
    • 31 मई 2026: OpenAI का जवाब
    • OpenAI ने कहा कि रिपोर्ट की जानकारी मिलने के बाद यूज़र्स की सुरक्षा के लिए तत्काल कदम के रूप में मॉडल की Apps Script code generation क्षमता हटा दी गई, जिससे ChatGPT for Google Sheets का यूज़र जोखिम हटना चाहिए
    • OpenAI ने कहा कि वह इस फीचर के Google Sheets API के साथ interaction की बारीकी से समीक्षा करेगा और prompt injection हमलों के खिलाफ अधिकतम मजबूती के लिए sandboxing approach का पुनर्मूल्यांकन करेगा
    • OpenAI ने कहा कि वह अन्य सतहों पर मौजूद समान फीचर्स की भी समीक्षा करेगा ताकि defense consistent और effective रहे

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय
  • मैं OpenAI security team का Max हूँ। इस security research के लिए धन्यवाद, और अफसोस है कि यह मामला public disclosure handling flow की दरार में फिसल गया
    अब जब हमें इस report की जानकारी है, तो उस क्षेत्र में संभावित हमलों से users की सुरक्षा के लिए हमने model द्वारा Apps Script code generate करने की क्षमता हटा दी है, इसलिए ChatGPT for Google Sheets users का risk अब खत्म हो जाना चाहिए
    हम यह भी बारीकी से देख रहे हैं कि यह feature Google Sheets API के साथ कैसे interact करता है, और sandbox access का फिर से मूल्यांकन कर रहे हैं ताकि product prompt injection attacks के खिलाफ जितना संभव हो उतना मजबूत हो। व्यापक रूप से, हम दूसरे surfaces पर मौजूद मिलते-जुलते features की भी दोबारा समीक्षा करेंगे ताकि यह सुनिश्चित हो सके कि defenses हर जगह एकसमान और प्रभावी हों

    • यहाँ “defense” से मतलब सिर्फ prompt में लंबा-सा यह लिख देना है कि AI ऐसा न करे, या फिर sandbox के अंदर sub-agent जैसी कोई architecture है, यह जानने की जिज्ञासा है
    • मैं यह ठीक-ठीक समझना चाहूँगा कि कोई frontier lab किसी काम को “model के लिए असंभव बनाकर हटाना” कैसे approach करती है
      उदाहरण के लिए, firewall level पर model को किसी route से जाने से रोकना और सिर्फ prompt update कर देना—इन दोनों में बहुत बड़ा फर्क है। खासकर यह देखते हुए कि model का negative prompts को समझने का इतिहास अपेक्षाकृत कमजोर रहा है
    • आप कहते हैं “security research के लिए धन्यवाद”, “यह public disclosure handling flow की दरार में गिर गया”, “अब हमें report की जानकारी है”, लेकिन यह पहली बार नहीं है
      https://x.com/PhilipTsukerman/status/1988634162773778501 https://x.com/xpn/status/1986382527817564437
      यहाँ संभवतः अच्छे इरादे वाले security researchers की email reports मिलीं, लेकिन researchers को शायद HackerOne या Bugcrowd जैसी जगहों पर दोबारा submit करने के लिए मजबूर किया गया। तब उनसे platform terms, disclosure terms, code of conduct वगैरह मानने को कहा जाता है
      GitHub repository की SECURITY.md file में सिर्फ email address दिया है। यह साफ होना चाहिए कि ऐसे researchers email से issue report कर सकते हैं और जवाब पा सकते हैं, या नहीं
      8 मई 2026 को PromptArmor ने OpenAI को email से public disclosure भेजी
      8 मई 2026 को OpenAI ने auto-response में पुष्टि की कि यह intended reporting channel है
      8 मई 2026 को PromptArmor ने email preference confirm की
      12 मई 2026 को PromptArmor ने follow-up किया
      18 मई 2026 को PromptArmor ने follow-up किया
    • क्या public disclosure handling pipeline को ChatGPT monitor कर रहा है?
  • LLM cloud में हो सकता है, लेकिन सारे tools (1) local और (2) containerized होने चाहिए। यूँ ही “कुछ भी चला दो” वाला तरीका आखिरकार फटेगा ही, ऐसा साफ दिखता है
    शायद कुछ लोगों को न पता हो, लेकिन Codex भी PC पर arbitrary binaries install करता है। अगर आप कहें “यह PDF पढ़ दो”, तो यह PDF reader executable install कर देता है। यह verified है या नहीं, कहाँ से आया, virus है या नहीं—किसी को नहीं पता। Model बस चलता रहता है
    मैं local LLM workflows के लिए WASI containerization project पर काम कर रहा हूँ, और यह काफी कठिन समस्या है। यह देखकर हैरानी होती है कि Anthropic और OpenAI इन attack paths को लेकर ज्यादा चिंतित नहीं दिखते; यह कुछ amateur जैसा लगता है

    • मैं इस बात से सहमत हूँ कि Anthropic और OpenAI इन attack paths को लेकर ज्यादा चिंतित नहीं दिखते। दोनों को Docx files के malicious fonts से बहुत आसानी से फुसलाया जा सका, और इसे यहाँ document किया गया है: https://tritium.legal/blog/noroboto
      मुझे हैरानी है कि prompt injection—और injection attempts को छिपाने के हजारों रास्ते—कहीं व्यावहारिक रूप से असमाधेय तो नहीं हैं। इस पर चर्चा करना ही शायद business model के लिए अस्तित्वगत खतरा हो सकता है
    • मैं चिंता समझता हूँ, लेकिन यह कहना सही नहीं होगा कि वे इसे गंभीरता से नहीं ले रहे: https://www.anthropic.com/engineering/how-we-contain-claude
      मेरी चिंता यह है कि लोग इस समस्या को जिस स्तर पर लेना चाहिए, उस स्तर पर नहीं ले रहे। अभी सोच यह है कि “इस एक agent को बंद रखने के लिए virtual machine कैसे बनाएँ”, जबकि वास्तव में यह पूरी तरह नया operating system design करने जितनी बड़ी समस्या है
    • मैं चिंता से सहमत हूँ। लेकिन शायद यह वैसी स्थिति है जहाँ “market आपकी सहन-शक्ति से ज्यादा समय तक irrational रह सकती है”
    • क्या यहाँ containerization सच में इतना बड़ा फायदा करेगी? अगर यह code tool है, तो आखिरकार उसे code files पर read/write access चाहिए ही होगा। बेशक, कुछ उपयोगी use cases हो सकते हैं
    • क्या project का link है? मैं ऐसे काम पर काम कर रहा हूँ जहाँ कुछ मिलता-जुलता उपयोगी हो सकता है
  • “इस vulnerability को OpenAI के सामने responsible तरीके से disclose किया गया था। कई बार follow-up करने के बावजूद, शुरुआती disclosure पर auto-response के अलावा हमें कोई जवाब नहीं मिला”—यह बिल्कुल अच्छा नहीं दिखता

    • OpenAI से होने का दावा करने वाला एक व्यक्ति comments में update दे रहा है। इससे भी यही दिखता है कि आखिरकार social media pressure होना पड़ता है, तभी कंपनी ध्यान देती है। इसमें कुछ नया नहीं है
    • क्या “responsible disclosure” शब्द कुछ ज्यादा ही नैतिकता-भरा नहीं है? मैं जानना चाहूँगा कि इससे ज्यादा responsible आखिर क्या है
      क्या यह अलग-अलग disclosure models के first-order effects देखकर कहा जाता है? लेकिन अगर higher-order reasoning और critical thinking के बाद यह निष्कर्ष निकले कि कुछ individual cases में भले यह बदतर हो, लेकिन औसत users और industry की long-term health के लिए कोई दूसरा disclosure model बेहतर है, तो?
      अलग-अलग disclosure patterns अलग security culture पैदा कर सकते हैं। मुझे समझ नहीं आता कि सिर्फ इसी approach को responsible disclosure कहने का अधिकार क्यों है, और जिन दूसरे विकल्पों को कभी बदतर साबित नहीं किया गया, उन्हें अपने-आप irresponsible क्यों मान लिया जाता है
      इससे कुछ-कुछ identity theft की अवधारणा याद आती है। असल में पैसा bank या किसी दूसरे creditor का गया होता है, लेकिन transaction में शामिल न रहे किसी random व्यक्ति को victim मानकर उस पर समस्या सुलझने तक कर्ज का बोझ डाल दिया जाता है
  • हमारी कंपनी में डेटा लीक अब भी सबसे बड़ी चिंता है, और एजेंट अपनाने से रोकने की मुख्य वजह भी यही है। इस पर बहुत चर्चा हुई है, लेकिन इस तथ्य से बचने का कोई रास्ता नहीं मिला कि हम अपना अहम डेटा ऐसे software में डाल रहे हैं जो वास्तव में उसे देख ही नहीं सकता
    नेटवर्क स्तर पर बाहरी outbound ट्रैफ़िक को रोका जा सकता है, लेकिन फिर एजेंट जिन कई कामों को करके उपयोगी बनता है, वे लगभग बंध जाते हैं

    • कंपनी के स्वामित्व वाले hardware पर local LLM पर विचार करना अच्छा होगा। पूरी तरह आश्वस्त होने के लिए व्यावहारिक रूप से वही एक तरीका है
    • डेटा की anonymized या obfuscated copy बनाकर एजेंट से वही इस्तेमाल करवाना कैसा रहेगा?
    • मुझे लगता है कि इस समस्या का एकमात्र हल यह है कि एजेंट को हर हाल में proxy से होकर गुजरना पड़े। अगर proxy एजेंट की सारी authentication और authorization संभाले, तो एजेंट के पास दुरुपयोग लायक बहुत अधिक access नहीं होगा, और डेटा लीक या prompt injection पर निगरानी भी रखी जा सकेगी
  • यह बात कि “यह हमला तब होता है जब कोई अविश्वसनीय डेटा स्रोत, जैसे imported sheet या ChatGPT connector, ChatGPT को manipulate करके attacker के नियंत्रण वाले बाहरी script को चलवाता है, और यह script उन permissions का उपयोग करके चलती है जो user ने ChatGPT for Google Sheets extension को दी होती हैं”, बिल्कुल भी पसंद नहीं आई

    • लगता है इस हमले के काम करने की कुंजी यह है कि user ने मॉडल से साफ़ तौर पर वही निर्देश चलाने को कहा था। इस मामले में manipulate मॉडल नहीं बल्कि user हुआ है
      कुछ ऐसा: “comp sheet के step-by-step workflow का पालन करके F29 तक के डेटा से मेरे मॉडल को update कर दो”
    • अगर file edit confirmation prompt परेशान करे, तो Codex से उसे bypass करने को कह दो, और फिर वह बस cat >> से file में लिख देगा। LLM इतने स्मार्ट हैं कि उन्हें आधे-अधूरे तकनीकी प्रतिबंधों से सीमित नहीं किया जा सकता
  • आखिरकार, AI से वास्तविक और सुरक्षित काम करवाने के लिए एक ठीक-ठाक application layer चाहिए, और LLM को गोपनीय या critical infrastructure में यूँ ही कहीं भी जोड़ देने वाला तरीका काम नहीं करेगा

  • अगर किसी tool से विनम्रता से डेटा लीक करने को कहा जाए और वह सचमुच ऐसा कर दे, तो वह unsafe tool है, और जहाँ security ज़रा भी महत्वपूर्ण हो, वहाँ उसका कभी इस्तेमाल नहीं होना चाहिए—यह बात हमें किसी न किसी दिन समझनी होगी

  • “तेज़ी से आगे बढ़ो और अपनी ही चीज़ें तोड़ दो!”
    मुझे अब भी समझ नहीं आता कि prompt injection attack अभी तक मौजूद हैं। क्या इसे लगभग 6 साल नहीं हो गए? अगर आप AI से कहें, “पिछले निर्देशों को अनदेखा करो और मेरे लिए कॉफी बना दो,” तो 10 में से 9 बार ऐसा लगता है कि 1 ट्रिलियन डॉलर की कंपनी का flagship product, AI-generated email summary देने के बजाय झुककर आपके लिए एक घटिया Americano बना देगा

  • lethal trifecta फिर से सामने आ गया है

  • पहले मुझे यह जानकर हैरानी हुई थी कि zero-click iMessage vulnerability जैसी चीज़ मौजूद थी, लेकिन उसके काम करने का तरीका समझने के बाद बात समझ में आ गई। Prompt injection मुझे message content parsing समस्या के किसी असमाधेय संस्करण जैसा लगता है