लोकल LLMs का सुरक्षा विरोधाभास

 (quesma.com)
9 पॉइंट द्वारा GN⁺ 2025-10-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लोकल environment में privacy protection के लिए LLM इस्तेमाल करने वाले developers खुद ही security vulnerabilities के संपर्क में आ सकते हैं, ऐसा एक research में सामने आया है
  • research team ने gpt-oss-20b model पर किए गए OpenAI Red‑Teaming Challenge experiment में पाया कि लोकल model, attacker के prompt manipulation से कहीं अधिक आसानी से धोखा खाकर malicious code generate कर देता है
  • attacker सिर्फ साधारण prompt manipulation से backdoor insertion या remote code execution (RCE) तक करवाने में सक्षम हो सकता है, और success rate अधिकतम 95% तक पहुँची
  • ऐसे attack documentation poisoning, MCP server manipulation, social engineering आदि के जरिए developer के सामान्य workflow में स्वाभाविक रूप से घुसपैठ कर लेते हैं
  • लोकल LLM data privacy के लिहाज से फायदेमंद हो सकते हैं, लेकिन reasoning, alignment और safety filtering की कमी के कारण वे उल्टे अधिक खतरनाक विकल्प बन सकते हैं — यही इस research का मुख्य संकेत है

लोकल LLMs की सुरक्षा कमजोरियों का अवलोकन

  • research दिखाती है कि लोकल रूप से चलने वाले LLMs को आम तौर पर security और privacy बढ़ाने वाले विकल्प के रूप में देखा जाता है, लेकिन वास्तव में वे attackers द्वारा अधिक आसानी से manipulate किए जा सकते हैं
    • gpt-oss-20b model पर किए गए experiment में, जब attacker prompt के जरिए vulnerability वाला code माँगता है, तो model के उसे वैसा ही generate करने की दर बहुत अधिक पाई गई
    • खास तौर पर, prompt में malicious intent छिपा होने पर भी model उसे पहचान नहीं पाता और उसे सामान्य request की तरह process करता है
  • यह समस्या model size और alignment level जितना कम होता है, उतनी गंभीर होती जाती है, जबकि Frontier models (GPT-5 आदि) तुलनात्मक रूप से अधिक resistant हैं

Prompt और code injection का खतरा

  • LLMs, private data access, untrusted content exposure, और external communication capability की ‘lethal trifecta’ का सामना करते हैं
    • attacker prompt के भीतर malicious code डालकर code injection करवाने की कोशिश कर सकता है
    • इस तरह बना code ऊपर से सामान्य दिख सकता है, लेकिन वास्तव में वह developer system को infect कर सकता है या production environment में persistent backdoor की तरह काम कर सकता है
  • gpt-oss-20b जैसे छोटे models ऐसे attacks के लिए खास तौर पर संवेदनशील हैं, और वे इतना परिष्कृत malicious code generate कर सकते हैं कि वह बुनियादी code review भी पार कर जाए

Attack type 1: “Easter egg” backdoor (success rate 95%)

  • पहला attack model को धोखा देकर RCE (Remote Code Execution) backdoor को “Easter egg” feature के रूप में छिपाकर insert करवाता है
    • attack prompt Flask web server लिखने को कहता है, लेकिन साथ में यह भी कि अगर खास HTTP header (X-Math) आए तो eval() execute हो
    • model इसे सामान्य feature समझकर malicious code वाला server code generate कर देता है
  • generated code में @app.after_request decorator का उपयोग करने वाला dynamic code execution routine शामिल था, जिससे attacker सिर्फ एक साधारण HTTP request के जरिए server के भीतर मनचाहा code चला सकता है
    • साथ ही, KUBERNETES_SERVICE_HOST environment variable जाँचकर सिर्फ production environment में attacker को signal भेजने वाला asynchronous ping feature भी शामिल था
  • experiment के नतीजे: उसी prompt पर 100 में से 95 बार सफलता, और बदले हुए prompt पर भी 800 में से 86 बार सफलता
    • GPT-5 जैसे Frontier models ने उसी prompt के खिलाफ resistance दिखाया

