xz Utils बैकडोर के बारे में अब तक क्या पता है, जिसने लगभग पूरी दुनिया को संक्रमित कर दिया होता

xz Utils बैकडोर मामला: उस घटना के बारे में क्या पता है, जिसने लगभग पूरी दुनिया को संक्रमित कर दिया होता

• xz Utils एक data compression utility है, जो Linux सहित लगभग सभी Unix-परिवार के operating systems में इंस्टॉल होती है.
• इस software में एक malicious update के जरिए बैकडोर डालने की कोशिश की गई.
• Microsoft के एक डेवलपर ने इस बैकडोर को खोजकर सार्वजनिक किया, जिससे यह Debian और Red Hat जैसे प्रमुख Linux distributions में शामिल होने से ठीक पहले रोका जा सका.

बैकडोर कैसे काम करता है?

• version 5.6.0 और 5.6.1 में जोड़ा गया malicious code sshd, यानी SSH connection के executable, के साथ छेड़छाड़ करता है.
• जिस व्यक्ति के पास एक खास cryptographic key हो, वह SSH login certificate में code छिपाकर अपलोड कर सकता है और बैकडोर लगे device पर उसे चला सकता है.
• वास्तव में कौन-सा code अपलोड किया गया था, यह ज्ञात नहीं है, लेकिन सैद्धांतिक रूप से cryptographic key चोरी करने या malware इंस्टॉल करने जैसे कई काम संभव थे.

बैकडोर कैसे डाला गया

• लगता है कि यह बैकडोर कई सालों में तैयार किया गया था.
• 2021 में JiaT75 नाम के एक यूज़र ने पहली बार open source project में योगदान दिया.
• जनवरी 2023 में JiaT75 ने xz Utils में पहला योगदान किया, और बाद में Jia Tan नाम से धीरे-धीरे अधिक ज़िम्मेदारियां संभालने लगा.
• Tan ने oss-fuzz project में Collins की contact information को अपनी जानकारी से बदल दिया और testing के दौरान ifunc feature को disable करने का अनुरोध किया.
• इन बदलावों ने Tan द्वारा xz Utils में किए गए malicious changes का पता लगाना मुश्किल बना दिया.

प्रभावित distributions

• Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed और MicroOS, Kali Linux आदि में बैकडोर वाले xz versions शामिल थे.

GN⁺ की राय

• यह घटना open source ecosystem की security कमजोरियों को उजागर करती है और डेवलपर समुदाय के लिए चेतावनी का काम करती है.
• चूंकि बैकडोर वाला software व्यापक रूप से इस्तेमाल होता है, यह मामला Linux users और admins को तेज़ी से update करने और security checks की अहमियत याद दिलाता है.
• इसी तरह का एक उदाहरण SolarWinds hacking incident था, जिसने भी supply chain attack के खतरों को दिखाया था.
• open source projects में योगदान देने वाले डेवलपर्स की पहचान सत्यापित करना और code review process को मज़बूत करना ज़रूरी है.
• इस घटना के बाद security audits और vulnerability detection tools की अहमियत और बढ़ने की संभावना है.

[GN⁺]

Hacker News राय

• OpenSSH सबसे लोकप्रिय sshd implementation है, और यह liblzma लाइब्रेरी से लिंक नहीं होता, लेकिन Debian और कई अन्य Linux distributions ऐसे patches जोड़ते हैं जो sshd को systemd से जोड़ते हैं। systemd liblzma से लिंक होता है, इसलिए xz Utils का sshd पर असर पड़ सकता है।

• Xz एक open source compression program और लाइब्रेरी है, जो compressed data को संभालने के लिए अपने खुद के programs लिखने में मदद करती है। इसका उपयोग OpenSSH सहित कई अन्य programs में होता है।

• GNU का binutils भी liblzma से लिंक होता है, और यह OpenSSH से भी अधिक व्यापक रूप से इस्तेमाल होता है। अधिकांश मामलों में binutils का उपयोग OpenSSH, sshd चलाने वाले operating system आदि को compile करने में होता है। इससे संकेत मिलता है कि दुर्भावनापूर्ण actors ने open source software में गहराई तक घुसपैठ करने के लिए सही project चुना था।

• लक्ष्य यह है कि XZ project की स्थिरता को लंबे समय तक बेहतर बनाने के लिए एक standardized test framework इस्तेमाल किया जाए, जिससे अधिक tests लिखने में मदद मिले। अभी कई features का test नहीं हुआ है, इसलिए ऐसे tests उपयोगी होंगे।

