xz/liblzma की upstream stream में मौजूद बैकडोर के कारण SSH सर्वर compromise

• Debian sid इंस्टॉलेशन में liblzma (xz पैकेज का हिस्सा) से जुड़े कुछ असामान्य लक्षण देखे गए, जैसे SSH लॉगिन के समय CPU उपयोग बढ़ना और valgrind त्रुटियां।
• समस्या की जड़ यह पाई गई कि xz का upstream repository और tarball बैकडोर से संक्रमित थे। बैकडोर का कुछ हिस्सा केवल वितरित tarball में मौजूद है।
• tarball में शामिल स्क्रिप्ट configure के अंत में चलती है और यदि कुछ विशेष शर्तें पूरी हों, तो $builddir/src/liblzma/Makefile को संशोधित करके malicious code inject करती है.

repository के भीतर का बैकडोर

• बैकडोर का मुख्य हिस्सा repository के tests/files directory में encrypted रूप में मौजूद है।
• ये फाइलें 5.6.0 version के tests में उपयोग नहीं हुई थीं, और 5.6.1 version में बैकडोर से पैदा हुई valgrind errors और crashes को ठीक करने का प्रयास किया गया था।

प्रभावित सिस्टम

• बैकडोर स्क्रिप्ट configure के बाद पहली बार कॉल होती है और केवल कुछ विशेष शर्तों (जैसे x86-64 Linux system, gcc और gnu linker का उपयोग, Debian या RPM package build के दौरान) में build process को संशोधित करती है।

openssh server पर प्रभाव

• बैकडोर-इंस्टॉल्ड liblzma का उपयोग करने पर SSH के जरिए लॉगिन धीमा हो जाता है।
• openssh सीधे liblzma का उपयोग नहीं करता, लेकिन Debian सहित कुछ distributions systemd notification support के लिए openssh पर patch लगाते हैं, और libsystemd, lzma पर निर्भर करता है।

inject किए गए code का विश्लेषण

• यह विश्लेषण किसी security researcher या reverse engineering expert के बजाय एक पर्यवेक्षक के दृष्टिकोण से किया गया है।
• बैकडोर ifunc resolver के जरिए execution को intercept करता है, और sshd के initialization के दौरान symbols resolve करके RSA_public_decrypt symbol को अपने code में बदल देता है।

sshd पर प्रभाव

• RSA_public_decrypt@....plt को बैकडोर code की ओर मोड़ दिया जाता है, जिससे public key login के दौरान बैकडोर code कॉल होता है।
• इससे authentication bypass या remote code execution संभव होने का अनुमान है।

bug report

• upstream repository की संलिप्तता पर संदेह होने के कारण bug report दर्ज नहीं की गई।
• Red Hat ने इस समस्या को CVE-2024-3094 आवंटित किया है।

vulnerable installation का पता लगाना

• सिस्टम के ssh binary के vulnerable होने का पता लगाने के लिए एक script उपलब्ध कराई गई है।

[depth221]

xz बैकडोर के बारे में मुझे जो कुछ भी पता है
यह उस पोस्ट का लेख है जिसे इस बैकडोर की खोज करने वाले Andres Freund ने लिखा है।

[edunga1]

यह वाकई हैरान करने वाली बात है कि यह सब कितनी योजनाबद्ध तरीके से किया गया; पूरी प्रक्रिया किसी ड्रामा जैसी लगती है।

[carnoxen]

इसे टुकड़े-टुकड़े कर देना भी कम है

[roxie]

क्यों?

[keepworking]

क्योंकि यह open source में जानबूझकर backdoor डालने की हरकत थी... और उस प्रक्रिया में चोरी-छिपे जनमत को प्रभावित करने जैसी हरकतें भी की गई थीं
पहले भी Linux kernel में दुर्भावनापूर्ण तरीके से vulnerability डालने के मामले रहे हैं, इसलिए यह काफ़ी कड़वा लगता है

[roxie]

आह, अब लगता है कि मैं उसका nuance समझ गया हूँ, धन्यवाद

[GN⁺]

Hacker News की राय

• संबंधित लिंक:

  • Xz: Disable ifunc to fix Issue 60259
  • FAQ on the xz-utils backdoor
  • Everything I Know About the XZ Backdoor

