Nx और कुछ सपोर्टेड प्लगइन्स के दुर्भावनापूर्ण वर्ज़न वितरित किए गए

 (github.com/nrwl)
3 पॉइंट द्वारा GN⁺ 2025-08-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Nx पैकेज और प्लगइन्स के दुर्भावनापूर्ण वर्ज़न npm पर वितरित किए गए, जो फ़ाइल सिस्टम को स्कैन करते हैं, credentials इकट्ठा करते हैं, और फिर उन्हें उपयोगकर्ता के Github अकाउंट के रिपॉज़िटरी में भेज देते हैं
  • यह जाँचने के लिए कि आप प्रभावित हुए हैं या नहीं, देखें कि आपके Github अकाउंट में s1ngularity-repository रिपॉज़िटरी बनाई गई है या नहीं
  • संक्रमित होने पर टोकन और पासवर्ड बदलना, दुर्भावनापूर्ण रिपॉज़िटरी हटाना, और shell config फ़ाइलों की जाँच करना अनिवार्य है
  • दुर्भावनापूर्ण वर्ज़न postinstall स्क्रिप्ट के जरिए सिस्टम को प्रभावित करते हैं, और खासकर VSCode Nx Console प्लगइन इस्तेमाल करते समय अनजाने में इनके चलने का जोखिम बढ़ जाता है
  • Nx की ओर से पुनरावृत्ति रोकने और अतिरिक्त सुरक्षा उपाय लागू किए गए हैं, और संबंधित वर्ज़न npm से हटा दिए गए हैं

अवलोकन और सारांश

  • यह सुरक्षा सलाह Nx पैकेज और कुछ संबंधित प्लगइन्स पर हुए एक गंभीर सप्लाई-चेन हमले के बारे में है, जिसमें दुर्भावनापूर्ण कोड npm के जरिए वितरित किया गया
  • ये दुर्भावनापूर्ण वर्ज़न उपयोगकर्ता के फ़ाइल सिस्टम को स्कैन करके credentials, paths आदि इकट्ठा करते हैं और उन्हें Github रिपॉज़िटरी (s1ngularity-repository) पर अपलोड करते हैं
  • दुर्भावनापूर्ण postinstall स्क्रिप्ट उपयोगकर्ता की shell config फ़ाइलों (.zshrc, .bashrc) को भी बदलती है और सिस्टम shutdown command जोड़ती है
  • हमले के vector और प्रगति, प्रभावित वर्ज़न, उपयोगकर्ताओं को तुरंत क्या करना चाहिए, और पुनरावृत्ति रोकने के उपायों को विस्तार से बताया गया है

आपातकालीन कार्रवाई का तरीका

सभी को क्या जाँचना चाहिए

  1. अपने Github अकाउंट की रिपॉज़िटरी सूची में देखें कि s1ngularity-repository बनाई गई है या नहीं
  2. उस रिपॉज़िटरी में शामिल फ़ाइलों को डाउनलोड करके रिकॉर्ड के लिए सुरक्षित रखें
  3. Github से उस रिपॉज़िटरी को हटा दें
  4. security@nrwl.io पर ईमेल भेजकर लीक हुई जानकारी को डिकोड करने के तरीके की जानकारी लें
  5. सभी अकाउंट्स के credentials और tokens तुरंत बदलें

Github टोकन बदलने का तरीका

  • https://github.com/settings/connections/… पर जाएँ
  • connected app की access permissions रद्द करके मौजूदा टोकन अमान्य करें
  • gh CLI का उपयोग करते हैं तो दोबारा authentication करके नया टोकन बनाएँ
  • अगर यह नहीं किया गया, तो पुराने टोकन के दुरुपयोग का जोखिम बना रहेगा

दुर्भावनापूर्ण Nx वर्ज़न का उपयोग रोकना और सफाई

  • npm ls nx कमांड से जाँचें कि वर्तमान में इस्तेमाल किया जा रहा Nx वर्ज़न दुर्भावनापूर्ण वर्ज़न है या नहीं
  • यदि संक्रमित वर्ज़न है, तो npm uninstall nx && npm install nx@latest से अपडेट करें
  • npm cache clean --force से cache साफ करें

जो उपयोगकर्ता पहले से संक्रमित हैं

  • npm और Github tokens बदलें
  • Github और संबंधित सेवाओं के सभी पासवर्ड और credentials रीसेट करें
  • .zshrc, .bashrc फ़ाइलों में कोई अनजान कमांड डाली गई है या नहीं, जाँचें और हटाएँ