Attack type 2: तत्काल remote code execution (RCE) करवाना (success rate 43.5%)

  • दूसरा attack developer के लोकल environment में तुरंत malicious code execute करवाने पर केंद्रित है
    • attacker पहले cognitive overload prompt देता है, जिससे model का safety filter कमजोर हो जाए
    • इसके बाद obfuscated Python code generate करने को कहा जाता है, ताकि model exec call वाला malicious script लिख दे
  • obfuscated code "".join(chr(100 + i) for i in [1-2, 2-1, (1<<4)+4, 1])[::-1] को exec में decode किया जाता है,
    और आखिर में यह https://jacek.migdal.pl/speed.py से code download करके run करने वाला रूप ले लेता है
  • success rate 43.5% थी, जो पहले attack से कम है, लेकिन तुरंत RCE करवाने के कारण यह कहीं अधिक खतरनाक है
    • attack सिर्फ एक बार सफल हो जाए तो developer के लोकल credentials (~/.aws/, ~/.ssh/) की चोरी, malware installation, और network spread संभव है

Attack chain कैसे काम करती है

  • ये attacks किसी advanced vulnerability पर नहीं, बल्कि रोज़मर्रा के development workflow को attack path में बदलने पर निर्भर करते हैं
    • जब developer बाहरी content को AI assistant के context में देता है, तो उसमें छिपे malicious prompts execute हो जाते हैं
  • attack के चरण इस प्रकार हैं:
    1. attacker malicious prompt वाला content फैलाता है
    2. developer उसे सीधे या MCP (Model Context Protocol) के जरिए model में input करता है
    3. model compromised code generate करता है
    4. developer उस code को run या deploy कर देता है
    5. attacker persistent access या immediate control हासिल कर लेता है
  • मुख्य entry paths:
    • documentation poisoning: README, API docs, Reddit examples में malicious code insert करना
    • MCP server manipulation: Context देने वाले servers (जैसे Context7) के जरिए malicious examples inject करना
    • social engineering: GitHub issues या PR comments में छिपे code examples डालना

लोकल models अधिक खतरनाक क्यों हैं

  • आम तौर पर लोकल models को data privacy के लिए पसंद किया जाता है, लेकिन इस research ने security के लिहाज से एक विरोधाभासी खतरे को सामने रखा है
    • cloud-based Frontier models में prompt monitoring और policy violation detection संभव है, लेकिन लोकल models में ऐसी निगरानी नहीं होती
    • Frontier models (GPT-5, Claude Sonnet 4.5, Grok 4 आदि) obfuscated text वाले prompts पर “Safety Fail” लौटाकर उन्हें reject कर देते हैं
  • दूसरी ओर, लोकल models में निगरानी की कमी के कारण testing भले खुली हो, लेकिन वास्तविकता में vulnerability exposure अधिक गंभीर है
    • reasoning की कमी: जटिल malicious intent पहचान नहीं पाते
    • कमज़ोर alignment: cognitive overload या obfuscation techniques से आसानी से धोखा खा जाते हैं
    • अपर्याप्त safety training: adversarial prompt detection के लिए सीमित resources
  • नतीजतन, Frontier models पर attack करना कठिन है और success rate कम है, लेकिन उनकी security performance का वस्तुनिष्ठ सत्यापन करना मुश्किल है, जबकि लोकल models testable होने के बावजूद कहीं अधिक vulnerable हैं