• RSA_public_decrypt फ़ंक्शन से लिंक हो सकने वाले linking mechanism पर बहुत चर्चा नहीं हुई। process separation जैसी तकनीकों से क्या हासिल किया जा सकता है, इस पर तो काफी बात हुई, लेकिन उस function call redirection पर कम ध्यान दिया गया। यह सवाल उठता है कि क्या महत्वपूर्ण components को trust-tier तरीके से जोड़ने का कोई तरीका स्थापित किया जा सकता है।

• कहा जा रहा है कि दुनिया "लगभग" संक्रमित हो गई होती, लेकिन वास्तव में Arch, Gentoo, OpenSUSE Tumbleweed जैसी लोकप्रिय Linux distributions कई हफ्तों तक backdoor शामिल करके वितरित की गईं, और Tumbleweed में यह निश्चित रूप से काम भी कर रहा था। "लगभग" कहना उचित नहीं है।

• अनुमान है कि अगले 12 महीनों के भीतर इसी तरह का एक और मामला सामने आएगा। इसकी शुरुआत maintainers द्वारा एक-दूसरे के पुराने commits पर शक करने से होगी।

• इस घटना से मिले व्यक्तिगत सबक:

  • source repository से अलग code शामिल करने वाले source distribution tarball बुरे हैं। इस तरीके से दूर जाना चाहिए।
  • auto-generated artifacts को हमेशा commit किया जाना चाहिए।
  • code review के दौरान जिन auto-generated artifacts को हर कोई सरसरी तौर पर देखता है, वे समस्या बन सकते हैं। अगर इस तरह की files repository में हैं, तो यह जांचने के लिए automated tests होने चाहिए कि किसी ने उनके साथ छेड़छाड़ तो नहीं की।
  • autotools और autotools संस्कृति खराब है।
  • libsystemd ecosystem में समस्याएं पैदा करता है। systemd की आलोचना करने वालों को अक्सर नज़रअंदाज़ किया जाता है, लेकिन systemd बड़ा, जटिल और बहुत dependencies वाला है, और अधिकांश programs उसका सिर्फ एक छोटा हिस्सा इस्तेमाल करते हैं।
  • यह संस्कृति कि code reuse हमेशा अच्छा है, और छोटे feature के लिए बड़े library पर निर्भर रहना भी अच्छा है, गलत है। dependencies maintenance burden और security risk लाती हैं, इसलिए इन्हें functionality के साथ संतुलित करना चाहिए।
  • distribution maintainers द्वारा packages पर बड़े पैमाने पर patches लागू करना समस्याजनक हो सकता है। इससे ऐसे व्यापक रूप से उपयोग किए जाने वाले de facto forks बनते हैं, जिन्हें वास्तव में कोई maintain नहीं कर रहा होता।
  • developers के लिए OSS पर काम को आर्थिक रूप से संभव बनाना चाहिए। liblzma और xz-utils करोड़ों installations में मौजूद हैं, लेकिन इन्हें संभालने के लिए मानसिक स्वास्थ्य समस्याओं से जूझ रहा एक ही maintainer था।
  • code review और maintainer replacement में अब मौजूदा geopolitical considerations को भी ध्यान में रखना चाहिए।

• इस समस्या को खोजने वाला व्यक्ति Azure Postgres पर काम करने वाला Microsoft engineer था, इसके लिए आभार व्यक्त किया गया। अब Azure पसंद आने लगा है।

• xz के मूल maintainer ने जिम्मेदारी Jia Tan को सौंप दी थी, लेकिन हो सकता है कि उसने उससे कभी व्यक्तिगत रूप से मुलाकात या phone call तक न की हो। यह सवाल उठाया गया कि क्या सिर्फ email/GitHub के जरिए संवाद करना सामान्य बात है। उम्मीद है कि इस कहानी के बाद open source projects के maintainers अधिक सतर्क होंगे।

• जबकि लोग सोचते हैं कि यह backdoor जल्दी पकड़ लिया गया, संभव है कि यह पहले ही अपना उद्देश्य पूरा कर चुका हो। खासकर अगर target वे developers थे जो Kali और Debian जैसी rolling release distributions इस्तेमाल करते हैं।

• यह संकेत मिलता है कि xz Utils के लंबे समय के maintainer Lasse Collin के बारे में यह दावा कि वह software को अक्सर या पर्याप्त तेजी से update नहीं करते थे, एक गलती थी।