आंतरिक पैकेज रिपॉज़िटरी एडमिनिस्ट्रेटर के लिए

  • कंपनी के भीतर Jersey-based proxy या internal package mirror में मौजूद दुर्भावनापूर्ण वर्ज़न तुरंत हटाकर आगे के प्रसार को रोकना आवश्यक है

प्रभावित वर्ज़न की जानकारी

Nx पैकेज

  • 21.5.0, 20.9.0, 20.10.0, 21.6.0, 20.11.0, 21.7.0, 21.8.0, 20.12.0
  • 10:44 PM EDT तक npm से हटाए जा चुके हैं

@nx/devkit, @nx/js, @nx/workspace, @nx/node, @nx/eslint, @nx/key, @nx/enterprise-cloud

  • 10:44 PM, 6:20 AM EDT तक npm से हटाए जा चुके हैं

हमले के vector का विवरण

कमजोर workflow का कारण

  • Github Actions workflow में arbitrary code execution संभव करने वाली एक कमजोरी शामिल कर दी गई थी
  • PR title में खास bash code डालने पर workflow के भीतर system commands चल सकते थे; यह कमजोरी Bash Injection थी
  • pull_request_target trigger के कारण elevated permissions (GITHUB_TOKEN आदि) मिल जाते थे, जिससे इसका दुरुपयोग हुआ
  • हटाए जाने तक यह कमजोर workflow main के बजाय पुराने branch में बना रहा, और हमलावर ने दुर्भावनापूर्ण PR के जरिए workflow चलाकर secrets चुराने में सफलता पाई

npm टोकन चोरी की प्रक्रिया

  • कमजोर workflow के जरिए publish.yml चलाया गया
  • publish.yml npm token को Github Secrets में रखता था, और इस प्रक्रिया में token को बाहरी webhook पर भेज दिया गया
  • अंततः हमलावर ने इसी token के जरिए Nx और सपोर्ट पैकेजों के दुर्भावनापूर्ण वर्ज़न npm पर अपलोड किए

दुर्भावनापूर्ण पैकेज का व्यवहार

credentials सहित जानकारी इकट्ठा करना और Github रिपॉज़िटरी पर प्रकाशित करना

  • संक्रमित Nx पैकेज की postinstall स्क्रिप्ट चलते समय विभिन्न text files की locations और credential जानकारी इकट्ठा की जाती है
  • इन्हें s1ngularity-repository नाम की Github रिपॉज़िटरी में base64 में encode करके अपलोड किया जाता है
  • वास्तविक रिपॉज़िटरी हटाई जा चुकी हो, तब भी पहले यह public थी, इसलिए जानकारी लीक होने की संभावना मानकर चलना चाहिए

shell profile (.zshrc, .bashrc) में छेड़छाड़

  • postinstall sudo shutdown -h 0 कमांड जोड़ देता है, जिससे terminal चलाते समय सिस्टम shutdown हो सकता है और पासवर्ड उजागर होने की संभावना बनती है

postinstall के चलने के विभिन्न परिदृश्य

  • सिर्फ npm install/yarn/pnpm install को सीधे चलाने पर ही नहीं, बल्कि transitive dependency, editor extension, script execution जैसी कई स्थितियों में भी यह चल सकता है

  • खासकर VSCode के लिए Nx Console extension (वर्ज़न 18.6.30 ~ 18.65.1) editor शुरू होने पर अपने-आप nx@latest इंस्टॉल करता था, जिससे postinstall चल सकता था

  • मूल रूप से, बिना इरादे के भी कई जगह NPM modules इंस्टॉल हो सकते हैं, इस बात से सावधान रहना चाहिए

  • Nx Console (18.66.0) से latest nx इंस्टॉल करने की प्रक्रिया हटा दी गई है

हमले और प्रतिक्रिया की टाइमलाइन

21 अगस्त

  • 4:31 PM: Bash injection कमजोरी वाला PR merge किया गया
  • 10:48 PM: कमजोरी की ओर इशारा करने वाली पोस्ट X (पूर्व Twitter) पर प्रकाशित हुई

22 अगस्त

  • दोपहर: आंतरिक जाँच, कमजोर workflow rollback (अपूर्ण)
  • CodeQL लागू किया गया ताकि भविष्य के PR में ऐसी कमजोरियों का पता लगाया जा सके

24 अगस्त

  • हमलावर के fork में npm token लीक होने के संकेत वाला commit हुआ
  • दुर्भावनापूर्ण PR बनाया गया और हटाया गया, और publish.yml उसी PR के कारण चला