• सारांश:

  • बैकडोर लेखक ने Fedora 40 और 41 में xz 5.6.x जोड़ने के लिए कई हफ्तों तक संवाद किया। इस बैकडोर से पैदा हुई valgrind समस्या को ठीक करने के लिए उसने सहयोग भी किया, लेकिन बाद में पता चला कि समस्या की जड़ वही बैकडोर था। embargo गलती से टूट जाने के बाद इस समस्या को तत्काल सुलझाना पड़ा।
  • बैकडोर लेखकों में से एक ने oss-fuzz में बैकडोर पर निर्भर फीचर को सीधे disable कर दिया, ताकि उसका संयोगवश पता न चल सके।
  • बैकडोर लेखक ने xz-java प्रोजेक्ट में SECURITY.md फ़ाइल जोड़ी। इसमें निर्देश था कि अगर कोई security vulnerability मिले तो उसे सार्वजनिक न करें, बल्कि निजी तौर पर रिपोर्ट करें। दूसरे नज़रिए से देखें तो इसे इस तरह भी समझा जा सकता है कि लेखक अपने exploit को fine-tune करने और target का फायदा उठाने के लिए समय खरीदना चाहता था।
  • openssh सीधे liblzma का उपयोग नहीं करता, लेकिन debian और कई अन्य distributions ने systemd notification support के लिए openssh पर patch लगाए। इसके कारण libsystemd, liblzma पर निर्भर हो गया, जिससे openssh जैसे security-critical daemon में अतिरिक्त dependency जुड़ गई और supply chain attack का जोखिम बढ़ गया।
  • घबराए हुए लोगों के लिए मुख्य जाँच बिंदु:
    • अगर आप liblzma5 का हालिया version (5.6.0 या 5.6.1) उपयोग कर रहे हैं। यह पिछले लगभग एक महीने में जोड़ा गया था।
    • अगर आप debian या RPM-आधारित Linux distribution उपयोग कर रहे हैं। यह reverse engineering को कठिन बनाने की कोशिश जैसा दिखता है।
    • अगर आप systemd में OpenSSH sshd चला रहे हैं। कुछ distributions में patch किया गया OpenSSH logging functionality के लिए libsystemd का उपयोग करता है, जो vulnerable liblzma5 को साथ खींच लाता है।
    • Debian testing में पहले से ही '5.6.1+really5.4.5-1' version मौजूद है, जो वास्तव में पुराने 5.4 version को नए version के रूप में दोबारा पैक करता है।
  • अगर GNU autoconf में कुछ संदिग्ध छिपाना हो, तो उसे "curl | sh" script में नहीं बल्कि वहीं छिपाया जाएगा। इस घटना का वितरक पहले भी releases संभाल चुका था और 2022 से commits कर रहा था। उसके कई commits में वास्तविक बदलाव शामिल थे, और libarchive जैसे संबंधित projects में भी उसके commits थे। बैकडोर डालने के लिए बहुत मेहनत की गई।
  • कुछ साल पहले Go library लिखी गई थी जो xz C code को wrap करती है ताकि Go से xz compression किया जा सके। लगभग एक हफ्ते पहले उस repository में 5.6.1 पर upgrade करने के लिए पहला PR आया। यह upstream GitHub account से अलग account था।
  • एक contributor, जो security researcher या reverse engineer नहीं है, तकनीकी लेख लिखना पसंद करता है। उसकी खोजों का सार बताने वाली रिपोर्ट को मुख्यधारा debugging दुनिया के बाहर के उन contributors के लिए एक शानदार template माना गया, जो चीज़ें साझा करने में हिचकते हैं।
  • अगर xz(1) के लिए इससे अधिक कुशल बैकडोर प्रयास की कल्पना करें, तो शायद वह इतनी जल्दी पकड़ा नहीं जाता। xz लगभग हर जगह इस्तेमाल होता है। ऐसा xz बनाया जा सकता है जो .tar.xz software tarballs जैसे files के केवल छोटे हिस्सों को चुनिंदा रूप से बदल दे, जिन्हें खास build process की नींव के रूप में इस्तेमाल किया जाता है। निशाना source code tarball नहीं, बल्कि वे tarballs होंगे जो precompiled binaries वितरित करते हैं।