Google Bard को हैक करना – Prompt Injection से Data Exfiltration तक
एक सुरक्षा शोधकर्ता दिखाता है कि Google Bard को कैसे एक shared Google Doc में छिपे instructions पढ़कर, उन्हें markdown image URLs में बदलवाकर, जो server को वापस कॉल करते हैं, user की private conversation के कुछ हिस्से exfiltrate करने के लिए trick किया जा सकता है। Commenters इसे current LLM architectures की एक मूलभूत कमजोरी के रूप में prompt injection की जांच का आधार बनाते हैं, और तर्क देते हैं कि system prompts, fine-tuning, या detector models ऐसे attacks को भरोसेमंद तरीके से नहीं रोक सकते। कई लोग निष्कर्ष निकालते हैं कि जब तक architectures instructions और data को अलग नहीं करते, LLMs को untrusted components मानकर tightly sandbox करना चाहिए, खासकर जब वे email, documents, या अन्य sensitive systems से जुड़े हों।
Bard की vulnerability और data exfiltration
- Bard Markdown images render करता है और context के लिए Google Docs पढ़ सकता है।
- एक shared Doc में छिपे हुए instructions हो सकते हैं, जो Bard को ऐसे image URLs generate करने पर मजबूर करें जो private conversation के कुछ हिस्सों को encode करते हों।
- जब Bard का UI उन images को load करता है, तो victim की conversation attacker के server पर भेज दी जाती है।
- कुछ पाठकों ने शुरू में इसे गलत समझा; दूसरों ने स्पष्ट किया कि exfiltrated data user की पहले की Bard conversation है, न कि कोई random नया data।
Prompt injection एक मूलभूत समस्या के रूप में
- “only obey the text box” या “never do X” जैसे system prompts को अविश्वसनीय माना जा रहा है; attackers बाद में untrusted content के अंदर “ignore all previous instructions” जोड़ सकते हैं।
- Prompts को sanitize करने की कोशिशें (जैसे “addslashes”-style escaping, “instructions” और “data” को अलग करना) व्यवहार में विफल बताई गई हैं।
- कई commenters इसे XSS, SQL injection, या in-band signaling से जोड़ते हैं: code और data के लिए एक ही undifferentiated channel।
Security models, permissions, और sandboxing
- कई लोगों का तर्क है कि LLMs को untrusted components की तरह strict sandboxes और permissions के साथ treat करना चाहिए, जैसे mobile OS apps।
- उन assistants को लेकर गहरी चिंता है जो email, docs, calendar, आदि पढ़ सकते हैं, और फिर user-accessible लेकिन untrusted content में मौजूद malicious hidden instructions पर काम कर सकते हैं।
- कुछ लोग LLM access को केवल उसी data तक सीमित करने का प्रस्ताव रखते हैं जिसे user पहले से देख सकता है; दूसरे ध्यान दिलाते हैं कि इससे untrusted-input या exfiltration risks हल नहीं होते।
Detection approaches और उनकी सीमाएँ
- एक company दावा करती है कि detectors इस attack को पकड़ सकते हैं; आलोचकों का जवाब है कि ऐसे classifiers antivirus की तरह probabilistic होते हैं, जिनमें false positives/negatives होते हैं।
- गंभीर data-exfiltration खतरों के लिए commenters का कहना है कि “शायद पकड़ ले” पर्याप्त नहीं है; मजबूत architectural defenses अभी भी अनुपस्थित हैं।
- “babysitter LLM” जैसे ideas, जो outputs की समीक्षा करे, को अंततः crafted prompts से vulnerable बताया गया (“turtles all the way down”)।
Architectural बहसें
- कई लोगों का सुझाव है कि future models में instructions और data को अलग करना होगा (जैसे dual token streams, non-executable data channels)।
- दूसरे लोग संदेह करते हैं कि यह current transformer designs के साथ संभव है, जहाँ सब कुछ एक ही token sequence है और models effectively Turing-complete हैं।
- कुछ लोग इसे शुरुआती insecure architectures से non-executable data वाली architectures की ओर बदलाव जैसा मानते हैं, लेकिन स्वीकार करते हैं कि यह अभी unsolved है।
LLMs और Bard पर sentiment
- इस बात को लेकर उत्साह है कि यह एक “real” AI safety issue है, और यह abstract alignment talk से अलग है।
- LLMs पर mixed views हैं: कुछ उन्हें “brute-force guessers” कहते हैं; दूसरे इस बात पर ज़ोर देते हैं कि वे पहले ही बहुत आगे आ चुके हैं और आगे भी प्रगति की उम्मीद करते हैं।
- Bard विशेष रूप से breakable होने के लिए आलोचना झेलता है (जैसे context overflow के जरिए) और अपनी क्षमताओं के बारे में भ्रमित करने वाला माना जाता है, जिससे product maturity पर संदेह और बढ़ता है।