Arch Linux ने अब malware घटना को नियंत्रित मान लिया: 1,500 से अधिक packages प्रभावित

 (phoronix.com/news)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Arch Linux के AUR user-contributed repository में malware-संक्रमित packages की संख्या पहले 400 से अधिक पाई गई थी, लेकिन अंततः यह बढ़कर 1,500 से अधिक हो गई
  • कुछ घंटे पहले के अपडेट में इस सप्ताह की घटना से प्रभावित packages की संख्या लगभग 900 बताई गई थी
  • इसके बाद Arch Linux डेवलपर्स ने पहचाने गए सभी malicious commits हटा दिए, और प्रभावित packages की संख्या 1,579 दर्ज की गई
  • 1,579 की सूची को भी प्रभावित packages की काफी बड़ी लेकिन पूरी नहीं सूची बताया गया, इसलिए कुल दायरा इससे बड़ा हो सकता है
  • user-maintained repository के बहुत से software इस security incident से प्रभावित हुए, और एक अलग अपडेट में अधिक परिष्कृत malware हमले की एक और लहर का उल्लेख किया गया

घटना का सार

  • Arch Linux उपयोगकर्ताओं के लिए AUR user-contributed repository में 400 से अधिक malware-संक्रमित packages मिलने के साथ यह घटना शुरू हुई
  • दिन के अंत तक Arch Linux पक्ष ने माना कि प्रभावित commits सभी संभाल लिए गए हैं, लेकिन प्रभावित packages की संख्या 1,500 से अधिक हो गई
  • यह घटना user-maintained Arch Linux repository के बहुत से software को प्रभावित करने वाली एक security incident थी

प्रभाव के दायरे में बदलाव

  • कुछ घंटे पहले के अपडेट में इस सप्ताह की घटना से लगभग 900 packages के malware से संक्रमित होने की बात सामने आई थी
  • इसके बाद security incident thread के अंतिम संदेश के अनुसार Arch Linux डेवलपर्स ने पहचाने गए सभी malicious commits हटा दिए
  • उद्धृत सूची में malware से प्रभावित packages की संख्या 1,579 दिखाई गई

बची हुई अनिश्चितता

  • 1,579 packages दिखाने वाली सूची को भी “प्रभावित packages की काफी बड़ी लेकिन पूरी नहीं सूची” के रूप में चिह्नित किया गया
  • इसलिए सार्वजनिक संख्या पुष्टि किए गए बड़े पैमाने के प्रभाव को दिखाती है, लेकिन सूची स्वयं सभी packages को शामिल नहीं करती