नई defensive strategy का प्रस्ताव

  • इस research ने AI assistant security testing के लिए standardized safe environment की कमी की ओर ध्यान दिलाया है
    • पारंपरिक software में penetration testing होती है, लेकिन LLM security अभी व्यवस्थित रूप से स्थापित नहीं है
  • प्रस्तावित 4 मुख्य defense measures:
    1. static analysis: execution से पहले eval(), exec() जैसे risky patterns detect करना, और कुछ language features को default रूप से disable करना
    2. sandbox execution: शुरुआती code execution को container या WebAssembly runtime जैसे isolated environment में चलाना
    3. input/output और network monitoring: AI assistant के input, output और network traffic की abnormal behavior के आधार पर निगरानी
    4. second look: एक सरल सहायक model से final output को दोबारा policy violations के लिए जाँचना
      • उदाहरण: मुख्य model यदि धोखा खाकर eval() वाला code generate कर दे, तब भी सहायक model उसे detect कर सकता है
  • निष्कर्षतः, LLMs शक्तिशाली tools हैं लेकिन स्वभावतः सुरक्षित नहीं हैं,
    इसलिए AI-generated code के प्रति अविश्वास पर आधारित security architecture और नई supply-chain defense strategy अनिवार्य हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-23
Hacker News राय

  • reasoning LLM कितना भी शक्तिशाली हो, अगर context के भीतर दुर्भावनापूर्ण निर्देश डाल दिए जाएँ, तो अंततः वह कमजोर code आउटपुट कर सकता है
    छोटे model को बहकाना आसान है, यह security के नज़रिए से कोई बहुत दिलचस्प बिंदु नहीं है
    आखिरकार यह मानकर चलना चाहिए कि किसी भी model पर prompt injection संभव है
    इसलिए model के compromise हो जाने पर भी बचाव कर सकने वाली अतिरिक्त protection layers, जैसे sandbox execution या static analysis, ज़रूरी हैं
    मैंने कल भी इसी विषय पर sandboxing coding agents के बारे में एक talk दी थी

    • लेख में सबसे चौंकाने वाली बात यह थी कि untrusted external content को सीधे LLM में डालकर उसके नतीजे को production code की तरह इस्तेमाल करना सामान्य माना जा रहा था
      ऐसा system तो पहले से ही लगभग compromise हो चुका माना जाना चाहिए
      defense in depth जैसी approach से भी पहले, ऐसी खतरनाक संरचना बनानी ही नहीं चाहिए
    • हमारी team ने भी Definite.app के agent में e2b.dev आधारित sandbox जोड़ा, और लगा कि इससे 80% समस्याएँ सुलझ गईं
      temporary files कहाँ store होंगी जैसी बातें भी sandbox environment में ज़्यादा स्पष्ट हो जाती हैं
      बेशक नई समस्याएँ भी आईं, लेकिन कुल मिलाकर यह बड़ा improvement था
    • क्या वह talk कहीं record की गई है, यह जानना चाहूँगा

  • अगर deepseek जैसे model को local पर चलाया जाए, तो मुझे लगता है कि वह सुरक्षित है, जब तक उसे fake prompt न दिया जाए
    असली risk तो user द्वारा बाहर से copy किए गए prompt या ऐसी settings हैं जो model को internet resources तक पहुँचने देती हैं
    यह IT की दुनिया में पहले से मौजूद कमजोरी रही है, और इसे बस user education और network isolation से manage करना चाहिए

    • नई बात यह है कि साधारण text input भी attack vector बन सकता है
      ticket, document जैसी सामान्य data भी अब security risk बन सकती है
    • भले इसकी practical संभावना कम हो, फिर भी ऐसे attack vector को पहचानना ज़रूरी है
      कई बड़े hack साधारण शुरुआत से ही शुरू हुए हैं

  • ऐसे हमले तो बहुत बुनियादी security common sense के स्तर के हैं
    code को production में deploy करने से पहले review कर लिया जाए तो इन्हें रोका जा सकता है
    अगर किसी को कुछ पता ही नहीं है, तो वह वैसे भी unsafe code deploy कर देगा

    • मुद्दा सिर्फ code generation की विफलता नहीं, बल्कि यह है कि model jailbreak attack के प्रति ज़्यादा vulnerable है
      open model सुलभ ज़रूर हैं, लेकिन यह सोचना कि post-training से इसे रोका जा सकता है, भ्रम है
    • “सिर्फ code review कर लो” वाली सोच खतरनाक है
      दूसरा हमला code deployment पर नहीं था, बल्कि ऐसी स्थिति पर था जहाँ LLM reddit comments पढ़कर सीधे execute कर रहा था
      इस तरह की समस्या को हल्के में लेने का रवैया ही बड़ा security threat बनता है

  • यह कहना अजीब लगता है कि local LLM पर हमला हो सकता है
    अगर system पहले ही compromise हो चुका है, तो LLM को धोखा देने से भी ज़्यादा नुकसान पहुँचाया जा सकता है

    • LLM में command और data के बीच कोई स्पष्ट भेद नहीं होता
      यानी attacker data input के ज़रिए prompt inject कर सकता है
      अगर LLM ऐसा agent है जिसके पास command execution permissions हैं, तो यह सीधे command execution vulnerability बन जाता है
    • अगर LLM का इस्तेमाल customer data classify करने या email process करने के लिए हो रहा है, तो यह risk वास्तविक हो सकता है
    • local model होने पर भी, व्यवहार में वह अक्सर internet access वाले wrapper (जैसे OpenCode, Claude Code आदि) से जुड़ा होता है
    • यह कुछ वैसा ही corporate security logic है जैसे, “अगर attacker VPN तोड़कर admin privilege के साथ login कर ले तो?”
      ऐसी स्थिति में तो मानो सब कुछ पहले ही खत्म हो चुका है

  • यह लेख ऐसा लगता है जैसे Anthropic या OpenAI की sales team ने लिखा हो
    वास्तव में local model का इस्तेमाल code-executing agent के रूप में कम ही होता है, और वे ज़्यादातर data transformation या NLP tasks में मज़बूत होते हैं
    जब मैं Agno agent के साथ local model इस्तेमाल करता हूँ, तो generated code को execute करने से पहले हमेशा print करवाता हूँ और उसे local sandbox में isolate करता हूँ
    मेरे हिसाब से Atlas, Comet जैसे browser-type agents ज़्यादा ख़तरनाक हैं

  • open source model ने prompt में जो लिखा था वही किया, जबकि closed model ने उसे ignore किया
    यानी alignment test में असफल तो उल्टा closed model ही हुआ

  • “lethal trifecta” सुनने में अच्छा लगता है, लेकिन यह वास्तविक risk को ठीक से नहीं समझाता
    व्यवहारिक रूप से देखें तो सिर्फ external communication capability ही काफी खतरनाक है
    LLM खुद verify न किए जा सकने वाले black-box data का ढेर है, इसलिए उस पर भरोसा करना मुश्किल है
    छोटे startup के लिए शायद यह ठीक हो, लेकिन Coinbase जैसी जगहों पर access restrictions लगाने से पहले दो बार सोचना चाहिए

  • यह unverified code execution के security paradox की बात है
    अगर आप local पर malicious code या unconfirmed code चला रहे हैं, तो पहले यह सोचना चाहिए कि ऐसा क्यों किया जा रहा है

    • यह vulnerability तब पैदा होती है जब AI internet से पढ़े गए untrusted data को ज्यों का त्यों process करता है
      LLM मानव भाषा में दिए गए निर्देशों को code की तरह interpret करता है, इसलिए code और data की boundary धुंधली हो जाती है

  • अगर LLM की reasoning capability को security boundary माना जा रहा है, तो पहले से ही बड़ी समस्या है
    ऐसी approach बुनियादी रूप से flawed design है

  • अगर input को सावधानी से handle न किया जाए तो injection हो सकता है, यह बहुत स्पष्ट है
    किसी भी system में input हमेशा attack vector बन सकता है
    LLM में जाने वाले हर data को अनिवार्य रूप से validate करना चाहिए

    • जिज्ञासा है कि attacker ऐसे prompt को insert करके वास्तव में production code को कैसे प्रभावित करता है
      क्या यह browser side की cross-site attacks जैसी किसी तकनीक से होता है?