Red Hat Cloud Services में व्यापक रूप से दुर्भावनापूर्ण npm पैकेज मिले

 (github.com/RedHatInsights)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह इश्यू खुला हुआ है, और लेखन के समय इसमें कोई assignee·milestone·जुड़ी हुई branch या PR नहीं है
  • इसे एक security issue के रूप में दर्ज किया गया है कि @redhat-cloud-services/ scope की कई npm releases में दुर्भावनापूर्ण versions मिले हैं
  • संदर्भ सामग्री के रूप में StepSecurity की विश्लेषण पोस्ट और OSS Security Feed खोज परिणाम दिए गए हैं
  • अपडेट की गई impact list में @redhat-cloud-services/chrome, frontend-components, rbac-client, types, vulnerabilities-client आदि समेत 32 packages शामिल हैं
  • तालिका में दिए गए compromised versions अधिकांश packages के लिए 3-3 हैं, जबकि @redhat-cloud-services/vulnerabilities-client में केवल 2.1.9, 2.1.11 ये दो versions शामिल हैं
  • पूरी तालिका के आधार पर compromised versions की संख्या 95 निकाली जा सकती है, और अलग से उल्लेखित external PR का शीर्षक भी 95 versions की ओर इशारा करता है
  • @redhat-cloud-services/frontend-components-* श्रृंखला और कई *-client packages साथ में शामिल हैं, इसलिए यह किसी एक package की नहीं बल्कि उसी scope की releases के व्यापक स्तर की समस्या है
  • टिप्पणियों में “What are these?” सवाल के जवाब में “all that module is pwned” लिखा गया है, जिससे यह समझ साझा हुई कि पूरी सूची प्रभावित हुई है
  • DanielRuf ने लिखा कि उसने इस घटना को supply-chain-incidents में जोड़ दिया है
  • GitHub activity में इस issue का संदर्भ देने वाला content summary और detection से जुड़ा PR दिखता है, लेकिन मूल विवरण में अभी तक Red Hat की ओर से diagnosis·mitigation steps·removal status·fixed versions प्रस्तुत नहीं किए गए हैं

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News टिप्पणियाँ

  • उम्मीद है कि cooldown सेटिंग की बात करने के लिए इस थ्रेड को फिर से उठाना ठीक होगा। axios, tanstack, @redhat-cloud-services और हाल के कई npm सप्लाई-चेन हमलों को cooldown होता तो रोका जा सकता था
    अगर आप Artifactory/Nexus इस्तेमाल करते हैं तो संभव है यह पहले से मौजूद हो, और न भी हो तो सेट करना आसान है। npm या PyPI से जुड़ी ज़्यादातर छेड़छाड़ कुछ घंटों के भीतर हटा दी गई थी, इसलिए रिलीज़ हुए N दिनों से कम पुराने पैकेजों को अनदेखा करने का तरीका काफ़ी है। 1 दिन भी असरदार है, 3 दिन ठीक है, और 7 दिन थोड़ा ज़्यादा है लेकिन काम करता है
    नया pnpm डिफ़ॉल्ट रूप से 1 दिन का cooldown जोड़ चुका है: https://pnpm.io/supply-chain-security
    अगर आप इसे एक क्लिक में पूरा करना चाहते हैं, तो https://depsguard.com इस्तेमाल कर सकते हैं। यह npm, pnpm, yarn, bun, uv, dependabot में cooldown और सुझाई गई settings जोड़ने वाला CLI है, और मैं इसका मेंटेनर हूँ
    cooldown पर ज़्यादा केंद्रित https://cooldowns.dev भी है, और local settings में मदद करने वाली scripts भी हैं। सब open source/मुफ़्त हैं
    अगर आपको ~/.npmrc वगैरह सीधे एडिट करना आता है तो इसकी खास ज़रूरत नहीं, लेकिन अगर आपके आसपास ऐसे लोग हैं जिन्हें सिर्फ one-click fix चाहिए, तो यह अगले हमले से बचने में मदद कर सकता है
    लेकिन, जब किसी नई critical CVE को patch करना हो, तब cooldown को bypass करना पड़ेगा, और हर टूल में इसका तरीका होता है। पिछले कुछ महीनों के सटीक आँकड़े मेरे पास नहीं हैं, लेकिन Mythos-शैली vulnerability discovery के दौर में भी नई zero-day CVE की तुलना में malicious version publish जैसे software supply-chain हमलों का जोखिम बड़ा लगता है

    • embedded developer के रूप में मैं toolchain और dependencies को कई सालों तक pin करके रखने का आदी हूँ, इसलिए web development culture कई मायनों में चौंकाने वाली लगती है
    • एक दोस्त का GitHub repository है जिसमें sane और थोड़ा ज़्यादा सुरक्षित settings के तरीके इकट्ठा किए गए हैं: https://github.com/jordanconway/package-manager-hardening
    • क्या Docker/Podman image pull पर भी cooldown लगाने का कोई व्यावहारिक तरीका है?
    • मैं ~/.npmrc फ़ाइल खोलकर एक लाइन जोड़ सकता हूँ, फिर भी one-click fix की ज़रूरत वाले लोग बहुत छोटा समूह लगते हैं
    • cooldown के साथ-साथ, अच्छा होगा अगर और ज़्यादा package managers security fixes और सामान्य releases (bug fixes/performance improvements/new features) को अलग-अलग तरीके से संभालें
      यह कहना पूरी तरह संभव है कि “security fix में सिर्फ security fix ही होने चाहिए, उसमें दूसरे features नहीं आने चाहिए।” इससे security researchers और tools, दोनों के लिए audit करना आसान हो जाएगा
      सामान्य releases पर cooldown लागू किया जा सकता है, और security fixes पर cooldown हटाया जा सकता है या बहुत छोटा रखा जा सकता है
      Debian जैसे बहुत स्थिर servers रखकर, unattended upgrades को सिर्फ security fixes पर लागू करने योग्य बनाने वाला ढाँचा एक अच्छा संदर्भ है। ऐसे नए package releases को security researchers के लिए audit करना भी आसान होता है

  • हर ऐसे थ्रेड में बहुत-सी टिप्पणियाँ होती हैं जो ऐसे पेश आती हैं मानो इस तरह का हमला सिर्फ npm में ही होता हो, या फिर तंज कसती हैं मानो कोई उपाय कभी किए ही नहीं गए, लेकिन मुझे नहीं लगता कि यह उचित है
    delay line और pnpm जैसी चीज़ों द्वारा package consumers को सुरक्षित रखने के लिए लाई गई अच्छी सुविधाओं का ज़िक्र करने वाली टिप्पणियाँ भी बहुत हैं
    जिस हिस्से पर कम बात होती है, वह है package maintainers की तरफ़ के tools। publishing के लिए MFA: https://docs.npmjs.com/requiring-2fa-for-package-publishing-..., और लगभग एक साल पहले से उपलब्ध trusted publishers: https://docs.npmjs.com/trusted-publishers
    हाल में इन दोनों सुविधाओं के फ़ायदों को मिलाकर staged publishing भी आया है: https://docs.npmjs.com/staged-publishing
    अब static credentials के बिना CI से publish किया जा सकता है, और registry पर वास्तव में public होने से पहले maintainer से MFA द्वारा approval माँगा जा सकता है। चाहें तो GitHub Actions Environments protection के ज़रिए CI की तरफ़ से multiple approvals या time delay भी अनिवार्य किए जा सकते हैं
    समुदाय को ऐसे publishing सुरक्षा उपाय अपनाने के लिए प्रोत्साहित करना चाहिए, नहीं तो यह समस्या चलती रहेगी

    • [1] के अनुसार, “प्रभावित सभी packages RedHatInsights/javascript-clients repository से GitHub Actions OIDC के माध्यम से publish किए गए थे, जो यह संकेत देता है कि upstream CI/CD pipeline स्वयं compromise हो गई थी”
      तब malicious packages को भी हरा सितारा मिला होगा, और उपयोगकर्ताओं को यह कहकर आश्वस्त किया गया होगा कि वे “source attestation के साथ build और sign किए गए हैं”
      [1] https://lwn.net/Articles/1075742/
    • यह बार-बार होता रहता है, इसलिए थोड़ा हास्यास्पद लगता है। npm attacks तो इतने नियमित हैं कि उन्हें calendar पर चिह्नित किया जा सके, और किसी ने The Onion के क्लासिक “इसे रोकने का कोई तरीका नहीं” लेख की npm version parody भी बना दी थी
      इसे रोकने के लिए काम चल रहा है, यह बहुत अच्छी बात है, लेकिन फिर भी यह होता रहता है। “लो, फिर शुरू हो गया” वाले अर्थ में मज़ेदार है
    • जब सबके लिए अनिवार्य बना दिया जाएगा, तभी लगेगा कि सच में कुछ किया गया है
    • मुझे mechanical changes से बहुत प्रभावित नहीं होता, और लगता है कि एक समूह इस समस्या को सांस्कृतिक समस्या के रूप में देखता है
      बाहर से देखने पर web development में एक तरह की बेकाबू frontier जैसी energy दिखती है। mutability, dynamic typing, लगातार बदलते standards और frameworks, continuous deployment, CDN, real-time A/B campaigns, बहुत-सी dependencies, और कई infrastructure में फैला संवेदनशील user data — सब मौजूद है
      मैं यह नहीं कह रहा कि यह नज़रिया बिल्कुल सही है, और न ही मुझे “देखा, हमने कहा था” वाला रवैया सही लगता है, लेकिन यह कहाँ से आता है, यह समझ में आता है
    • मेरी राय में ये दोनों ही सूअर पर लिपस्टिक जैसे समाधान हैं। आखिरकार ये सब “releases को deploy करना और कठिन बना दो” के ही रूपांतर हैं, और बस लोगों को workaround सीखने पर मजबूर करेंगे
      खासकर, इनमें से कोई भी xz-utils backdoor को package distribution में जाने से नहीं रोक पाता। xz-utils अब भी sophisticated upstream compromise का मानक उदाहरण बना हुआ है
      यहाँ असली bug यह नहीं है कि हमें उस upstream को, जिस पर हम पहले ही भरोसा कर चुके हैं, और बेहतर तरीके से authenticate करना चाहिए; bug यह है कि upstream को security के एकमात्र स्रोत के रूप में भरोसेमंद माना ही नहीं जा सकता। upstream तो hackers का एक समूह है जिसे robust release engineering में न खास दिलचस्पी होती है और न ही वे इसमें बहुत अच्छे होते हैं
      लेकिन कुछ लोग इसमें अच्छे होते हैं। Linux दुनिया का समाधान, और xz-utils में जिसने हमें बचाया, वह यह है कि वहाँ मनुष्यों की दूसरी परत होती है जो hackers द्वारा बनाए गए upstream को उपयोगकर्ताओं के लिए review, audit, package और customize करती है
      इन लोगों के पास अलग नज़र, अलग consumer requirements, और अलग quality standards होते हैं, और वे उन bugs और दुर्भावना को पकड़ लेते हैं जिन्हें upstream पकड़ने के लिए तैयार नहीं होता
      NPM, cargo, PyPI वगैरह बार-बार सोचते हैं कि वे इस मानवीय श्रम की आवश्यकता को bypass कर सकते हैं, लेकिन ऐसा नहीं हो सकता। NPM ecosystem में यह बात खास तौर पर इसलिए ज़्यादा दिखती है क्योंकि वहाँ बहुत-से web developers हैं जो बहुत तेज़ releases, ढीली compatibility requirements, और अत्यधिक reuse के आदी हैं, इसलिए Python या Rust की तुलना में node packages में ऐसी घटनाएँ अधिक बार दिखाई देती हैं

  • हमारी कंपनी yarn 4 इस्तेमाल करती है, और इसमें ऐसा विकल्प है जो npm पैकेज रिलीज़ होने के बाद शुरुआती कुछ दिनों तक इंस्टॉल को रोकता है। लगता है कि ऐसे ज़्यादातर हमले उसी अवधि (1~3 दिन) के भीतर पकड़ में आ जाते हैं
    https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

    • event-stream पैकेज के compromise होने के बाद भी वह 60 दिनों तक पकड़ा नहीं गया: https://medium.com/intrinsic-blog/compromised-npm-package-ev...
      axios पैकेज compromise हो गया था, और लेखक के credentials भी चुरा लिए गए थे, इसलिए हर remediation attempt फिर से निष्प्रभावी कर दिया गया: https://www.trendmicro.com/en_us/research/26/c/axios-npm-pac...
      xz utility में 2 महीनों तक backdoor मौजूद था: https://gigazine.net/gsc_news/en/20240403-timeline-of-xz-ope...
      एक छात्र शोधकर्ता ने Python ctx और PHPass पैकेज की maintainer authority अपने पास लेकर malicious changes वितरित किए, और detection तथा fix में 7 दिनों से ज़्यादा लगे: https://infosecwriteups.com/how-i-hacked-ctx-and-phpass-modu...
      Kaspersky ने कई PyPI पैकेज पाए जिनका एक साल से ज़्यादा समय तक दुरुपयोग हुआ: https://www.kaspersky.com/about/press-releases/kaspersky-unc...
      “LoftyLife” पैकेज का कई महीनों तक दुरुपयोग हुआ: https://securelist.com/lofylife-malicious-npm-packages/10701...
      अगर attack window 7 दिन की कर दी जाए, तो ऐसे सभी नए हमले 8वें दिन तक सक्रिय न होने वाला time bomb डाल देंगे
    • pnpm में भी यही फ़ीचर है, और v11 से यह डिफ़ॉल्ट रूप से चालू है: https://pnpm.io/settings#minimumreleaseage
    • अगर आप Python developer हैं, तो uv भी यही फ़ीचर support करता है: https://docs.astral.sh/uv/concepts/resolution/#dependency-co...
    • इस सोच पर फिर से विचार किया जाना चाहिए कि हर पैकेज को हमेशा बिल्कुल latest और best state में रखना ज़रूरी है। हर minor version update को तुरंत लागू करना आवश्यक नहीं है, और high/critical vulnerabilities के लिए भी ज़रूरी नहीं कि minor version upgrade ही करना पड़े
    • अगर सब लोग 3 दिन की delay शुरू कर दें, तो क्या आखिरकार सबको 3वें दिन ही पता नहीं चलेगा?

  • कुछ सुझाव हैं। dependency cooldown 1~2 दिन का रखना, CVE patch करने की क्षमता को नुकसान पहुँचाए बिना, काफ़ी प्रभावी लगता है
    npm install, npm test जैसी हर जगह जहाँ code execute होता है, उसे unprivileged environment में चलना चाहिए। GitHub Actions में artifacts build/test करने वाली jobs को deploy/signing जैसी jobs से अलग करना अपेक्षाकृत आसान है। अगर आप AI इस्तेमाल करते हैं, तो इस pattern को enforce करने वाली skill/guide जोड़ सकते हैं
    अगर आप GitHub Actions इस्तेमाल करते हैं, तो latest zizmor इंस्टॉल करने से security posture काफ़ी बेहतर हो जाती है
    दूसरा उपाय इसे अब “worm की तरह फैलने योग्य” नहीं रहने देता, और मौजूदा समस्या के बड़े हिस्से को कम कर देता है। पहला उपाय कंपनियों को हमलों पर प्रतिक्रिया देने के लिए समय देता है। इस क्षेत्र के कुछ vendors का भी मूल्यांकन किया जा सकता है

    • अगर zizmor ही compromise हो जाए तो?
      नए पैकेज delay करने की बात कहने के तुरंत बाद यह मज़ाक जैसा लगा
    • क्या ऐसे cooldown की जगह isolated context में build चलाना काफ़ी नहीं होगा?
      मैं लोकल में Maven proxy चलाता हूँ, और सभी builds container के अंदर करता हूँ। Python, npm, और Go public repositories ही इस्तेमाल करते हैं, इसलिए इन builds को भी container में किया जाता है, लेकिन repository proxy की ज़रूरत नहीं होती
    • जहाँ-जहाँ code execute होता है, वहाँ codex, claude-code जैसे agent-type orchestrators शायद डिफ़ॉल्ट रूप से यही करते दिखते हैं

  • यह उसी दिन की बात है जिस दिन Red Hat और IBM ने supply chain vulnerabilities की detection और remediation में मदद के लिए Project Lightwell की घोषणा की थी
    https://www.redhat.com/en/lightwell

  • कुछ दिन पहले यह दिलचस्प rant देखा था: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...
    यह बात कुछ हद तक सही लगती है कि सही तरीका यह है कि जिन dependencies का आप इस्तेमाल करते हैं, उन सबको fork करें, और ज़रूरत पड़ने पर upstream की समीक्षा करके merge करते हुए अपने repository से install करें। हालांकि, यह बहुत झंझटभरा लगता है

    • यह ऐसा काम नहीं है जिसे automate न किया जा सके। Go की दुनिया में इसे vendoring कहा जा सकता है: https://go.dev/ref/mod#vendoring
      यह third-party dependency hosting providers पर निर्भरता घटाने या हटाने, dependencies को अपने code review tools के भीतर लाने, और लंबे समय में reproducible builds सुनिश्चित करने के लिए अच्छा है
    • समस्या यह है कि dependencies की भी dependencies होती हैं, और उसके नीचे कई स्तरों तक यह सिलसिला चलता रहता है
    • CLI में dependencies का आसानी से audit करने के लिए मैंने Packj बनाया
      Packj(https://github.com/ossillate-inc/packj) behavior analysis के ज़रिए malicious PyPI/NPM/Ruby/PHP जैसी dependencies का पता लगाता है। यह static + dynamic code analysis से shell execution, SSH key usage, network communication, decode+eval के इस्तेमाल जैसे compromise indicators को scan करता है। typosquatting जैसे malicious actors को खोजने के लिए यह कई metadata properties भी जांचता है
    • संभावना बदल सकती है, लेकिन अगर आप ईमानदारी से fork बनाए नहीं रखते और आगे आने वाली हर vulnerability पर monkeypatch नहीं करते, तो हो सकता है कि आप compromised fork को हमेशा के लिए distribute करते रहें
    • क्या packages को सिर्फ latest पर बनाए रखना ही नहीं, बल्कि version numbers को भी restrict नहीं करना चाहिए?

  • करीब एक हफ्ते पहले मैंने अपने laptop से Node हटा दिया, और अच्छा लगा
    बुरा वक्त आने पर exploit लग भी जाए, तो blast radius घटाने के लिए मैं अब सारा काम dev containers या किसी दूसरे sandbox में करने की कोशिश कर रहा हूँ। attacker Claude token ले जा सकता है, लेकिन container से आसानी से निकलकर home directory नहीं खंगाल पाएगा
    cooldown और install script allowlist खासकर CI में defense in depth के लिए अच्छे अतिरिक्त उपाय हैं। लेकिन मूल रूप से जिस चीज़ को बदलना चाहिए, वह OS permission model है। third-party software पर user privileges के पूरे दायरे के साथ भरोसा करने वाला default अब काम नहीं करता

    • जानना चाहूँगा कि आप Bubblewrap/Firejail/Flatpak जैसी चीजें इस्तेमाल कर रहे हैं या नहीं, या ऐसा setup कैसा दिखता है। मैं भी कुछ समय से इसी तरह का विचार कर रहा हूँ, लेकिन अभी तक लागू नहीं कर पाया हूँ

  • लगता है मूल announcement का link भी देना चाहिए
    https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...

    • सही है। और title में Red Hat की spelling भी गलत है

  • packages install करते समय अब मुझे --before=2026-05-30 flag इस्तेमाल करने की आदत हो गई है। इससे तय तारीख से पहले release हुए versions चुने जाते हैं, और मैं आम तौर पर लगभग 5 दिन पहले की तारीख चुनता हूँ

    • अगर आप npm 11 इस्तेमाल करते हैं, तो flow को सरल बनाने के लिए min-release-age को 5 पर set कर सकते हैं
      https://docs.npmjs.com/cli/v11/using-npm/config#min-release-...
    • मैं pnpm इस्तेमाल करता हूँ और एक उदार minimumReleaseAge set करता हूँ
      https://pnpm.io/settings#minimumreleaseage
      अच्छी बात यह है कि v11 से यह default रूप से enabled है
    • अगर आप pure npm (v11.10.0 या बाद का) इस्तेमाल करते हैं, तो project root की .npmrc में बस min-release-age=5 जोड़ दें
    • Yarn 4 इसे automate कर सकता है

  • NPM design से ही टूटा हुआ है, और community में फैले NIH syndrome की वजह से साधारण कदम भी नहीं उठाए जा सकते

    • दूसरी पंक्ति पूरी तरह समझ नहीं आई। क्या npm में समस्या ‘not invented here’ की उलटी नहीं है?
      in-house development की बजाय बाहरी packages बहुत ज़्यादा अपना लेने की वजह से npm projects बड़े और जटिल dependency trees रखने की ओर झुकते हैं। https://www.npmjs.com/package/is-windows जैसे packages के बारे में लंबे समय से शिकायत रही है कि वही code सीधे लिखना बहुत आसान है, फिर भी वे संभावित vulnerabilities और maintenance headaches पैदा करते हैं
    • NIH वाले पक्ष की आम गलती यह मानना है कि package X को दोबारा बनाने में बहुत समय लगेगा
      लेकिन जाहिर है, आपको पूरी functionality दोबारा बनाने की ज़रूरत नहीं होती; सिर्फ जितनी चाहिए उतनी बनानी होती है
      और जब आप सिर्फ एक function code कर रहे होते हैं, तो abstraction या अतिरिक्त function interfaces बनाने की भी ज़रूरत नहीं होती। इसलिए यह सस्ता पड़ता है, और शायद बेहतर integrated भी होता है
      एक और गलती यह मानना है कि इससे bugs और vulnerabilities बनेंगी। अगर programmer खराब हो तो ऐसा हो सकता है, लेकिन उन vulnerabilities की एक श्रेणी से बचा जा सकता है जो दो libraries के integration boundary पर पैदा होती हैं, जब वे एक-दूसरे से ठीक-ठीक मेल खाने के लिए design नहीं की गई हों। ऐसे मामले बहुत होते हैं