अनुवर्ती अपडेट

  • एक अलग अपडेट में कहा गया कि Arch Linux AUR पर अधिक परिष्कृत malware हमले की एक और लहर आई

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • जानना चाहता हूँ कि क्या AUR टीम ने कभी postmortem जारी किया है
    इस बार की प्रतिक्रिया प्रभावित करने वाली तेज़ थी, लेकिन ईमानदारी से कहें तो AUR policies हों या wrappers, बदलाव की ज़रूरत दिखती है
    pnpm की तरह minimum package age सेट कर पाना चाहिए, और orphan packages को कोई भी जाकर adopt न कर सके
    adoption पर global rate limit भी लगाई जा सकती है ताकि उसे attack signal की तरह इस्तेमाल किया जा सके, और जैसे NPM में कई कंपनियाँ करती हैं, वैसे publish समय पर vulnerability scan भी चाहिए
    हालाँकि इन बदलावों में से ज़्यादातर काम AUR maintainers से ज़्यादा packaging helpers और third parties के हिस्से का लगता है

    • AUR packages को namespace में बाँटना बेहतर होगा
      तब ownership गायब नहीं होगी, इसलिए orphan करने की ज़रूरत ही नहीं पड़ेगी
    • AUR repositories डाउनलोड करने के लिए कोई official tool नहीं है, इसलिए वह हिस्सा हर कोई अपने-अपने तरीके से संभालता है
    • pnpm से प्रेरित होकर मैंने हाल ही में pakku में minimum AUR age जोड़ने वाला patch [1] बनाया है
      [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
      [2] https://github.com/zqqw/pakku
    • अगर orphan package adoption को बहुत ज़्यादा रोका जाए, तो जिन packages का सही maintenance हो सकता है वे भी यूँ ही पड़े रह सकते हैं
      restrictions ज़रूरी हैं, लेकिन जैसे कुछ समय पहले से registered users को महीने में 1 adoption तक सीमित करना ठीक लग सकता है
      वैसे भी local machine पर installed AUR packages पर कोई automatic, unreviewed updates लागू नहीं करता होगा, इसलिए attack surface पहले से ही काफ़ी छोटी है
    • साधारण vulnerability scanning से शायद यह पकड़ा ही नहीं जाता
      miasma worm की जड़ यही है कि signatures और helper तरीक़े बहुत तेज़ी से बदलते हैं
      encrypted malicious implant uploaded GitHub location के हिसाब से बदलने वाली AES-128-GCM key से payload को decrypt करता है, और code के method names भी dynamically बदलते हैं, साथ ही encrypted symbol offsets को मिलाकर दोबारा इस्तेमाल करता है
      यह polymorphic malware है, इसलिए signature-based tools के लिए सबसे बुरा प्रतिद्वंद्वी है
      APT28/29 कुछ हद तक इस बात पर निर्भर दिखते हैं कि GitHub पर C2 infrastructure के रूप में इस्तेमाल हो रहे users और repositories को Microsoft अपने-आप block करने में धीमा है
      इसका security strategy के लिए क्या मतलब है, इस पर सोचने की ज़रूरत है
      जब तक आप signatures या strings scan कर पाते हैं, तब तक आप पहले ही पूरी तरह automated botnet के साथ cat-and-mouse game में पहुँच चुके होते हैं, और उसे जीता नहीं जा सकता
      पिछले हफ़्ते भर में इस implant के बदलावों को track करने वाला supply-chain tool शायद सिर्फ socket.dev था, जबकि दूसरे tools Miasma को पहचान भी नहीं पाए और उसे नई campaign समझकर फिर से खोजते रहे
      नए ecosystem adapters हर 24 घंटे में आ रहे थे, लेकिन payload को उतनी तेज़ी से reverse engineer करने के लिए लोगों और toolchain की कमी थी
      यहाँ fully automated का मतलब यह है कि दूसरे package ecosystems में 48 घंटे से भी कम समय में चोरी किए गए credentials पहले ही इस्तेमाल हो रहे हैं
      email addresses और names बार-बार सामने आ रहे हैं, और लगता है कि वे ऐसे लोग हैं जिन्हें शायद इस self-propagating worm के असर का अंदाज़ा ही नहीं था
      उदाहरण के लिए bun पर निर्भर packages खोजने वाले indicators of compromise भी बहुत मददगार नहीं हैं
      malware बस किसी बाहरी तरीके से फिर से डाउनलोड किया जा सकता है
      दूसरी PyPI campaign में, PyPI maintainers को RedHat campaign की पहली malicious dropper wave दिखने के बाद, इसे बदलकर compressed WHL files और auto-executed setup.pth files के ज़रिए dropper डाउनलोड कराया गया
      जब तक इन ecosystems के package managers को शुरू से chroot, sandbox, network·domain logs, और per-entry allowlists को ध्यान में रखकर दोबारा नहीं लिखा जाता, तब तक supply-chain attacks के ज़रिए malware distribution की strategy व्यावहारिक बनी रहेगी
      mitigation tools का repository [1] है, और technical details blog post [2] में हैं
      Composer, Rubygems, NPM, PyPI, Go — सब प्रभावित हैं; यह सभी package managers में फैली समस्या है
      package managers में कितनी लापरवाही और external trust जोड़ा हुआ है, इस पर ज़्यादा खुलकर चर्चा होनी चाहिए, और यह सच में बदलना चाहिए
      [1] https://github.com/cookiengineer/antimiasma
      [2] https://cookie.engineer/weblog/articles/malware-insights-mia...

  • जब AUR से सीधे install किए जा सकने वाले pacman wrappers आने लगे थे, तब यह मुझे सच में असुविधाजनक लगा था
    मैंने AUR से कुछ install किया है, लेकिन ज़्यादातर मामलों में मैं बीच के कदम छोड़कर सीधे project website पर जाना पसंद करता हूँ
    पहले से तैयार PKGBUILD इतने सुविधाजनक नहीं लगते कि typosquatting या npm·pip dependency abuse के जोखिम को सही ठहराया जा सके

    • yay जैसे wrappers हर update पर PKGBUILD diff दिखाते हैं
      पहली install के समय URL जाँचा जाता है और देखा जाता है कि install scripts वगैरह ठीक लग रही हैं या नहीं, और उसके बाद updates में ज़्यादातर सिर्फ version number और checksum बदलते हैं
      typosquatting attack काफ़ी साफ़ नज़र आएगा
      पहली install थोड़ी vulnerable ज़रूर है, लेकिन project website पर जाकर download बटन दबाने का तरीका भी ऐसा ही है
    • Arch पर elitist होने या आम users को दूर रखने का आरोप बार-बार लगता है, लेकिन ख़तरनाक कामों को आसान न बनाना अपने आप में एक स्पष्ट फ़ायदा है
      ज़िंदगी के कई और पहलुओं में भी यही बात लागू होती है
      Void Linux इस्तेमाल करने के बाद मैंने Arch पर भी ऐसी ही separation के लिए aurutils अपना लिया
      इससे सीधे build करके local AUR repository को आसानी से maintain किया जा सकता है, और pacman से install·manage करने पर पूरा upgrade process बेहतर हो जाता है
    • यह समझौता मेरे लिए कोई ख़ास मूल्य नहीं रखता
      मैंने Linux पर इसलिए switch नहीं किया था कि Windows users की तरह website पर जाकर “download” दबाऊँ और programs update करने में समय बर्बाद करूँ
      फिर भी, जिन pacman wrappers का ज़िक्र हुआ है वे जोखिमभरे लगते हैं
    • AUR और दूसरी distros के ऐसे ही repositories सच में डरावने लगते हैं
      इन repositories का इस्तेमाल करने वाली tutorials इतनी व्यापक हैं कि कभी-कभी ऐसा लगता है जैसे मैं ही अजीब हूँ, क्योंकि मैं किसी अनजान व्यक्ति को, लगभग बिना किसी peer review के, अनिश्चित समय के लिए root access नहीं देना चाहता
      और यह सब सिर्फ किसी ऐसे package का एक version install करने के लिए, जिसे शायद update की ज़रूरत ही न पड़े या बहुत कम पड़े

  • जल्दी से पढ़ने पर लगा कि npm से atomic-lockfile, js-digest, lockfile-js इंस्टॉल किए गए थे
    प्रभावित packages की सूची [1] में है
    सिस्टम चेक करने का तरीका मुझे तुरंत नहीं मिला, इसलिए external packages और तारीख से जुड़ी जानकारी देखने के लिए मैंने pacman -Qmi चलाया
    output को प्रभावित packages की सूची से मिलान कर सकते हैं
    इसके अलावा कई locations में इस तरह files खोजी जा सकती हैं
    grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
    grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
    grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
    पता नहीं run होने के बाद package खुद को delete करता है या नहीं
    बाकी जानकारी बहुत मददगार नहीं लगी, इसलिए सोचा कम-से-कम basic commands ही share कर दूँ
    [1] https://md.archlinux.org/s/SxbqukK6IA

    • मैंने यह तरीका अपनाया
      yay से AUR से आए installed packages की सूची ली: yay -Qam > packages_aur.last
      https://md.archlinux.org/s/SxbqukK6IA# से सूची ली: curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
      फिर grep -wFf compromised.txt packages_aur.last चलाने पर वे packages मिल जाने चाहिए जो दोनों files में हैं, यानी ऐसे packages जो किसी समय compromised थे
    • हमलावर ने कम-से-कम तीन Node dependencies इस्तेमाल की थीं, इसलिए सिर्फ atomic-lockfile देखना काफी नहीं है
      js-digest और lockfile-js भी इस्तेमाल हुए थे, और किसी समय npm की जगह bun पर switch किया गया था
    • यह भी देखने लायक है: https://github.com/lenucksi/aur-malware-check
    • मज़ेदार बात यह है कि Arch Linux AUR में malware डालने की कोशिश वाली स्थिति में भी malware अब भी NPM के ज़रिए distribute होता है
      क्या legendary platform है
    • emacs-magit कैसे प्रभावित हुआ, यह समझ नहीं आ रहा
      जहाँ तक मुझे पता है, उसमें JavaScript बिल्कुल नहीं है

  • यह हमेशा की तरह एक उचित याद दिलाना है कि बिना review किए मनमाने third-party packages, libraries, applications इंस्टॉल नहीं करने चाहिए
    अच्छी बात है कि यह मामला AUR तक सीमित था, और AUR दरअसल ऐसा package repository है जहाँ लगभग कोई भी upload कर सकता है; official repositories के विपरीत, install करने से पहले review ज़रूरी है, इस बारे में कई बार चेतावनी दी गई है
    rua जैसे command-line tools AUR से install करने से पहले packages का review करना आसान बनाते हैं
    अगर आप उसी computer पर banking भी करते हैं, तो जिस software पर निर्भर हैं उसका review न करने का कोई बहाना नहीं है
    package count कम रखें और सिर्फ ज़रूरी चीज़ें इस्तेमाल करें, तो upgrade के समय भी चीज़ें बहुत सरल रहती हैं

    • “review” कैसे करें
      क्या install करने से पहले code की हर एक line पढ़नी होगी
      और अगर binary package हो तो क्या करें
      क्या जो कुछ भी install करें, उसके लिए reproducible build बनाना होगा, या फिर source-based distribution पर चले जाएँ
      यह ज़िम्मेदारी user पर डालना कोई sustainable solution नहीं है
      common sense की गुंजाइश है, लेकिन इसके लिए user को blame करना ठीक नहीं है
    • सुनने में ठीक लगता है, लेकिन आखिरकार यह ऐसा सलाह है जिस पर अमल करना संभव नहीं, इसलिए यह बेकार ही नहीं बल्कि नुकसानदेह भी है
      दुनिया में code की मात्रा इतनी ज़्यादा है कि एक इंसान पूरी ज़िंदगी में जितना पढ़ सकता है उससे कहीं अधिक है
      संभव है आपने अपने computer पर अभी चल रहे source code का 1% भी न पढ़ा हो
      तो क्या आपने computer इस्तेमाल करना छोड़ दिया
      फिर उसके भीतर हो रही चीज़ों पर भरोसा कैसे करेंगे
    • मेरा मानना है कि “install से पहले ज़रूर review करें” वाले रुख का फिर से मूल्यांकन होना चाहिए
      Arch Linux developers शानदार काम करते हैं और मैं व्यक्तिगत रूप से आभारी हूँ, लेकिन आजकल supply-chain attacks जिस तरह बढ़ रहे हैं, उसमें सिर्फ user warnings से काम चलने की सीमा बहुत पहले आ चुकी लगती है
      आसान समाधान दिखाई नहीं देता, लेकिन publish से पहले peer review या waiting period जैसे controls कुछ हद तक समस्या कम कर सकते हैं
    • AUR को लंबे समय से Arch की बड़ी ताकत माना गया है, लेकिन उसकी सुविधा की एक कीमत रही है
      यह बेतुका है कि package को orphan mark करके 2 हफ्ते इंतज़ार किया जाए, और अगर मूल maintainer छुट्टी पर होने के कारण जवाब न दे पाए, तो हमलावर maintainer बनकर malicious update जारी कर सके
    • इसे immutable system files, default user-local installs, और components व programs को न्यूनतम privileges देने वाले संयोजन के पक्ष में एक मज़बूत तर्क मानता हूँ
      immutable distributions, Wayland, Flatpak में इसके कुछ हिस्से हैं, लेकिन महत्वपूर्ण खामियाँ अब भी बाकी हैं
      सबसे बड़ी समस्या यह है कि sandboxing package format से बँधी हुई है, और मुझे लगता है यह गलती है
      sandboxing और access permissions system-level features होने चाहिए, ताकि arbitrary binaries भी आसानी से बचकर न निकल सकें
      इससे समस्या पूरी तरह हल नहीं होगी, लेकिन नुकसान का दायरा काफ़ी कम हो सकता है और distro users को कम आकर्षक target बनाया जा सकता है

  • जो लोग चिंतित हैं, उनके लिए मुझे एक repository मिली है जो updated scripts और package lists इकट्ठा करती है ताकि infection check करने में मदद मिल सके: https://github.com/lenucksi/aur-malware-check

    • मैंने वही सूची (https://md.archlinux.org/s/SxbqukK6IA) Claude को देकर malware check कराया, और उसने मूल रूप से वही verification किया जो यह script करती है
      किसी भी तरीके से शायद काम चल जाएगा

  • मैं Arch Linux यूज़र नहीं हूँ, लेकिन NodeJS का काफ़ी इस्तेमाल करता हूँ, और वहाँ भी ऐसे ही हमले अक्सर देखने को मिलते हैं
    आजकल जिज्ञासा होती है कि package management ठीक से और सुरक्षित तरीके से आखिर कहाँ किया जाता है

    • AUR यूज़र-सपोर्ट आधारित है, इसलिए malware अक्सर packages में घुसकर आ जाता है
      इस बार जैसा इतना बड़ा पैमाना नहीं था, लेकिन शुरुआत से ही यह साफ़ था कि यह सुरक्षित नहीं है, और जगह-जगह जोखिम की चेतावनियाँ लगी हुई थीं
    • Linux distributions यह काम अच्छी तरह कर रही हैं
      सब जगह packages की समीक्षा करने और ज़िम्मेदारी लेने वाले maintainers होते हैं
      Arch Linux में भी यही बात लागू होती है
      AUR की मूलभूत अविश्वसनीयता Arch Wiki और उसके आसपास की संस्कृति में हमेशा साफ़ तौर पर बताई गई है, और यह npm या pip जैसे programming language package managers से अलग है
    • अगर AUR का इस्तेमाल न करें, तो Arch ठीक है
      अगर AUR का इस्तेमाल करें, तो हर चीज़ जाँचनी चाहिए
      ज़्यादातर distributions भी ठीक हैं, और बड़े distributions का रिकॉर्ड काफ़ी अच्छा रहा है
    • लगता है Node ecosystem में कुछ ऐसा है जो इसे खास तौर पर कमज़ोर बनाता है
      शायद इसकी वजह हद से ज़्यादा DRY culture हो, या कोई और कारण
      मैंने जो इस्तेमाल किए हैं, उनमें dependency tree के ऐसे दुःस्वप्न जैसा कुछ नहीं देखा

  • AUR में 15,000 orphan packages हैं
    आज सुबह मैंने इन्हें लोकप्रियता के हिसाब से sort किया और उनमें से लगभग अपडेट न होने वाले 3 packages adopt करके build किए
    अगर आप orphan packages इस्तेमाल कर रहे हैं, तो बुरे लोग उन्हें ले लें उससे पहले खुद adopt करने पर विचार किया जा सकता है

  • मैं गलत भी हो सकता हूँ, लेकिन यह स्थिति desktop Linux adoption बढ़ने का संकेत लगती है

  • मुझे कभी AUR की ज़रूरत नहीं पड़ी
    अगर official repository में न होने वाला कोई package चाहिए होता है, तो मैं उसे खुद build करता हूँ, या binary release हो तो उसे डाउनलोड कर लेता हूँ
    ऐसा करने से build के समय root की ज़रूरत नहीं पड़ती, और program को single-user के लिए local install किया जा सकता है, इसलिए ज़्यादातर desktop use cases के लिए यह तरीका उल्टा ज़्यादा उपयुक्त है
    कम-से-कम developer → user path की तुलना में developer → maintainer → user के रूप में malicious code injection की एक अतिरिक्त संभावना कम हो जाती है

    • makepkg root के रूप में चलाने पर सक्रिय रूप से मना करता है
      जब तक आप जानबूझकर env EUID=123 makepkg ... जैसी किसी तरकीब से इसे bypass न करें, यह root पर नहीं चलता
      हालांकि, अच्छा होगा अगर pacman user-level installation को support करे
      फिलहाल यह root न होने पर installation से मना करता है, और workaround के तौर पर user namespace में खुद को root पर map किया जा सकता है

  • मैं समझता हूँ कि इस बार मामला AUR का था
    AUR हो या न हो, package install करते समय आप कौन-कौन से steps लेते हैं, और जिस package व dependencies को install करने जा रहे हैं वे malware नहीं हैं, यह कैसे सुनिश्चित करते हैं, अगर लोग यह साझा करें तो अच्छा होगा
    कोई खराब package install हो जाने के बाद सच में उसे वापस पलटना बहुत मुश्किल लगता है