NixOS और reproducible builds से पता चला xz backdoor

 (luj.fr)
1 पॉइंट द्वारा GN⁺ 2025-03-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मार्च 2024 में Linux distributions में source tarball को decompress करने के लिए इस्तेमाल होने वाले xz software में एक backdoor मिला।
  • यह backdoor malicious maintainer Jia Tan द्वारा 3 साल तक चुपचाप डाला गया था।
  • इस घटना का असर बहुत बड़ा था क्योंकि यह remote code execution संभव बनाती थी, और इसे ढूंढना बेहद मुश्किल था।
  • Microsoft के Postgres developer Andres Freund ने performance degradation की जांच करते समय इसे संयोग से खोज लिया, जिससे एक बड़ी आपदा टल गई।

हमला कैसे काम करता है

  • backdoor ssh program को hijack करके remote code execution संभव बनाता है।
  • RSA_public_decrypt function को modify करके, खास RSA key से login करने पर attacker arbitrary commands चला सकता था।
  • यह दो मुख्य components से बना था:
    1. एक script जो xz build process के हिस्से के रूप में malicious object file install करती थी।
    2. RSA_public_decrypt function को hook करने की प्रक्रिया।

1. malicious object file install script

  • malicious object file, xz git repository की test files में छिपी हुई थी।
  • backdoor केवल maintainer द्वारा दिए गए release tarball में ही सक्रिय होता था।

2. RSA_public_decrypt function hooking प्रक्रिया

  • dynamic loading time पर चलने वाले code को force execute करने के लिए glibc के ifunc feature का उपयोग किया गया।
  • जब ssh चलता है, तब libsystemd और liblzma load होते हैं, और इसी प्रक्रिया में backdoor arbitrary code execute करता है।

xz आपदा से बचने के तरीके

  • open source software की reliability बढ़ाने के लिए social और technical, दोनों तरह की समस्याओं से निपटना होगा।
  • software supply chain security process को बेहतर बनाना होगा।

भरोसेमंद source से software build करना

  • हमला इसलिए प्रभावी रहा क्योंकि कई distributions ने maintainer द्वारा दिए गए tarball का उपयोग करके xz build किया था।
  • जहां संभव हो, software को सबसे भरोसेमंद source से build करना चाहिए।

जब स्थिति इसकी अनुमति दे...

  • NixOS functional package management model पर आधारित एक distribution है, और हर package को Nix नाम की functional programming language में व्यक्त किया जाता है।
  • NixOS में GitHub से automatically generated source archives इस्तेमाल करने की संस्कृति है।

अविश्वसनीय release tarball पर भरोसा बनाना

  • NixOS को bootstrap चरण में maintainer द्वारा दिए गए tarball का उपयोग करना पड़ता था।
  • software supply chain security को मजबूत करने के लिए कुछ विशेष सुरक्षा उपाय तैयार करने होंगे।

1. source comparison

  • यह जांचना महत्वपूर्ण है कि distribution में इस्तेमाल होने वाला source tarball, GitHub वाले tarball जैसा ही है या नहीं।
  • हालांकि, कई बार release tarball source से अलग होता है, और यह अपने आप में समस्या नहीं है।

2. bit-for-bit reproducibility का उपयोग

  • reproducible builds software projects की वह विशेषता है जिसमें एक जैसे हालात में दो बार build करने पर एक जैसे artifacts बनते हैं।
  • bit-for-bit reproducibility के जरिए अविश्वसनीय maintainer-provided tarball पर भी भरोसा बनाया जा सकता है।

निष्कर्ष

  • xz backdoor घटना open source software supply chain security के महत्व को फिर से रेखांकित करती है।
  • NixOS जैसे systems reproducible builds के जरिए security को मजबूत कर सकते हैं।

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

