PyTorch Lightning AI ट्रेनिंग लाइब्रेरी में Shai-Hulud थीम वाला मैलवेयर मिला

• डीप लर्निंग फ्रेमवर्क lightning के 2.6.2 और 2.6.3 वर्ज़न का सप्लाई-चेन अटैक में दुरुपयोग हुआ — सिर्फ pip install lightning चलाने पर भी छिपी हुई _runtime डायरेक्टरी में मौजूद obfuscated JavaScript payload अपने-आप चल जाता है
• यह फ्रेमवर्क image classifier बनाना, LLM fine-tuning, diffusion model, time-series forecasting आदि में व्यापक रूप से इस्तेमाल होता है, इसलिए कई AI/ML टीमों की dependency tree में इसके पहले से शामिल होने की संभावना बहुत अधिक है
• मैलवेयर चलने पर यह लोकल filesystem में 80 से ज़्यादा paths स्कैन करता है और GitHub tokens(ghp_, gho_), npm tokens(npm_), environment variables, cloud secrets चुरा लेता है, साथ ही हर फ़ाइल से अधिकतम 5MB तक प्रोसेस करता है
• AWS(credential files·IMDSv2·ECS·Secrets Manager·SSM), Azure(Key Vault), GCP(Secret Manager) समेत तीनों बड़े cloud providers से secrets enumerate और fetch करता है
• GitHub Actions environment में यह built-in Python के जरिए Runner.Worker process memory dump करता है और "isSecret":true के रूप में चिह्नित सभी secrets के साथ repository और workflow जानकारी निकाल लेता है
• entry point PyPI(Python) है, लेकिन worm propagation npm(JavaScript) के जरिए फैलती है — चुराए गए npm tokens से publish किए जा सकने वाले सभी packages में dropper(setup.mjs) और मैलवेयर(router_runtime.js) inject करके patch version बढ़ाकर दोबारा publish किया जाता है, जिससे उन packages को install करने वाले downstream developers की machines तक चेन-इन्फेक्शन हो जाता है
• डेटा exfiltration को किसी एक रास्ते को ब्लॉक करके रोकना मुश्किल बनाने के लिए यह 4 parallel channels एक साथ इस्तेमाल करता है: ① HTTPS POST से C2 server पर भेजना, ② GitHub commit search API का dead drop की तरह उपयोग करना(commit message में double Base64 encoded token डालना), ③ Dune universe के नाम वाले public GitHub repository में results-<timestamp>.json के रूप में commit करना, ④ victim repository में सीधे push करना
• repository में घुसने के बाद यह dev tools में persistence hooks डालकर re-infection सुनिश्चित करता है — Claude Code की .claude/settings.json में SessionStart hook लिखकर session शुरू होते ही auto-run, और VS Code की .vscode/tasks.json में runOn: folderOpen task डालकर हर बार folder खुलने पर run
  • दोनों hooks self-contained dropper setup.mjs को कॉल करते हैं, और अगर Bun runtime मौजूद न हो तो उसे GitHub से चुपचाप डाउनलोड करके 14.8MB payload router_runtime.js चलाते हैं
• write permission वाला GitHub token मिल जाने पर यह victim repository में Formatter नाम का छद्म workflow push करता है — हर push पर ${{ toJSON(secrets) }} से repository secrets dump करता है और उन्हें Actions artifact के रूप में upload करता है
• प्रभावित अवधि में जिन सभी machines पर यह वर्ज़न install हुआ है, उन्हें पूरी तरह compromise हुआ मानना चाहिए, और GitHub tokens, cloud credentials, API keys तुरंत rotate करने के साथ .claude/ और .vscode/ directories में किसी अनपेक्षित फ़ाइल की audit करनी चाहिए
• attack indicators: commit messages में EveryBoiWeBuildIsAWormyBoi prefix, repository description में "A Mini Shai-Hulud has Appeared", और repository में _runtime/ डायरेक्टरी की मौजूदगी — इन्हें GitHub search के जरिए सीधे verify किया जा सकता है

[picopress]

अब लगता है अपडेट नहीं करना चाहिए...

[GN⁺]

Hacker News टिप्पणियाँ

