दुनिया भर को लगभग संक्रमित कर देने वाले xz Utils backdoor के बारे में अब तक क्या पता है

 (arstechnica.com)
3 पॉइंट द्वारा GN⁺ 2024-04-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Microsoft के Andres Freund ने Debian सिस्टम में SSH performance anomaly को ट्रैक करते हुए, लगभग सभी Linux/Unix-जैसे environments में इस्तेमाल होने वाले xz Utils में डाला गया backdoor खोजा
  • malicious code xz Utils 5.6.0 और 5.6.1 में शामिल था, और इसे इस तरह design किया गया था कि किसी खास private key वाला attacker SSH login certificate में code छिपाकर backdoor वाले device पर उसे चला सके
  • attacker ने GitHub source के बजाय release tarball, test files, build scripts, और glibc IFUNC का इस्तेमाल करके liblzma के ज़रिए sshd authentication routine को hook करने की कोशिश की
  • backdoor ने amd64/x86_64, glibc, Debian या Red Hat-family package build conditions की जांच की, और यह Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed/MicroOS, तथा Kali Linux की कुछ अवधि वाली releases में शामिल हुआ
  • Jia Tan नाम की developer persona ने कई वर्षों तक xz Utils maintenance में हिस्सा लिया, यह घटना CVE-2024-3094 के रूप में track की जा रही है, और Binarly check page व xzbot जैसे detection/analysis tools सामने आए

खोज और प्रभाव का दायरा

  • Andres Freund Microsoft में PostgreSQL से जुड़े काम करने वाले developer और engineer हैं; Debian system पर SSH login में CPU का असामान्य रूप से अधिक उपयोग और valgrind errors की जांच करते समय उन्हें गड़बड़ी के संकेत मिले
  • कारण xz Utils update था, और Freund ने Open Source Security List पर सार्वजनिक किया कि यह update compression software में जानबूझकर डाला गया backdoor है
  • xz Utils Linux सहित लगभग सभी Unix-जैसे operating systems में lossless data compression और decompression देता है, और legacy .lzma format को भी support करता है
  • Filippo Valsorda ने इसे “publicly described supply chain attacks में शायद सबसे बेहतर तरीके से execute किया गया मामला, और व्यापक रूप से इस्तेमाल होने वाली library के malicious, capable और privileged upstream वाला nightmare scenario” बताया

backdoor ने जिस behavior को target किया

  • malicious code xz Utils 5.6.0 और 5.6.1 में जोड़ा गया, जिससे software के काम करने का तरीका बदल गया
  • backdoor remote SSH connections के लिए इस्तेमाल होने वाली executable file sshd से छेड़छाड़ करता है
  • पहले से तय cryptographic key रखने वाला व्यक्ति SSH login certificate में मनचाहा code छिपा सकता है, उसे upload कर सकता है, और फिर backdoor वाले device पर चला सकता है
  • वास्तव में upload किया गया code confirm नहीं हुआ, इसलिए यह पता नहीं कि attacker कौन-सा code चलाना चाहता था
  • सैद्धांतिक रूप से cryptographic keys की चोरी या malware install करने सहित लगभग कोई भी काम संभव हो सकता था

compression library के SSH तक पहुंचने का रास्ता

  • कोई library अपने साथ linked executable file के internal behavior में छेड़छाड़ कर सकती है
  • OpenSSH का प्रमुख sshd implementation default रूप से liblzma से link नहीं होता
  • Debian और कई Linux distributions sshd को systemd से जोड़ने वाला patch जोड़ते हैं
    • systemd boot के दौरान कई services load करने वाला program है
    • systemd liblzma से linked है
    • इसी connection path के कारण xz Utils sshd को प्रभावित कर सका