1 टिप्पणियां

 
GN⁺ 2025-03-24
Hacker News राय

  • NixOS और reproducible builds xz backdoor का पता नहीं लगा सके। NixOS ने malicious xz build वितरित किया, लेकिन क्योंकि यह NixOS को target नहीं कर रहा था, इसलिए कोई समस्या नहीं हुई

    • जब backdoor का खुलासा हुआ, तो NixOS डेवलपर्स यह देखकर हैरान रह गए कि malicious xz version users तक वितरित हो चुका था
    • सिद्धांत और वास्तविकता अलग हैं, और xz के संभव होने का कारण कोई तकनीकी कमजोरी नहीं बल्कि 'वास्तविक दुनिया' की समस्या थी। यह स्वीकार करना कठिन है कि software से वास्तविक दुनिया को patch नहीं किया जा सकता

  • लगता है लेखक सिर्फ इसी घटना पर ध्यान दे रहा है। Jiatan घटना एक अकेला उदाहरण है, और दूसरे scenarios में भी defense विफल हो सकता है

    • एक NixOS user के रूप में, मुझे लगता है कि बहुत संभव है NixOS इसे पकड़ नहीं पाता। सबूत के बिना NixOS पर भरोसा करना मूर्खता है

  • NixOS का xz backdoor से कोई लेना-देना नहीं था क्योंकि xz backdoor का लक्ष्य RedHat और Debian थे। विडंबना यह है कि backdoor एक Microsoft कर्मचारी द्वारा खोजा गया था

  • लेख में कहा गया है कि distributions को पारंपरिक install tarball के बजाय सीधे VCS (जैसे Github) से source code लेना चाहिए

    • लेकिन एक malicious maintainer सीधे source code repository में binary blob जोड़ सकता है
    • लेखक संकेत देता है कि Github code verify करने के मामले में भरोसेमंद है, लेकिन वास्तव में Github code verify नहीं करता

  • अगर उन घटनाओं पर ध्यान देना है जिन्हें NixOS रोक सकता था, तो CrowdStrike घटना पर ध्यान देना चाहिए। अगर कल के configuration से boot किया जा सकता, तो ज्यादातर समस्याएँ कम की जा सकती थीं

  • NixOS source से सब कुछ compile करता है, इस्तेमाल किए गए source में छेड़छाड़ न हुई हो इसे cryptographically verify करता है, और packages के बीच version dependencies रखता है। Debian में भी reproducible builds हैं

    • समस्या यह थी कि build system ने source से build करने से पहले precompiled object files को नहीं हटाया। अगर कोई source code की जाँच नहीं करता, तो backdoor जोड़ा जा सकता है, और NixOS या कोई दूसरा distribution भी इसे नहीं रोक सकता

  • "कर सकता था" का मतलब है कि यह साबित नहीं हुआ है, जबकि वास्तव में उन्होंने इसे वितरित किया था

  • शानदार explanatory analysis। शीर्षक गलत और भ्रामक है, शायद "technically accurate" है, लेकिन "backdoor वाला" अर्थ निकालने के लिहाज से सबसे अच्छा है

    • यह build manager tools की ज़रूरत और उपयोग पर ज़ोर देता है, और build process में कौन-सी file किस file को प्रभावित करती है इसका causal tracing graph स्पष्ट रूप से बनाना चाहिए, फिर उस graph को enforce करने या पिछले tracing graph से deviations की report करने का तरीका बनाना चाहिए

  • अगर Jia Tan का PR approve हो गया होता, तो malicious artifact उतनी ही आसानी से Github release में जा सकता था जितनी आसानी से tarball में। यह समझना मुश्किल है कि Github release किस तरह security mitigation है

  • यह बात कि release tarball source से अलग है

    • अगर maintainer द्वारा दिया गया tarball मूल source code से ईमानदारी से generate किया गया था, तो यह समझना मुश्किल है कि अलग version आदि कैसे समस्या बनते हैं
    • generated tarball को source code से ही generate किया जा सके, कुछ भी exclude न किया जाए, और git add & commit किया जाए। इस स्थिति में भी commit history की जाँच करनी होगी, और क्योंकि यह देखने में हानिरहित था, यह सवाल बना रहता है कि इसे verify कैसे किया जाए
    • अगर maintained tarball मालिक के source code से generate किया गया हो और Github पर न हो, तो वह समस्या है

  • सिर्फ poisoned test files push करने से बढ़कर भी समस्याएँ थीं, लेकिन यह समझना मुश्किल है कि Nix इसे कैसे रोक सकता था

    • अगर किसी प्रसिद्ध project ने leadership बदली हो, तो commits को ध्यान से देखना चाहिए और यह verify करना चाहिए कि leader कौन है

  • समझ नहीं आ रहा कि मैंने लेख को गलत समझा है या कुछ छूट गया है