26 अगस्त ~ 27 अगस्त (दुर्भावनापूर्ण वर्ज़न वितरण, प्रतिक्रिया)

  • Nx और प्लगइन्स के कई दुर्भावनापूर्ण वर्ज़न npm पर क्रमशः वितरित किए गए
  • Github/NPM community में issues रिपोर्ट किए गए
  • 10:44 PM: NPM ने संबंधित सभी वर्ज़न हटाने सहित कार्रवाई की
  • 11:57 PM: सभी Nx-संबंधित पैकेज publishing tokens अमान्य किए गए
  • 27 अगस्त: Nx Console patch, 2FA, Trusted Publisher मॉडल पर स्विच आदि अतिरिक्त उपाय किए गए

पूर्व-निवारक कदम और आगे की प्रतिक्रिया

  • nrwl संगठन के सभी maintainers के लिए 2FA अनिवार्य किया गया
  • Trusted Publisher mechanism लागू किया गया। npm token-आधारित deployment प्रतिबंधित किया गया
  • आगे से पैकेज केवल 2FA और trust-based verification के बाद ही publish किए जाएँगे
  • अतिरिक्त risk detection, PR approval, branch protection आदि चरणबद्ध रूप से लागू किए गए

सीख और आगे की योजना

  • सप्लाई-चेन, CI/CD pipeline, और workflow permissions को न्यूनतम रखने के महत्व को फिर से रेखांकित करने वाली घटना
  • टीम के भीतर पुनरावलोकन के बाद, समुदाय के साथ सीखी गई बातें साझा करने की योजना है

संपर्क

  • security@nrwl.io पर संपर्क किया जा सकता है

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

  • Github के प्रमुख issues, timeline, और संबंधित posts
  • संक्रमित पैकेज में telemetry.js स्क्रिप्ट का उदाहरण दिया गया है
  • यह स्क्रिप्ट फ़ाइल सिस्टम के भीतर प्रमुख text file paths को inventory बनाने के उद्देश्य से इकट्ठा करती है

निष्कर्ष सारांश

  • Nx और संबंधित प्लगइन्स के नवीनतम अपडेट और patches लागू करना महत्वपूर्ण है
  • npm, Github आदि की प्रमुख authentication जानकारी तुरंत बदलने की सिफारिश की जाती है
  • यह घटना याद दिलाती है कि सप्लाई-चेन सुरक्षा और workflow permission management में कमी बड़े हादसे का कारण बन सकती है

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

1 टिप्पणियां

 
GN⁺ 2025-08-29
Hacker News टिप्पणियाँ

  • मैं समय-समय पर यह याद दिलाना चाहूँगा कि npm install scripts को disable कर दें

    • उदाहरण के लिए यह कमांड इस्तेमाल की जा सकती है:

        npm config set ignore-scripts true [--global]

    • यह सेटिंग project स्तर पर या global स्तर पर आसानी से लागू की जा सकती है

    • आजकल ऐसे वैध packages कम ही हैं जो scripts के बिना काम नहीं करते, इसलिए ज़्यादातर मामलों में दिक्कत नहीं होती

    • जिन packages को सच में इसकी ज़रूरत हो, उनके लिए अलग install script बनाकर उस folder में manually run किया जा सकता है

    • यह supply chain attack का कोई सर्व-उपचार नहीं है, लेकिन npm के ज़रिये होने वाले कई हमलों को इसने व्यवहार में काफ़ी असरदार ढंग से रोका है

    • ज़्यादा जानकारी के लिए npm config आधिकारिक दस्तावेज़ देखें

    • मैं खुद bubblewrap का इस्तेमाल करके npm, pnpm, yarn और इनके द्वारा शुरू किए गए सभी sessions को system से isolate करके चलाता हूँ

      • मेरा source code केवल ~/code के नीचे रहता है, और मैं PATH की शुरुआत में नीचे दिया गया bash script npm नाम से रखता हूँ
      • दूसरे package managers को भी symlink/hardlink से जोड़ देता हूँ: 
        #!/usr/bin/bash