कई वर्षों की तैयारी के संकेत

  • 2021 में JiaT75 नाम के user ने open source project में अपना पहला ज्ञात commit किया
    • libarchive project में safe_fprint function को एक ऐसे variant से बदलने वाला बदलाव था जिसे लंबे समय से कम सुरक्षित माना जाता था, और उस समय किसी ने ध्यान नहीं दिया
  • 2022 में JiaT75 ने xz Utils mailing list पर patch submit किया
    • जल्द ही Jigar Kumar नाम के नए participant ने Lasse Collin पर दबाव डाला कि वे xz Utils को पर्याप्त बार या तेजी से update नहीं कर रहे हैं
    • Dennis Ens और अन्य नए participants ने भी Collin पर अतिरिक्त maintainer जोड़ने का दबाव डाला
  • जनवरी 2023 में JiaT75 ने xz Utils में पहला commit किया, और Jia Tan नाम से xz Utils के काम में अधिक गहराई से शामिल हुआ
    • oss-fuzz में Collin contact को अपने contact से बदल दिया
    • oss-fuzz tests के दौरान IFUNC feature को disable करने का अनुरोध किया, ताकि बाद में xz Utils में आने वाले malicious changes detect न हो सकें
  • फरवरी 2024 में Tan ने xz Utils 5.6.0 और 5.6.1 commits किए, और इन्हीं updates ने backdoor implement किया
  • इसके बाद Tan या अन्य लोगों ने Ubuntu, Red Hat और Debian developers से उन updates को operating systems में merge करने का अनुरोध किया

शामिल distributions और execution conditions

  • Tenable के अनुसार backdoor version या संबंधित updates निम्न releases में गए
    • Fedora Rawhide: Fedora Linux का development distribution
    • Fedora 41
    • Debian testing, unstable, experimental: 5.5.1alpha-0.1 से 5.6.1-1 तक
    • openSUSE Tumbleweed और openSUSE MicroOS: 7 मार्च से 28 मार्च के बीच backdoored xz version शामिल
    • Kali Linux: 26 मार्च से 28 मार्च के बीच xz-utils 5.6.0-0.2 शामिल
  • Sam James के analysis के अनुसार malicious script यह जांचता है कि build target amd64/x86_64 है या नहीं, linux-gnu नाम इस्तेमाल करता है या नहीं, और GCC व GNU ld इस्तेमाल करता है या नहीं
  • यह भी check करता है कि build Debian package build है या RPM_ARCH x86_64 है
  • attack ऐसा लगता है कि amd64 systems पर glibc इस्तेमाल करने और Debian या Red Hat-derived distribution build करने वाले environments को target कर रहा था
  • अन्य systems vulnerable थे या नहीं, उस समय ज्ञात नहीं था

implementation method और छिपाने की techniques

  • Sam James ने बताया कि backdoor कई components से बना था
    • upstream द्वारा distribute किया गया release tarball GitHub के code जैसा नहीं था
    • release tarball का build-to-host.m4 GitHub upstream वाले से काफी अलग था
    • git repository के tests/ folder में manipulated test files हैं
      • tests/files/bad-3-corrupt_lzma2.xz
      • tests/files/good-large_compressed.lzma
    • build-to-host.m4 द्वारा call की गई script malicious test data को unpack करती है और build process को modify करती है
    • glibc का IFUNC OpenSSH authentication routine को runtime पर hook या redirect करने के लिए इस्तेमाल हुआ
  • HD Moore ने confirm किया कि final backdoor stage केवल तब execute होता है जब amd64 पर library build की जाती है और Debian या RPM package बनाया जाता है
  • researchers के analysis के अनुसार, SSH public key verification process में जब कोई specific fingerprint function और public key match करते हैं, तो actual public key verification से पहले key content को pre-shared key से decrypt किया जाता है
  • decrypted content अगर किसी specific format से match करता है, तो उसे सीधे system को pass किया जाता है
  • fingerprint match न हो या decrypted content format से match न करे, तो सामान्य key verification पर लौट जाता है, और user के लिए फर्क नोटिस करना मुश्किल होता है

Akamai द्वारा संक्षेपित execution chain

  • Akamai researchers का मानना है कि backdoor xz GitHub repository में नहीं, बल्कि केवल source code tarball release में शामिल किया गया था, ताकि detection से बचा जा सके
  • backdoor कई commits में तैयार हुआ
    • build process में IFUNC का उपयोग करके malicious code को symbol resolution function intercept करने लायक बनाया गया
    • test files के अंदर obfuscated shared object छिपाया गया
    • library build process के दौरान shared object extract करने वाली script execute की गई
    • process privileges सीमित करने वाले security feature landlocking को disable किया गया
  • execution chain कई stages में आगे बढ़ती है
    • build-to-host.m4 library build के दौरान execute होकर bad-3-corrupt_lzma2.xz को bash script में decode करता है
    • यह bash script good-large_compressed.lzma को अधिक जटिल तरीके से decode कर एक और script बनाती है
    • वह script liblzma_la-crc64-fast.o shared object extract करती है और इसे liblzma compilation process में जोड़ती है
  • यह shared object liblzma में compile होकर सामान्य function name resolution process की जगह लेता है
  • malicious library OpenSSH के RSA_public_decrypt function pointer को अपने बनाए malicious function से बदल सकती है
  • Filippo Valsorda के analysis के अनुसार यह malicious function authentication client के certificate से command निकालता है, threat actor होने की पुष्टि करता है, और फिर उसे system() को pass करके authentication से पहले remote code execution हासिल करता है