• यह शायद सिर्फ frequency illusion भी हो सकता है, लेकिन हाल में बड़े पैकेजों में मशहूर supply chain attacks काफ़ी ज़्यादा दिख रहे हैं
  अभी HN के पहले कुछ पन्नों पर भी अलग-अलग मामलों पर कई पोस्ट हैं
  10 साल पहले के left-pad को देखें तो लगता है कि अब सफल हमले पहले से ज़्यादा हैं, और शायद सच में हैं
  सफल हमलों की वैल्यू भी निश्चित रूप से बढ़ी होगी, लेकिन यह जानना दिलचस्प है कि पैकेज रिलीज़ होने से पहले उन्हें पकड़ने की क्षमता क्या पूरे community स्तर पर सच में बेहतर हो रही है
  commercial software कंपनियों को बेहतर करना चाहिए, लेकिन hobby/amateur code से शुरू होकर बहुत-से प्रोजेक्ट्स की dependency बन जाने वाले मामलों के लिए universal और आसान tools अभी भी कम लगते हैं
  यही टिप्पणी मैंने मौजूदा SAP supply chain attack थ्रेड में भी डाली थी: https://news.ycombinator.com/item?id=47964003

  • यह सचमुच एक वास्तविक रुझान है। अप्रैल की शुरुआत तक पिछले 12 महीनों में 7 घटनाएँ हुईं, और उससे पहले के 20 वर्षों में 9 थीं: https://www.jefftk.com/p/more-and-more-extensive-supply-chai...
  • लोग बिना कोड को ठीक से देखे उसे हर जगह बड़ी मात्रा में ठेल रहे हैं, इसलिए supply chain attacks का बढ़ना स्वाभाविक है
  • वजह यह है कि auto updates और CI tools अब इतने फैल चुके हैं कि सब उनका इस्तेमाल करते हैं
    पहले npm install ज़्यादातर manually चलाया जाता था, शायद तभी जब build टूट जाती थी या बहुत कभी-कभार
    supply chain attack इस बात पर निर्भर करते हैं कि लोग, या ज़्यादा सही कहें तो pipelines, नई रिलीज़ आते ही बिना सोचे पैकेज अपने-आप अपडेट कर दें
  • ऐतिहासिक रूप से, अतिरिक्त security checks से गुज़रे artifacts को संभालना paid enterprise option हुआ करता था, और कम सुरक्षित रास्ता कहीं कम झंझट वाला default था
    यह अच्छा business model है या नहीं, पता नहीं, शायद नहीं
  • left-pad हमला नहीं था, वह NPM का bug था
    ऐसा नहीं होना चाहिए था कि किसी ऐसे पैकेज version को हटाया जा सके जिस पर पहले से public दूसरे पैकेज निर्भर हों, और उल्टा यह संभव होना चाहिए था कि किसी नए version को हटाया जा सके जिस पर अभी कोई निर्भर न हो
    जब left-pad के लेखक ने सेवा छोड़ने के इरादे से अपना सारा डेटा मिटाने की कोशिश की, तब NPM को error code लौटाना चाहिए था
    Wikipedia के अनुसार, Koçulu npm, Inc. के फ़ैसले से निराश था और प्लेटफ़ॉर्म का हिस्सा बने नहीं रहना चाहता था, तो NPM के लेखक Schlueter ने उसके registered 273 modules हटाने का command दिया

• अजीब बात यह है कि 4 security issues दर्ज किए गए थे, और उन सब पर pl-ghost नाम के bot ने auto-comment करके उन्हें बंद कर दिया [1][2][3][4]
  आखिरकार इनमें से सिर्फ [4] को सही तरह से handle किया गया, और bot की सभी टिप्पणियाँ हटा दी गईं
  दूसरे report [5] में bot comment देखी जा सकती है, और उसमें original से ज़्यादा जानकारी है
  [1] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [2] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [3] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [4] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [5] https://socket.dev/blog/lightning-pypi-package-compromised

  • मैं Lightning का Andy हूँ। हाँ, PyPI credentials pl-ghost bot account के compromise होने से चुराए गए थे
    attacker ने इसी account से एक नया Actions workflow बनाया, और चलाए गए workflow से PyPI secrets को parse करके निकाल लिया
    पैकेज रिलीज़ करने के बाद उसने उसी account से comments भी किए, थोड़ी-सी तंज़ कसते हुए