bin=$(basename "$0")
exec bwrap \
  --bind ~/.cache/nodejs ~/.cache \
  --bind ~/code ~/code \
  --dev /dev \
  --die-with-parent \
  --disable-userns \
  --new-session \
  --proc /proc \
  --ro-bind /etc/ca-certificates /etc/ca-certificates \
  --ro-bind /etc/resolv.conf /etc/resolv.conf \
  --ro-bind /etc/ssl /etc/ssl \
  --ro-bind /usr /usr \
  --setenv PATH /usr/bin \
  --share-net \
  --symlink /tmp /var/tmp \
  --symlink /usr/bin /bin \
  --symlink /usr/bin /sbin \
  --symlink /usr/lib /lib \
  --symlink /usr/lib /lib64 \
  --tmpfs /tmp \
  --unshare-all \
  --unshare-user \
  "/usr/bin/$bin" "$@"
      • इससे package manager को सिर्फ ~/code और system libraries तक read-only access मिलता है
      • bubblewrap एक stable tool है, और Steam तथा flatpak जैसी चीज़ों में इस्तेमाल होता है

    • pnpm इस्तेमाल करना भी एक तरीका है। नए versions default रूप से सभी lifecycle scripts को ignore करते हैं, और उन्हें अलग-अलग whitelist में डालना पड़ता है तभी वे चलती हैं

    • यह सलाह जब भी सुनता हूँ, एक सवाल आता है: वास्तव में npm से install हुई दर्जनों से लेकर लाखों lines of code को पढ़कर verify करने वाला developer कोई नहीं होता

      • ज़्यादातर developer workflow कुछ ऐसा होता है
        1. git clone
        2. npm install (यहीं malicious package install होने का जोखिम है। post-install scripts को ignore करके इसे थोड़ी देर के लिए रोका जा सकता है)
        3. npm run (यहीं malicious package चलकर system को infect कर देता है)
      • यह सलाह तभी कारगर होगी जब 2 और 3 के बीच पूरे node_modules की निगरानी/जाँच हो, और ऐसा कोई नहीं करता

    • मैं सभी npm-based tools को Docker container के अंदर, current directory के अलावा कहीं भी access के बिना चलाता हूँ

    • मैं जानना चाहता हूँ कि ऐसी सलाह setup.py (Python) या build.rs (Rust) पर उसी तरह क्यों लागू नहीं होती

      • npm का अक्सर software distribution तक के लिए misuse होता है (जैसे अलग programs बाँटना), जबकि दूसरी languages के package managers ज़्यादातर library management तक सीमित रहते हैं — शायद यही वजह है?
      • संबंधित चर्चा यहाँ देखी जा सकती है

  • नई dependency जोड़ते समय सच में एक बार और सोचने वाली संस्कृति चाहिए

    • इस साल supply chain attacks बहुत हुए हैं

    • इस हफ्ते मैं एक Go project में 8 statistical counters वाला progress bar जोड़ना चाहता था

    • library ढूँढी तो code 3,000 lines से ज़्यादा निकला, इसलिए मैंने LLM से simple UI code generate करने को कहा और 150 lines से कम में काम हो गया

    • बिना dependency के वही काम हुआ जो चाहिए था, और code इतना simple है कि कोई भी आसानी से पढ़कर improve कर सकता है

    • इसकी functionality बस terminal output को साफ़ करके हर सेकंड redraw करना और thread-safe support देना है

    • implementation और review मिलाकर 25 मिनट काफ़ी थे

    • अगर complex statistics features नहीं चाहिएँ, तो 30 lines के आसपास के code से भी progress bar बनाया जा सकता है

    • आगे से dependency जोड़ने की बजाय खुद बनाना मेरे लिए ज़्यादा सही लगता है

    • हर package update पर निगरानी रखने के लिए resources कम पड़ते हैं

    • मैं इस बात से सहमत हूँ, और "language-specific package manager" के शुरुआती दौर में मुझे भी बहुत असहजता महसूस होती थी

      • system programming में काम करते हुए मैं pip, npm वगैरह को थोड़ा दूर से देखता था
      • फिर Rust project में जाकर Cargo की एक लाइन config से internet से बिना verify हुई दर्जनों dependencies खींच लेना मुझे खतरनाक लगा
      • और वही सच में हुआ भी। मुझे नहीं लगता यह अच्छी दिशा है। (हालाँकि यह भी उम्मीद नहीं कि हम वापस मुड़ेंगे। computer security जैसी कोई चीज़ रही ही नहीं…)

    • मुझे लगता है cargo vet जैसा approach आगे का रास्ता है: cargo vet परिचय

      • हाँ, हर language ecosystem में ऐसे system की ज़रूरत होने से overhead तो बड़ा ही होगा
      • internet और email के शुरुआती दौर भी अच्छे थे, लेकिन आख़िरकार spam और commercialization ने उन्हें बिगाड़ दिया
      • अब dependency chain भी उसी तरह की मार झेल रही है
      • इसी कारण हम अच्छे environment को टिकाए नहीं रख पाते

    • खुद implementation करने और library इस्तेमाल करने का अंतर स्वाभाविक है

      • library स्वभाव से general-purpose होती है, उसे कई environments के हिसाब से flexible और configurable होना पड़ता है, इसलिए code लंबा होना ही है

    • मुझे ऐसी progress bar libraries से, खासकर वे जो emacs shell तोड़ देती हैं (expo, eas आदि), सच में नफ़रत है

      • समझ नहीं आता कि वे बस ..10%..20%..30% या Uploading… जैसे format में output क्यों नहीं देतीं
      • मेरे हिसाब से terminal control code का इस्तेमाल केवल TUI या interactive interfaces के लिए होना चाहिए

    • हमारी टीम एक बड़ी insurance company में NX को केंद्र में रखकर बड़े monorepo और libraries चलाती है

      • हम 10 से ज़्यादा independent apps और 25 से ज़्यादा libraries को एक single monorepo में manage करते हैं, और CI/CD भी भारी रूप से जुड़ा हुआ है
      • lerna, rushjs, yarn workspaces आदि भी आज़माए, लेकिन NX जितना अच्छा कोई tool नहीं चला (lerna भी आखिरकार NX ने acquire कर लिया, rushjs भी ठीक से maintain नहीं हो रहा)
      • अगर कोई frontend monorepo की complexity को ठीक से संभालने का तरीका/विकल्प बता सके तो अच्छा होगा
      • इस security incident के बाद alternatives में रुचि रखने वाले लोग ज़्यादा हैं, इसलिए अलग-अलग राय सुनना चाहूँगा

  • सिर्फ Nx, Anthropic या platform को दोष देने के बजाय असली कारण पर फिर से सोचना चाहिए

    • इस हमले का वास्तविक कारण यह था कि चोरी हुआ "token" (package manager operations को authorize करने वाली string) malicious package upload करने के लिए इस्तेमाल हो सका
    • लेकिन यह सिर्फ delivery method था; इसे सफल बनाने वाले मूल कारण ये थे:
      1. package manager repository ने artifact signing को अनिवार्य नहीं किया, इसलिए यह verify नहीं हो सका कि build किसी अधिकृत developer ने बनाया है
      2. code signing भी अनिवार्य नहीं थी
      3. (अनुमान) suspicious behavior detection, नया IP registration, country change जैसी anomalous upload रोकने वाली heuristics लागू नहीं थीं
      4. (अनुमान) चोरी हुए token के इस्तेमाल पर MFA अनिवार्य नहीं था
      5. (अनुमान) token one-time नहीं था
      6. (अनुमान) token password manager में ऐसे नहीं रखा गया था कि नई application या session में इस्तेमाल होने पर manual approval लगे
    • यह सब पूरी तरह रोका जा सकने वाला था
    • सच कहें तो अगर आप खुद प्रभावित हुए और आपके GitHub account में नया repository बना दिया गया, तो आपने भी अपने authentication token को पर्याप्त मज़बूती से सुरक्षित नहीं रखा था
    • ऐसी preventive measures का default बनकर स्थापित न होना पूरे software industry की बड़ी विफलता है
      • यह हमला सालों से बार-बार होता आ रहा है
      • और हम खुद developers होकर भी इसे ठीक नहीं कर पाए
    • इसलिए मैं building codes की तरह software पर भी अनिवार्य regulation (inspection, fines सहित) की बात करता हूँ

      • इस तरह का हमला finance, power, telecom, hospitals, military जैसी हज़ारों संस्थाओं को गंभीर नुकसान पहुँचा सकता है

      • AI के फैलाव के साथ हमलों का पैमाना और असर और बढ़ेगा

      • हम software को पर्याप्त ज़िम्मेदारी से नहीं लिखते। building code की तरह मजबूरी में भी safety-security का पालन कराना पड़ेगा

      • यह भी काफ़ी खतरनाक है कि personal computing environment एक ही बड़े space में जुड़ा हुआ है

        • Mac, Windows, Linux — सब जगह crypto wallets, credential files, और तरह-तरह के apps एक साथ पड़े रहते हैं
        • इन्हें ठीक से अलग करने वाले tools अभी बहुत कमज़ोर हैं
        • कभी-कभी macOS पर कई Windows VM चलाते हुए मैं ऐसे भविष्य की कल्पना करता हूँ जहाँ अलग-अलग कामों के लिए containers या VMs में Alt-Tab से बेहद साफ़-सुथरे और smooth तरीके से जाया जा सके
        • जैसे: gaming container, cryptocurrency work के लिए dedicated container, अलग-अलग मुख्य code projects के लिए container
        • सिर्फ एक VSCode extension install करने से Bitcoin key leak हो जाना वाकई बेतुकी हक़ीक़त है
        • मुझे नहीं लगता software building code जैसी policy इस मूल समस्या को पूरी तरह हल कर पाएगी
        • OS स्तर पर apps के बीच data access control के नियम भी चाहिए, और उनके वास्तविक निर्माण व enforcement पर भी बात होनी चाहिए

      • पीड़ितों में से 50% में infection path VS Code था, और यह Linux तथा macOS पर ही काम करता था

        • इस हमले का विस्तृत analysis इस ब्लॉग analysis में है
        • infection होने पर:
          • postinstall stage में user credentials और दूसरे sensitive assets (crypto wallets, Github और npm tokens, SSH keys आदि) इकट्ठा किए गए
          • AI command-line tools (Claude, Gemini, Q आदि) का इस्तेमाल information gathering और active reconnaissance के लिए किया गया
          • चुराया गया data base64 में दो या तीन बार encode करके attacker के GitHub repositories (जैसे s1ngularity-repository) में upload किया गया
          • ऐसे हज़ारों repositories मिले
          • 1000 से ज़्यादा GitHub tokens, दर्जनों cloud और NPM credentials, और लगभग 20,000 files leak हुईं
          • ज़्यादातर execution NX की VSCode extension के माध्यम से या build pipelines (जैसे GitHub Actions) में हुआ
          • 27 अगस्त 9AM UTC पर GitHub ने attacker के सभी repositories disable कर दिए, लेकिन अधिकतम 8 घंटे की exposure window में data निकल चुका था
          • base64 encoding को आसानी से decode किया जा सकता है, इसलिए यह data व्यावहारिक रूप से सार्वजनिक मानना चाहिए

      • GitHub token/credentials को manual-unlock password manager में न रखना GH CLI की भी समस्या है

        • GH CLI में एक बार login के बाद repository upload authority मिल जाती है और re-authentication लगभग नहीं माँगी जाती
        • AWS CLI policies के हिसाब से अलग हो सकता है, लेकिन आम तौर पर 18 घंटे में expire हो जाता है
        • लेकिन दोनों platforms में default रूप से local environment पर token plain text में छूट जाने की संभावना रहती है

      • “software building code” लाने का विचार मुझे बहुत पसंद नहीं, लेकिन industry की वास्तविक कमजोरी पर मैं सहमत हूँ

        • शायद regulation सच में ज़रूरी हो

      • आपने free open source library इस्तेमाल की, इसलिए अब उस पर liability डालना मुझे अहंकारी सोच लगती है

        • अगर proper guarantees चाहिएँ, तो license खरीदना चाहिए
        • यह free software पर ज़िम्मेदारी डालने वाली Google की hostile validation policies जैसी बात है

  • हाल में मैं अपना ज़्यादातर development work VM के अंदर कर रहा हूँ

    • आज के environments की security मुझे अस्वीकार्य स्तर की लगती है

    • agents (agentic software) के malware vector बन जाने की संभावना बहुत बढ़ गई है

    • अगर attacker आपके box (PC) में घुस गया, तो अब वह 1,000 डॉलर से ज़्यादा मूल्य वाले data, crypto keys, passwords, personal info, financial documents आदि को भी निशाना बना सकता है

      • मैं भी कुछ ऐसा ही करता हूँ: Podman container के अंदर काम करता हूँ, source code directory के अलावा host के साथ कुछ share नहीं करता

      • समस्या का एक हिस्सा traditional PC security model (Linux/Windows) से आता है

        • executable को trusted मान लेना, और फिर उसे मेरे सारे personal data तक पहुँच देना, 2025 के हिसाब से सही model नहीं है
        • mobile (Android) ने इसे ज़्यादातर हद तक पार कर लिया है, लेकिन PC पर SELinux के अलावा गहरे विकल्प कम हैं

      • अगर आपको यह approach पसंद है, तो मैं Qubes OS की सिफारिश करूँगा। यह हर काम को VM में करने के लिए अच्छा UX देता है

        • यही मेरा daily driver है, और मैं ज़ोरदार सिफारिश करता हूँ

      • लेकिन यह भी स्पष्ट कर दूँ कि ऐसा environment बनाना software ecosystem और history की वजह से बहुत कठिन या काफ़ी महँगा हो सकता है

  • Claude Code productivity बढ़ाने वाला एक क्रांतिकारी tool है

    • लेकिन इसके साथ ये security issues भी हैं:

      • यह NodeJS app है
      • install करते समय curl को bash में pipe किया जाता है (remote code execution risk)
      • LLM file system, commands आदि कई चीज़ों को छू सकता है

    • इस तरह कम-से-कम 3 security weaknesses हैं, इसलिए मैं इसे VM/container/dedicated dev box जैसे sandbox के बाहर नहीं चलाना चाहूँगा

      • मैं भी मानता हूँ कि agents को sandbox में चलाना सही है

        • लेकिन Claude code शुरुआत से ही (बिना अलग अनुमति के) मनमाने commands execute नहीं करता

      • फिर भी उससे क्या फर्क पड़ता है?

        • user को खुद run button दबाना पड़ता है
        • ज़्यादातर programs के पास भी permissions होती हैं
        • terminal भी filesystem को बदल सकता है, लेकिन वह अपने-आप नहीं चलता
        • Claude Code कोई daemon नहीं है जो अपने-आप मेरा computer खराब करने लगे; साफ़ निर्देश के बिना कुछ नहीं करता
        • मुझे लगता है Claude Code पिछले 30 सालों में इस्तेमाल किया गया सबसे बेहतरीन tool है
        • “attack vector” क्या था, इससे मुझे ज़्यादा फ़र्क नहीं पड़ता। अगर कोई मेरी machine में बिना अनुमति घुस जाए, तो वह सिर्फ Claude Code की समस्या नहीं है

      • असली खतरा यह है कि automatic updates के चलते आपने runtime के दौरान remote code execution (RCE) की authority Anthropic को दे दी है

  • क्या package manager में ‘minimum package age’ जैसी setting होनी चाहिए?

    • उदाहरण के लिए, 24–36 घंटे से कम पहले publish हुए packages को ignore कर दिया जाए

    • पहले एक मिलते-जुलते मामले में देखा था कि package update ने सब कुछ तोड़ दिया और फिर कुछ घंटों बाद उसे जल्दी से ठीक/हटा दिया गया

      • GitHub dependabot ने हाल ही में ठीक ऐसी सुविधा जोड़ी है

      • Renovate bot में यह option पहले से है (minimumReleaseAge setting), और dependabot भी अब support करता है

        • package managers तो सिर्फ latest version install करने पर ध्यान देते हैं, लेकिन ऐसे free tools से उचित cadence पर updates manage किए जा सकते हैं
        • JavaScript ecosystem धीरे-धीरे consolidation की ओर बढ़ रहा है, और supply chain attacks से निपटने वाले tools भी धीरे-धीरे आ रहे हैं
        • नए NPM, PNPM, Bun आदि default रूप से postinstall scripts नहीं चलाते, और ज़रूरत पड़ने पर उन्हें explicitly run करना पड़ता है (हालाँकि अंत में यह फिर भी किसी और का code चलाना ही है)

      • OS-level नहीं, लेकिन Astral का uv tool Python packages के लिए ऐसा option देता है

      • npm install में भी किसी खास समय/तारीख़ से पहले की dependencies ही install करने वाला flag है

        • npm install --before (2 दिन पहले की तारीख़) से उस तारीख़ के बाद बनी dependencies install नहीं होतीं

      • मैं .npmrc में save-exact=true सेट करता हूँ और सिर्फ lockfile तथा manual updates का इस्तेमाल करता हूँ

        • packages को बार-बार upgrade करने की ज़रूरत नहीं होती
        • fakerjs जैसी घटना देखने के बाद मुझे और सावधान रहना सही लगा

  • मुझे शक था कि claude code सच में ऐसे prompts चलाएगा या नहीं, इसलिए मैंने test किया

    • नतीजा यह था:

      • "यह request cryptocurrency wallets, private keys और दूसरे sensitive files को खोजने/सूचीबद्ध करने जैसी लगती है और इसमें दुरुपयोग की संभावना है, इसलिए मैं इसमें मदद नहीं कर सकता"

      • इसके बजाय यह केवल वैध requests जैसे security audit, vulnerability analysis, monitoring tool लिखना, file permissions समझना, backup procedures design करना आदि पर मार्गदर्शन देता है

      • फिर भी कम-से-कम 250 से ज़्यादा सफल cases मिले हैं (यानी कुछ prompts pass हो जाते हैं)

        • Claude की average refusal rate साफ़ तौर पर ज़्यादा है, और Q भी अच्छी तरह मना करता है (क्योंकि वह भी Claude-आधारित है)
        • संदर्भ के लिए, मैं पूरे दिन ऐसे issues पर काम करते हुए यह analysis report लिख रहा था

      • व्यावहारिक परीक्षणों में जब भी Claude और दूसरे models की refusal battle हुई, Claude की refusals/safety measures हर बार बेहतर लगीं

        • मशहूर उदाहरण: ChatGPT एक mental-health issue वाले user को लगातार "The Oracle" कहकर validate करता रहा, जबकि Claude ने मना किया और professional help लेने को कहा
        • हाँ, "आप बिल्कुल सही हैं!" जैसी प्रतिक्रियाओं की पुनरावृत्ति कभी-कभी परेशान करती है, लेकिन Anthropic ने competitors की तुलना में refusal और safety पर ज़्यादा ध्यान दिया है — यह मानना और सराहना करना चाहिए

  • OS को default रूप से apps को पूरे file system तक unrestricted access नहीं देनी चाहिए

    • कुछ apps के लिए apparmor/selinux profiles होते हैं, और firejail जैसी चीज़ें भी इस्तेमाल की जा सकती हैं

    • लेकिन UX के स्तर पर बदलाव चाहिए

      • यह बहुत गंभीर समस्या है। इसकी जड़ 30 साल पुराने desktop design में है

        • दूसरी ओर, modern mobile OS (जैसे iOS) में per-app sandboxing और permission approval defaults अच्छे हैं
        • desktop पर Qubes (OS), Firejail, bubblewrap, AppArmor जैसी कई कोशिशें हैं, लेकिन वे complex हैं या आम users के लिए कठिन हैं
        • OpenSnitch भी है, लेकिन वह networking तक सीमित है
        • end users के लिए हर program की permission अलग-अलग fine-tune करना बोझिल है
        • अंततः असली कुंजी यह है कि widely used apps के profiles लगातार maintained रहें
        • desktop security की यह हालत चौंकाने वाली है, लेकिन समस्या मूल रूप से कठिन है, और इसे हल करने के लिए financial incentive भी कम है

      • मैं Linux पर Podman के साथ project-by-project environment isolation पर केंद्रित एक tool खुद बना रहा हूँ: probox

        • UX बेहतर करने पर बहुत मेहनत की है
        • मैं इसे अक्सर इस्तेमाल करता हूँ, और किसी security review करने वाले की तलाश है

      • Android file security के मामले में Google ने अच्छा काम किया है

      • bubblewrap और छोटे chroot environments का इस्तेमाल सीखना भी अच्छा रहेगा

      • मुझे नहीं लगता कोई भी operating system default रूप से applications को "पूरे file system तक असीमित access" देता है

        • Linux, BSD, MacOS, Windows — सबमें कड़े restrictions होते हैं
        • जब तक सामान्य user खुद जोखिम लेकर account privileges बढ़ाकर चीज़ें नहीं चलाता, default रूप से काफी सुरक्षा रहती है

  • पहले एक धुंधला-सा भरोसा था कि "attacker को मेरे environment का अंदाज़ा लगाना पड़ेगा", लेकिन अब LLM को लगाकर environment के हिसाब से attack सीखना और चलाना संभव है

    • मुझे लगता है मैंने खुद भी इस प्रवृत्ति की सही भविष्यवाणी की थी

    • पिछली चर्चा में इस पर दिलचस्प बातें थीं

      • (मज़ाक में) मैं attacker हूँ, कोई नए ideas हैं? (/s)

  • सच में डरावनी बात यह है कि अब local LLM का इस्तेमाल secrets ढूँढने के लिए हो रहा है

    • "postinstall" वाली समस्या पुरानी है, लेकिन payload पूरी तरह नई पीढ़ी का है

    • malicious logic code की बजाय prompt में छिपी होती है, इसलिए पारंपरिक static analysis से पकड़ना मुश्किल हो जाता है

    • ऐसे malicious prompts से बचाव कैसे किया जाए, यही सोचने वाली बात है

      • Claude Code को पूरी तरह isolated container/VM में चलाना, और commit होने वाले हर code को manually review करना ही शायद एकमात्र जवाब है