Jia Tan और बाकी सवाल

  • Jia Tan के बारे में बहुत कम जानकारी उपलब्ध है
  • इस developer persona ने पिछले कुछ वर्षों में दर्जनों अन्य open source software में भी हिस्सा लिया
  • Jia Tan user name के पीछे कोई वास्तविक व्यक्ति था या वह पूरी तरह fabricated persona थी, यह ज्ञात नहीं है
  • अतिरिक्त technical analysis Filippo Valsorda के Bluesky thread, Kevin Beaumont के analysis, और Freund के Friday disclosure material में देखा जा सकता है

CVE और checking tools

  • इस vulnerability का tracking identifier CVE-2024-3094 है
  • Binarly का xz.fail page IFUNC implementation detect करता है और behavioral analysis पर आधारित है
    • इसी तरह का backdoor कहीं और डाले जाने पर भी invariant conditions को automatically detect किया जा सकता है
  • xzbot analysis और experimental features प्रदान करता है
    • honeypot: exploit attempts detect करने के लिए fake vulnerable server
    • ed448 patch: अपनी ED448 public key इस्तेमाल करने के लिए liblzma.so patch
    • backdoor format: backdoor payload format
    • backdoor demo: ED448 private key पता होने की assumption पर RCE trigger करने वाला CLI

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