• काश वह दिन जल्दी आए जब dependencies बिल्कुल न हों
  एक चरम उदाहरण के तौर पर, आजकल जब मैं अपनी बेटी के लिए interactive educational app बनाता हूँ, तो Opus से सिर्फ pure JavaScript और HTML इस्तेमाल करने को कहता हूँ
  double pendulum से लेकर fluid simulation तक, सब एक ही बार में ठीक चल जाता है, जबकि पहले इन चीज़ों में सैकड़ों dependencies होती थीं
  अगर code MIT license में है, तो मैं Opus से कह सकता हूँ कि सिर्फ ज़रूरी हिस्से ठीक-ठीक निकालकर मेरे उपयोग के हिसाब से बदलकर शामिल कर दे
  hobby projects में यह अब तक ठीक चला है, और आगे चलकर अच्छा होगा अगर production software भी dependency-free हो सके

  • ऐसा करने पर हर बदलाव और ढेरों edge cases आपको खुद संभालने पड़ेंगे
    अगर Chrome किसी API का shape बदल दे तो आपको खुद ढूँढकर ठीक करना होगा, और अगर Morocco daylight saving time शुरू होने की तारीख बदल दे तो date/time handling code भी खुद अपडेट करना होगा
    ये वे चीज़ें हैं जिन्हें libraries हमारे लिए संभालती रही हैं, इसलिए हम उन्हें सहज मान लेते हैं
    आपकी बेटी शायद अगले हफ़्ते जिस double pendulum simulator में रुचि खो दे, उसके लिए यह बड़ी बात नहीं, लेकिन ऐसी चीज़ बनाने वाली कंपनी के लिए जो अनिश्चित काल तक चलनी है, यह समस्या है
  • अब आप असली dependency यानी browser के संपर्क में आ गए हैं
  • बेशक आप Opus द्वारा बनाई गई code की हर line को उतनी ही सावधानी से review करेंगे जितनी आप open source maintainers से उम्मीद करते हैं, है ना?
    शायद मुझे MIT license वाला कोई remote access code public करना चाहिए ताकि वह Opus training data में पहुँच जाए
  • मुझे Rust, Go से ज़्यादा पसंद है, इसलिए यह दुविधा है। LLM के नज़रिये से भी Rust बेहतर है, लेकिन Rust की dependency philosophy व्यवहार में security black hole जैसी है, और Go कहीं बेहतर है
  • क्या आपने कुछ ऐसा किसी shareable repository या forge पर डाला है? मेरे पास farm animals spelling game है, और मैं अपनी library बढ़ाकर और ideas जोड़ना चाहता हूँ

• जब मैं Fast.AI का deep learning course कर रहा था, तब मैं machine learning projects के साथ आने वाली Python dependencies की संख्या देखकर चौंक गया था
  web frontend projects में third-party dependencies हमेशा ज़्यादा मानी जाती रही हैं, लेकिन मुझे machine learning ecosystem उससे कहीं ज़्यादा उलझा हुआ लगता है
  ऊपर से, web development को लंबे समय से security-sensitive माना गया है, इसलिए उसमें security wisdom और practices जमा हुई हैं, लेकिन machine learning development बहुत ज़्यादा ad-hoc लगता है और उस पर सामान्य software engineering practices भी कम लागू होती दिखती हैं
  उदाहरण के लिए, उस समय machine learning models deploy करने का एक तरीका Python pickle था, जो मूल रूप से बिना किसी restriction के executable object है
  इस format के models import करने वाले कंप्यूटर पर कुछ भी कर सकते थे, और ऐसा शुरुआती lawless ecosystem security breaches और supply chain attacks को और आसान बना सकता है

  • उस ecosystem में शुरू से बहुत-से लोग ऐसे हैं जो मूल रूप से software engineers नहीं हैं
    कुछ ने काम करते-करते थोड़ा coding सीखा, कुछ mathematicians हैं, और कुछ AI के नशे में developers जैसे हैं
    “अब code महत्वपूर्ण नहीं, बस चलना चाहिए” जैसी सोच भी है
    बहुत-से लोगों के लिए सही dependency management बस एक परेशान करने वाला काम है जिस पर वे ध्यान नहीं देना चाहते
    कई machine learning projects में ये सारे factors एक साथ आते हैं, जबकि सच तो यह है कि machine learning projects उन क्षेत्रों में हैं जहाँ reproducibility पर सबसे ज़्यादा ध्यान होना चाहिए

• repository search करने पर दिख रहा है कि पिछले एक दिन में बनी repositories में "A Mini Shai-Hulud has Appeared" टेक्स्ट वाली 2.2 हज़ार repositories हैं: https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...

  • repositories के नाम सब dune के दो terms/words जैसे harkonen, mentat, ornithoptor आदि के साथ कोई number जुड़े हुए लगते हैं
    यह इस बात का संकेत लगता है कि account, शायद GitHub auth/Actions token, compromise होने के बाद repository creation के लिए इस्तेमाल हुआ
  • https://github.com/tinin46 इस account में बहुत-सी keys stored लगती हैं, लेकिन उनका purpose स्पष्ट नहीं है
  • समझ नहीं आता GitHub तुरंत कार्रवाई करके regex से match होने वाली README वाली repositories को block क्यों नहीं कर सकता
    पिछली बार भी ऐसा हो चुका है, तो लगा था कि उन्होंने उससे कुछ सीखा होगा
    इस malware ने भी कोई ख़ास मेहनत नहीं की, और Microsoft भी ज़्यादा कोशिश करता नहीं दिखता
  • यह आखिर हो क्या रहा है?

• साफ़ कर दूँ, मैंने कभी pytorch इस्तेमाल नहीं किया और software security practices की भी ज़्यादा जानकारी नहीं है
  लेकिन मुझे ऐसे scenarios ज़्यादा समझ नहीं आते जहाँ pytorch को network access चाहिए हो
  codebase में कहीं से भी कोई भी module import करके उसका API इस्तेमाल कर लेना गलत लगता है
  शायद अतिरिक्त import restrictions या static analysis की ज़रूरत है
  लगता है language में इस समस्या से निपटने के लिए सही abstraction नहीं है
  तुलना के लिए, Rust में सिर्फ function signature देखकर भी, अंदर का code समझे बिना, mutability और lifetimes देख पाना मुझे पसंद है
  dependencies के लिए भी कुछ वैसा ही चाहिए
  developer को नीचे का code खंगाले बिना आसानी से सारी dependencies audit कर पाना चाहिए, ताकि वह देख सके, “अच्छा, यह dependency eval() इस्तेमाल करती है” या “यह network access करती है”
  mobile apps में permissions enforce होते हैं, तो developers को भी शायद specific features ही allowlist करने की सुविधा होनी चाहिए, न कि सारी capabilities एक साथ स्वीकार करनी पड़ें

  • Python ecosystem शायद ऐसी चीज़ कभी अनुमति नहीं देगा, लेकिन अच्छा होगा अगर यह विषय वहाँ बेहतर समझा और स्वीकार किया जाए
    सामान्यीकरण नहीं करना चाहता, लेकिन खासकर AI development community में convenience को बाकी सभी बातों पर तरजीह दी जाती लगती है
    उदाहरण के लिए, किसी project का पहली run पर बड़े models auto-download कर लेना लगभग standard जैसा बन चुका है
    आम तौर पर इसे disable किया जा सकता है, लेकिन कई libraries में फैली code classes की गहरी layers के कारण सही parameters ढूँढना सचमुच कष्टदायक होता है
    complex चीज़ों को, जो अक्सर खिलौनों जैसी ही होती हैं, बहुत आसानी से शुरू कर पाना अच्छा है, लेकिन यह permissive माहौल काफ़ी असहज करता है
    अक्सर पहला troubleshooting step हमेशा “pip install …” ही लगता है, और कुछ environments, जैसे MacOS, GPU access virtualization भी ठीक से नहीं करते
  • कभी-कभी model को कई compute nodes पर train किया जाता है। यह network access की बड़ी ज़रूरत वाला मामला है