1 टिप्पणियां

 
GN⁺ 2024-04-02
Hacker News की टिप्पणियाँ

  • लक्ष्य standardized test framework का उपयोग करके XZ के लिए tests लिखना आसान बनाना था
    Jia ने 2022-06-17 को लिखा था कि अभी कई features test नहीं हुए हैं, इसलिए लंबे समय में project stability के लिए tests बढ़ाने में यह मदद करेगा
    यानी यह बदलाव काफी पहले से तैयार किया जा रहा था

  • lib को RSA_public_decrypt में दखल देने की अनुमति देने वाले linking mechanism पर शायद ज्यादा चर्चा नहीं हुई
    process separation जैसी बातों पर काफी चर्चा है, लेकिन उस function call redirection पर कम बात हुई है
    SSH में आने वाले code जैसे core components को libraries के साथ layered trust तरीके से link करके, क्या “जिस जगह से मैं call कर रहा हूँ वहाँ trust करता हूँ, लेकिन दूसरे call points में अपने-आप घुसने की अनुमति नहीं देता” जैसा model बनाया जा सकता है?
    यह सुनकर “security by obscurity” जैसी reflex प्रतिक्रिया आ सकती है कि bypass के तरीके हैं इसलिए इसका कोई मतलब नहीं, फिर भी इसे attack surface reduction माना जा सकता है

    • Erlang actors जैसा model भी काम कर सकता है, जहाँ program subcomponents अपने-अपने security context के साथ message passing के जरिए एक-दूसरे को call करते हैं
      हालांकि operating system में कई security contexts overlap करते हैं। XZ backdoor के संदर्भ में यह मुख्यतः module-level capability-based security है, लेकिन program-level capability, memory-level isolation (paging), microarchitecture-level isolation आदि भी हैं
      इन elements को साथ में काम कराते हुए performance भी निकालना काफी कठिन है, और Unix परिवार का ऐसे model की ओर जाना लगभग असंभव लगता है क्योंकि इसके लिए process की अवधारणा को ही replace करना पड़ेगा
    • मेरी नजर में समस्या glibc के IFUNC के उपयोग में है
      इसी ने XZ tests तोड़े, फिर अचानक ऐसे accounts सामने आए जो उन tests को disable करने के लिए lobby कर रहे थे, और परिणामस्वरूप exploit संभव हुआ
    • मूल रूप से यह code build time (./configure && make चलाते समय) पर C file को चुपके से modify करके ifunc resolver को patch करता है और दिए गए malicious object को call करवाता है
      compromised object file को now linker flag के साथ link किया जाता है, जिससे library load time पर ifunc तुरंत resolve होता है, और उस समय process link table अभी writable state में होती है, इसलिए patched resolver call हो जाता है
      यही हिस्सा अहम है, क्योंकि library load होते समय memory में मौजूद RSA_public_decrypt function को सीधे intercept किया जा सकता था
      backdoor injection process का बहुत अच्छा analysis: https://research.swtch.com/xz-script
    • systemd ने हाल ही में compression libraries के लिए dlopen इस्तेमाल करने वाला बदलाव merge किया है: https://github.com/systemd/systemd/pull/31550
      उस अर्थ में यह ज्यादा सुरक्षित linking method है
    • सोच रहा हूँ कि ltrace जिस तरह call किए जाने वाले symbols को monitor करता है, क्या वह पर्याप्त होगा

  • समझ नहीं आता कि “लगभग” पूरी दुनिया को संक्रमित करने वाला क्यों कहा जा रहा है
    कम-से-कम तीन काफी लोकप्रिय Linux distributions, Arch, Gentoo, openSUSE Tumbleweed, ने कुछ हफ्तों तक backdoor distribute किया, और Tumbleweed पर यह निश्चित रूप से काम कर रहा था
    कुछ हफ्तों तक SSH में backdoor था, इसलिए “लगभग” कहना कमजोर लगता है

    • उन distributions में exploit वास्तव में execute नहीं हुआ था
      यह सिर्फ deb/rpm targets पर काम करता था, इसलिए व्यवहार में production तक पहुँचने से पहले ही रुक गया
    • Arch और Gentoo hobby distributions के रूप में काफी लोकप्रिय हैं, लेकिन इस हमले के निशाने पर रहे SSH servers जैसे professional operating environments में वे कहीं कम आम हैं
      इसका मतलब यह नहीं कि सब ठीक है; अगर यह इतना लंबे समय तक अनदेखा रहता कि RHEL या Debian/Ubuntu stable में पहुँच जाता, तो banks या healthcare institutions जैसी जगहों से notifications मिलते
      authentication से पहले remote code execution होने पर, जब तक network बहुत कड़ा सीमित न हो और flow logging अच्छी न हो, “हम प्रभावित नहीं हुए” कहना मुश्किल होता
    • लगता है कि Arch binary package में यह वास्तव में शामिल नहीं था, क्योंकि backdoor build system ने खुद Arch के लिए backdoor नहीं डाला था
      xz-5.6.1-1 और xz-5.6.1-2 के liblzma.so.5.6.1 को cmp -l से compare करने पर बहुत छोटा अंतर ही दिखता है
      advisory लिखने से पहले शायद यह पता नहीं था
      https://github.com/QubesOS/qubes-issues/issues/9067#issuecom...
    • sshd चलाने वाली अधिकांश Linux machines शायद rolling release नहीं, बल्कि LTS distributions इस्तेमाल करती होंगी
      हालांकि इसे support करने वाला data कैसे मिलेगा, यह नहीं पता
    • उम्मीद है open source maintainers और बड़ी companies message समझेंगी। open source maintenance की financial prospects बदलनी होंगी

  • मैं 101 dollars की शर्त लगाऊँगा कि अगले 12 महीनों में production-like real environment में कुछ ऐसा ही मिल जाएगा
    क्योंकि maintainers एक-दूसरे के पुराने commits को शक की नजर से देखना शुरू करेंगे

    • मुझे लगता है कि पिछले 10 वर्षों में ऐसे attacks बढ़े हैं
      बस ऐसे codebases देखने होंगे जो critical हैं लेकिन ज्यादा प्रसिद्ध नहीं, और जिनके maintainers बहुत कम हैं
    • सोच रहा हूँ कि क्या ऐसे cases मिल पाएँगे जो पहले से चल रहे थे और इस्तेमाल किए गए थे
      अगर मेरे पास ऐसा कुछ होता और वह अच्छी तरह काम करता, तो शायद बाद में किसी दूसरे account से “discover” करके उसे fix करवाता

  • इस घटना से मेरे कई निजी निष्कर्ष निकले हैं
    पहला, source repository से अलग code रखने वाले source distribution tarball अच्छे नहीं हैं, और हमें उनसे दूर जाना चाहिए। एक और बड़े supply chain attack, event-stream, ने भी ऐसी ही बात का फायदा उठाया था
    नतीजतन, auto-generated artifacts को हमेशा commit किया जाना चाहिए
    दूसरा, code review में जिन auto-generated artifacts को हर कोई Page Down दबाकर पार कर देता है, वे समस्या हैं। अगर ऐसी files repository में हैं, तो यह जांचने के लिए automated tests भी होने चाहिए कि किसी ने उनसे छेड़छाड़ तो नहीं की, और यह भी कि पुराने auto-generated files यूं ही पड़े न रहें
    तीसरा, 1 और 2 के परिणामस्वरूप autotools खराब है और autotools culture भी खराब है
    चौथा, Libsystemd ecosystem के लिए समस्या है। यह कहने पर आपको systemd से नफरत करने वाला मान लिया जाता है, लेकिन यह बड़ा, जटिल और बहुत dependencies वाला है, जबकि ज्यादातर programs इसका बहुत छोटा हिस्सा ही इस्तेमाल करते हैं। सिर्फ initialization notification के लिए हर service को इस पर depend करने के लिए प्रोत्साहित करना पागलपन है
    पांचवां, यह culture है कि code reuse हमेशा अच्छा होता है और छोटी-सी functionality के लिए भी बड़ी library पर depend करना ठीक है, लेकिन यह सच नहीं है। Dependencies maintenance burden और security risk हैं, और इन्हें मिली हुई functionality के मुकाबले तौलना चाहिए
    छठा, distribution maintainers द्वारा packages पर बड़े patches लगाना भी समस्या है। इससे libraries और applications के widely used de facto forks बन जाते हैं, जिन्हें असली maintainers नहीं देखते
    सातवां, developer के नजरिए से OSS को financially sustainable बनना होगा। Liblzma और xz-utils की करोड़ों installations रही होंगी, लेकिन वे mental health issues से जूझ रहे एक ही maintainer पर निर्भर थे
    आठवां, यह कहना अच्छा नहीं लगता, लेकिन अब code review और maintainership transfer में geopolitical considerations भी करने होंगे

    • Geopolitical considerations मददगार नहीं हैं
      इस बात का कोई सबूत नहीं कि Jia Tan असली नाम है, और यहां तक कि वह कोई वास्तविक व्यक्ति भी है, इसका भी कोई सबूत नहीं
      अगर projects Asian-origin जैसा सुनाई देने वाले नामों से contributions लेना बंद कर दें, तो अगला attacker बस Richard Jones नाम इस्तेमाल कर लेगा
    • Libsystemd के बारे में पूरी तरह सहमत हूं
      BSD दुनिया से आने पर systemd चौंकाने वाला लगता है, राक्षसी है और हर तरफ अपने tentacles फैलाए हुए है
    • मेरी कुछ अतिरिक्त निजी observations हैं
      Consumers भी भोले हैं, लेकिन software industry खुद भी security threats को लेकर भोली है
      Social exploits, code exploits का हिस्सा हैं
      FOSS का “जितनी ज्यादा आंखें code देखें उतना अच्छा” वाला सिद्धांत सही है, लेकिन यह तभी काम करता है जब वे आंखें trained हों। FOSS को industry की material support की जरूरत है
      MSFT engineer ने यह exploit पकड़ा, फिर भी यह Fedora 41, openSUSE, Kali के regular public releases में पहुंच गया था
      Development toolchain और testing process कभी security test करने के लिए design ही नहीं किए गए। SolarWinds भी देखने लायक है: https://www.wired.com/story/the-untold-story-of-solarwinds-t...
    • tarball distribution बंद करने की बात यह पूरी तरह नजरअंदाज करती है कि release artifacts होते क्यों हैं
      Release artifacts में सिर्फ autoconf scripts ही नहीं होते
      Binary blobs को release archive में डालने के कई कारण होते हैं। Game resources, firmware images, test cases वगैरह। यह भी बात थी कि mpv proprietary encoder से बनाए गए कुछ media files को test cases के रूप में शामिल करता है, और यह बुरी नहीं बल्कि अच्छी बात है
      अच्छी तरह maintained sqlite हर जगह इस्तेमाल होती है और उसका बेहतरीन test suite भी है। हर release में वह एक नहीं, बल्कि compilation के अलग-अलग stages के हिसाब से दो tarballs distribute करती है। इसे बंद करना आसान होगा, लेकिन इससे package maintainers का काम ही बढ़ेगा और security में सुधार नहीं होगा
      Debian curated tarball से build इसलिए करता है क्योंकि उसे इंसान curate करता है और well-known key से sign करता है। बेशक git से भी build किया जा सकता है, लेकिन उससे स्थिति सुधरेगी या नहीं, यह स्पष्ट नहीं। सभी projects release tags sign नहीं करते, और अगर करते भी हैं, तो ज्यादा संभावना है कि वह automated हो
      हम चाहते हैं कि changes की review पहले upstream maintainer करे, फिर package maintainer, और बेहतर है कि ये दोनों पक्ष एक-दूसरे से unrelated हों
      इस बार corrupted upstream maintainer ने उस process पर attack किया, लेकिन इसका मतलब यह नहीं कि upstream maintainers को ही हटा देना चाहिए। पिछले कुछ वर्षों में इसी structure ने कई backdoor attempts रोके हैं, और यह ऐसा process नहीं है जिसे सावधानीपूर्वक review के बिना फेंक दिया जाए
      सुधार की दिशा वही है जो हम लगातार कहते आए हैं। Reproducible builds को और आगे बढ़ाना, जहां संभव हो attack surface और build complexity घटाना, और maintainers पर भरोसा करना लेकिन उनके काम को verify करना
    • systemd maintainers ने कभी सभी services को libsystemd पर depend करने के लिए प्रोत्साहित नहीं किया
      उलटे वे इसी बिंदु पर उलझन में हैं, और libsystemd के बिना simple datagram implement करने के तरीके पर documentation जोड़ रहे हैं
      liblzma और xz-utils की installation count करोड़ों से कहीं ज्यादा होगी। Python, PHP, Ruby जैसी कई languages libxml2 पर depend करती हैं, और libxml2 liblzma इस्तेमाल करता है। और भी बहुत dependencies हैं
      Geopolitical considerations maintainer का काम नहीं हैं। OSS बिना warranty के दिया जाता है
      इसके अलावा “Jia Tan” शायद पूरी तरह fake था। Commit timestamps देखें तो उसी दिन timezone Eastern Europe से Asia में बदलता है। कम से कम इतना साफ है कि कोई identity game खेल रहा था

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

    • अब मुझे लगता है कि लोगों को Valgrind anomalies सभी देखनी चाहिए
      क्योंकि यह issue इसी तरह मिला था
      उसके बाद problematic library को देखकर, project पर कब्जा करने वाले fake persona जैसे similar outliers खोजने चाहिए
      ऐसे errors को ignore करना आम practice जैसा दिखता है
    • वह Microsoft द्वारा hired PostgreSQL PGDG engineer है
      इस तरह की packaging मैं सच में बर्दाश्त नहीं कर सकता

  • लगता है xz के मूल maintainer ने Jia Tan को ज़िम्मेदारी सौंप दी, बिना उसे व्यक्तिगत रूप से देखे या कम-से-कम उससे कॉल पर बात किए
    सोचता हूँ कि क्या सिर्फ़ email या GitHub के ज़रिए संवाद करना आम बात है
    इस घटना के बाद कुछ open source project maintainers शायद ज़्यादा सावधान हो जाएँगे

    • सिर्फ़ email/GitHub से संवाद करना पूरी तरह आम है
      मैंने भी कई बार यह जाने बिना कि असली व्यक्ति कौन है, सिर्फ़ text के ज़रिए बात करके libraries की maintenance ली या सौंपी है
      लेकिन इस मामले से “maintainers को ज़्यादा सावधान होना चाहिए” वाला निष्कर्ष मुझे बिल्कुल गलत लगता है
      लोग अपने project में क्या खींचकर लाते हैं, इसकी ज़िम्मेदारी maintainer की नहीं बल्कि उस project पर काम करने वालों की होती है
      या तो आप maintainer पर भरोसा करते हैं, या नहीं करते; और जैसे ही आप किसी library पर निर्भर होना शुरू करते हैं, आप मौन रूप से यह मान लेते हैं कि आप किस पर भरोसा कर रहे हैं, इसे लगातार update करते रहेंगे
    • अभी की संरचना असल में ऐसी ही है
      लाखों कंपनियाँ unpaid open source developers के काम पर free ride कर रही हैं
      इसलिए उनका छोड़कर चले जाना और समस्याएँ पैदा होना हैरानी की बात नहीं है
    • समझ नहीं आता कि phone call से क्या फ़र्क पड़ता
      उससे उस व्यक्ति के इरादों पर कौन-सा अतिरिक्त भरोसा मिल जाता?
    • सिर्फ़ email/GitHub से संवाद करना सही है
      मैंने GitHub पर 100 stars से लेकर 30,000 stars तक के अलग-अलग आकार के लगभग छह open source projects में योगदान दिया है, लेकिन किसी से भी call पर बात नहीं की और text-based communication ही standard था
    • जब कई लोग काम की गति को लेकर दबाव बनाते हैं, तो maintainer को यह महसूस होना कि वही समस्या है और उस समय जिसे वह सबसे अच्छा समझता है उसे project सौंप देना अजीब नहीं है
      लेकिन किसी को व्यक्तिगत रूप से जानने से भी समस्या ज़रूरी नहीं कि हल हो जाए
      बहुत पहले मैंने anonymously एक open source project पर काम किया था, जिसका नाम यहाँ नहीं बताना चाहता। lead programmer के पास एक co-maintainer था, जिसे वह काफ़ी अच्छी तरह जानता हुआ दिखता था
      वह co-maintainer मुझे और बाद के दूसरे maintainers को लगातार gaslight करता, नीचा दिखाता और बहुत छोटे bugs के लिए दोष देकर project छोड़ने पर मजबूर करता था। अपमान हटा दें तो वह शिक्षाप्रद Linus Torvalds-शैली की डाँट जैसा भी नहीं था
      lead maintainer उसके दावों के तकनीकी मूल से सहमत था, इसलिए उसने उसे बढ़ावा दिया
      कुछ साल बाद उस co-maintainer ने project को hostile takeover करने की कोशिश की, और चीज़ें उसकी उम्मीद के मुताबिक़ नहीं चलीं। थोड़े समय बाद कई private correspondences सार्वजनिक हुईं, जिनसे पता चला कि वह हमेशा से यही चाहता था और दूसरे maintainers को gaslight करना भी उसी लक्ष्य का हिस्सा था
      दोनों लोग एक-दूसरे को जानते थे, फिर भी ऐसा हुआ

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

    • संभावना है
      हफ्ते की शुरुआत में मैंने कुछ SSH traffic देखा था, लेकिन उस समय इस पर ज़्यादा ध्यान नहीं दिया
      बेशक यह गलत सुराग भी हो सकता है: https://www.nubi-network.com/news.php?id=21

  • “Lasse Collin ने xz Utils को पर्याप्त बार या पर्याप्त तेज़ी से update नहीं किया” वाला meme एक गलती थी

  • समझ नहीं आता कि SSH xz का इस्तेमाल क्यों करता है
    क्या उसे करना चाहिए? क्या यह सच में इतना ज़रूरी है?

    • OpenSSH xz का इस्तेमाल नहीं करता
      OpenSSH ने startup notification देने के लिए libsystemd को खींचा, और libsystemd ने liblzma को खींचा। आम तौर पर liblzma का code OpenSSH के अंदर नहीं जाता
      लेकिन क्योंकि यह libsystemd की dependency के रूप में build होता है, build script libsystemd और OpenSSH जैसे environment में चलती है
      attack payload liblzma test directory में compressed test case की तरह छिपाए गए obfuscated binary blob के रूप में रखा गया था
      git source से lzma compile करने और autotools से build scripts generate करने पर कुछ भी संदिग्ध नहीं था। लेकिन distribution packagers द्वारा इस्तेमाल किए जाने वाले source tarball में autotools पहले ही चलाया जा चुका था, और attacker ने auto-generated, पढ़ने में मुश्किल script output को बदल दिया था
      वह script जांचती थी कि liblzma OpenSSH जैसे environment में compile हो रहा है या नहीं, और क्या वह .deb या .rpm package में जाने के लिए compile हो रहा है; अगर दोनों सही होते, तो attack payload को OpenSSH में implant कर देती
      इसके बाद payload कई checks करता था—जैसे OpenSSH init script से सामान्य रूप से शुरू हुआ है या manually चलाया गया है, सामान्य debugging tools मौजूद हैं या नहीं—और केवल तब running process से attach होता था जब वह debugging tools के बिना “natural” boot जैसा दिखता था
      चलते समय वह private key verification में hook लगाता था, और अगर सही private key login की कोशिश करती, तो incoming packet के बाकी हिस्से को system से call करके root privileges वाली remote code execution देता था
    • OpenSSH xz का इस्तेमाल नहीं करता, लेकिन कुछ distributions में systemd के साथ integrate करते समय xz इस्तेमाल होता है