• इस हफ़्ते मैं सोच रहा था कि Python version management के लिए uv इस्तेमाल करना अच्छा विचार है या नहीं
  website [1] पर लिखा है, “Python official distribution binaries नहीं देता, इसलिए uv Astral python-build-standalone project की distributions इस्तेमाल करता है”
  यह GitHub repository https://github.com/astral-sh/python-build-standalone की ओर इशारा करता है, और वहाँ आगे https://gregoryszorc.com/docs/python-build-standalone/main/r... का उल्लेख है
  अगर मैं सही समझ रहा हूँ, तो Python build का source code सीधे python.org से नहीं लिया जाता, और मुझे नहीं पता यह कितना सुरक्षित है
  asdf [2] को लेकर भी वही चिंता है, लेकिन asdf pyenv [3] इस्तेमाल करता है और वह थोड़ा ज़्यादा official-सा लगता है
  Python install करने के लिए uv और asdf में कौन-सा tool बेहतर और ज़्यादा सुरक्षित है, क्या कोई समझा सकता है?
  [1] https://docs.astral.sh/uv/guides/install-python/
  [2] https://github.com/asdf-community/asdf-python
  [3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...

  • python-build-standalone CPython source सीधे python.org से ही लाता है[1]
    और भला वह और कहाँ से लाता?
    [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
  • uv और cpython को लेकर मुझे ज़्यादा चिंता नहीं है। process मज़बूत है, response तेज़ है, और अब funding भी काफ़ी है
    चिंता mdformat जैसे formatter की होती है, जो बहुत इस्तेमाल होता है लेकिन मुख्यतः एक व्यक्ति के spare time में maintain होता है, या कोई बहुत specific dependency जो dependency tree में 3 levels नीचे है और वर्षों से update नहीं हुई
    मैं actively developed app में हर update pin करके manually approve नहीं करना चाहता, लेकिन किसी serious app के लिए अब यह लगभग अनिवार्य लगने लगा है
    इस बीच मुझे unencrypted .env file से API keys उठानी पड़ेंगी
    बड़े consumer webapp में ऐसा हो जाए तो शर्मनाक है लेकिन समझ आता है, पर उसी host और system पर संयोग से मौजूद किसी toy demo repository की indirect dependency के कारण सैकड़ों या हज़ारों dollars खो देना बहुत दर्दनाक है
    क्या किसी को पता है कि अगर keys इस तरह चोरी हो जाएँ, तो OAI या Anthropic refund करते हैं? या यह user error माना जाएगा?
  • आखिर uv खुद एक binary है जिसे आप कंप्यूटर पर चलाते हैं और जो Python binaries, packages, उनके अंदर की binaries, system-wide tools आदि manage करता है
    Python binary उन्होंने खुद build की हो या किसी और ने, इससे risk कितना बदलता है, मुझे स्पष्ट नहीं है

• आजकल मेरे pip install का बड़ा हिस्सा Claude Code सुझाता है और मैं बस Enter दबा देता हूँ
  model कुछ महीने पुराने data पर trained है, इसलिए उसे क्या पता इस हफ़्ते क्या compromise हुआ है
  मैंने “यह package अभी सुरक्षित है या नहीं” तय करने के लिए लगभग सबसे खराब filter बना लिया है

  • आलस्य और due diligence की कमी का दोष LLM पर नहीं डालना चाहिए
  • किस filter की बात हो रही है?
    आपका मतलब यह है कि Claude Code internet से install करने के लिए software recommend करता है, और आप उसे वैसे का वैसा install कर देते हैं
    मैंने कभी नहीं सुना कि Claude Code या कोई LLM “यह package अभी सुरक्षित है या नहीं” तय करने वाला filter है, और आपके बताए कारण सहित यह बहुत खराब heuristic लगता है
  • पुराना training data एक कारण है, लेकिन latest model भी यह नहीं जान सकता कि setup.py आपकी machine पर क्या चलाएगा
    क्योंकि execution से पहले package को वास्तव में inspect करने की कोई चीज़ नहीं है
    ज़रूरत ऐसे tool की है जो execution से पहले metadata लाकर बताए कि कौन-कौन से hooks हैं
  • अगर आप Enter न दबाएँ तो इसे आसानी से टाला जा सकता है
  • “सबसे खराब filter” से मतलब Claude जो कहे उसके अनुसार Enter दबाना है क्या?

• Claude Code लगभग रोज़, कभी-कभी दिन में कई बार update होता है
  जिस दिन Anthropic compromise हुआ, उस दिन हम सबकी बुरी हालत होगी

  • “हम” से आपका मतलब कौन है?
  • अगर आप उसे बिना privileges वाले VM/container में limited network access के साथ चलाएँ, तो ऐसा नहीं होगा
    लेकिन आजकल सब कुछ YOLO मोड में चल रहा है
  • लगता है यह पहले से ही Polymarket price में शामिल होगा

• मैंने GitHub पर 20 अप्रैल की यह message देखी और थोड़ा confused हूँ
  "deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."
  अगर उन्हें तब से समस्या का पता था और अब तक चेतावनी नहीं दी, तो यह बहुत बुरा लगेगा
  अगर किसी को ज़्यादा जानकारी है, तो कृपया साफ़-साफ़ समझाए
  https://github.com/Lightning-AI/pytorch-lightning/issues/216...

  • मैं Lightning का Andy हूँ। malicious package आज UTC 12:45 PM पर PyPI पर publish हुआ था
    उससे पहले कोई affected distribution नहीं थी, और हमें leak की जानकारी भी नहीं थी
    GitHub की original release में कोई समस्या नहीं थी, लेकिन confusion से बचने के लिए उसे नीचे रखा गया है
  • जो लोग uv इस्तेमाल करते हैं, उनके लिए: https://docs.astral.sh/uv/reference/settings/#exclude-newer