ओपन सोर्स प्रोजेक्ट में इंटरैक्शन का एक लघुरूप: xz बैकडोर मुद्दा

 (robmensching.com)
21 पॉइंट द्वारा GN⁺ 2024-03-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • xz/liblzma भेद्यता पर बहुत-से विश्लेषण हैं, लेकिन ज़्यादातर हमले के पहले चरण को छोड़ देने की प्रवृत्ति रखते हैं
    • मूल मेंटेनर बर्नआउट का शिकार हो गया, और सिर्फ़ हमलावर ने मदद की पेशकश की (इस तरह हमलावर को मूल मेंटेनर द्वारा बनाई गई विश्वसनीयता विरासत में मिल गई)।
  • ईमेल थ्रेड आर्काइव में उस समय की स्थिति दर्ज है जब यह चरण 0 हो रहा था

मेंटेनर का बर्नआउट और हमलावर का उभरना

  • मेंटेनर के सामने एक ऐसा अनुरोध रखा गया जो देखने में उचित लगता था

    • "क्या XZ for Java अभी भी मेंटेन किया जा रहा है? मैंने एक हफ्ता पहले सवाल पोस्ट किया था, लेकिन कोई जवाब नहीं मिला।"

  • इस सवाल ने मेंटेनर को अपनी "विफलता" स्वीकार करने पर मजबूर कर दिया
    • वास्तव में मेंटेनर किसी का ऋणी नहीं था और उसने विफलता भी नहीं पाई थी, लेकिन उसे ऐसा महसूस हुआ
    • क्योंकि "कम्युनिटी" को निराश करना बहुत बुरी बात लगती है
  • मेंटेनर ने माना कि वह "पीछे छूट गया है" और मदद माँगने जैसा संकेत दिया
  • लेकिन उस थ्रेड में मदद नहीं आई, बल्कि xz/liblzma हमलावर ने खुद को मदद करने वाले व्यक्ति के रूप में पेश किया

    • "Jia Tan (इस बार का हमलावर) ने मेरी मदद की है... आगे चलकर वह और बड़ी भूमिका निभा सकता है... मेरे संसाधन बहुत सीमित हैं, इसलिए लंबे समय में कुछ बदलना होगा, यह साफ़ है।"

  • मेंटेनर ने कहा कि उसके संसाधन सीमित हैं और लंबे समय में कुछ बदलाव ज़रूरी है

असहयोगी उपभोक्ता का उभरना

  • एक असहयोगी उपभोक्ता ने मेंटेनर के प्रति आलोचनात्मक टिप्पणी की

    • "लगता है नए मेंटेनर आने तक कोई प्रगति नहीं होगी। ... मौजूदा प्रशासक ने या तो रुचि खो दी है या अब मेंटेनेंस की परवाह नहीं करता। ऐसे रिपॉज़िटरी को देखना दुखद है।"

  • मेंटेनर ने सफ़ाई दी कि उसकी रुचि खत्म नहीं हुई है, लेकिन मानसिक स्वास्थ्य जैसी समस्याओं के कारण उसकी मेंटेन करने की क्षमता सीमित हो गई है
  • मेंटेनर ने यह भी याद दिलाया कि यह एक बिना भुगतान वाला हॉबी प्रोजेक्ट है

मांगों में बढ़ोतरी

  • एक हफ्ते बाद, वही असहयोगी उपभोक्ता फिर आया और मेंटेनर को दोष देने लगा।

    • "आप इस मेलिंग लिस्ट में धीरे-धीरे सड़ रहे अनगिनत पैचों को अनदेखा कर रहे हैं।"

    • "मानसिक स्वास्थ्य समस्याओं के लिए मुझे अफ़सोस है, लेकिन अपनी सीमाओं को पहचानना महत्वपूर्ण है। मैं जानता हूँ कि यह प्रोजेक्ट सभी योगदानकर्ताओं के लिए एक हॉबी प्रोजेक्ट है, लेकिन कम्युनिटी इससे ज़्यादा चाहती है।"

  • उस अनुरोधकर्ता ने कुछ सुझाव दिए, लेकिन खुद मदद करने की कोई पेशकश नहीं की

    • "क्या XZ for C का मेंटेनेंस अधिकार किसी और को देकर आप XZ for Java पर ज़्यादा ध्यान नहीं दे सकते? या फिर XZ for Java किसी और को देकर XZ for C पर फोकस नहीं कर सकते? अगर दोनों को मेंटेन करने की कोशिश करेंगे तो शायद दोनों ही ठीक से मेंटेन नहीं होंगे।"

  • मेंटेनर ने समझाया कि नया को-मेंटेनर ढूँढना या प्रोजेक्ट पूरी तरह सौंप देना आसान नहीं है

ओपन सोर्स प्रोजेक्ट की हक़ीक़त

  • सॉफ़्टवेयर डेवलपर ऐसे पुर्ज़े नहीं हैं जिन्हें मनचाहे ढंग से लगाकर हटाया जा सके
  • ईमेल थ्रेड का अंत इस तरह होता है कि शिकायत करने वाला उपभोक्ता लगातार माँगें करता रहता है लेकिन कोई मदद नहीं देता, और अंत में सिर्फ़ हमलावर बचता है

    • "Jia Tan आगे चलकर प्रोजेक्ट में बड़ी भूमिका ले सकता है। वह सूची के बाहर बहुत मदद कर रहा है और व्यवहार में पहले से ही सह-प्रशासक है। :-)"

  • यह ईमेल थ्रेड ओपन सोर्स प्रोजेक्ट में होने वाले इंटरैक्शन का एक लघुरूप दिखाता है
  • उपभोक्ता मेंटेनर के सामने माँगें रखते हैं, और मेंटेनर तनाव व बर्नआउट के बीच अलग-अलग तरह से प्रतिक्रिया देते हैं
  • इस तरीके को बदलने की ज़रूरत है

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

1 टिप्पणियां

 
GN⁺ 2024-03-31
Hacker News की राय

  • एक राय है कि जब डेवलपर यूज़र्स के प्रति विनम्र रहने की कोशिश करते हैं और कमेंट करने वालों की अच्छी नीयत देखने की कोशिश करते हैं, तो इसमें बहुत मानसिक ऊर्जा खर्च होती है। ऐसी राय अक्सर मज़े के लिए चलाए जाने वाले side projects (emulator, game remake आदि) से आती है। ये प्रोजेक्ट donation या copyright से जुड़े मुद्दों से बचने के लिए donation का ज़िक्र करने से बचते हैं। प्रोजेक्ट में रुचि तो बहुत होती है, लेकिन वास्तव में योगदान दे सकने वाली कुशल रुचि बेहद सीमित होती है। यूज़र्स की बातचीत की अनुमति दी जाती है और उसे प्रोत्साहित भी किया जाता है, लेकिन कभी-कभी उन्हें ऐसी 'सुझाव' या 'मांग' के रूप में देखा जा सकता है जो डेवलपर्स का मनोबल गिराती हैं। कम्युनिटी को बनाए रखना महत्वपूर्ण है, लेकिन जो लोग सीधे योगदान नहीं करते उन्हें बाहर न करने को लेकर भी चिंता है.

  • समस्या का पहला चरण एक social engineering attack था, जिसमें open source project के डेवलपर पर हमलावर को repository पर अधिक नियंत्रण सौंपने का दबाव बनाया गया.

  • एक security-oriented open source library के maintainer के रूप में, हर बार PR पढ़ते समय यह भारी संदेह मन में आता है कि "क्या यह व्यक्ति मदद करना चाहता है, या मुझे exploit करना चाहता है?" मुझे लगता है कि विकास की गति धीमी करना ही एकमात्र समाधान है, लेकिन उससे जो भावना पैदा होती है, वह लेख में बताई गई भावना जैसी ही है। अगर किसी भरोसेमंद expert community से मदद माँगने का कोई आसान तरीका हो, तो उसका हमेशा स्वागत होगा.

  • cryptocurrency, AI, और इस घटना की तरह, सबसे बड़ी समस्या आखिरकार trust की समस्या बन जाती है। cryptocurrency trust की समस्या को code से हल करने की कोशिश करता है, LLM भरोसा जीतने के लिए दिखावे से भ्रम पैदा करने की कोशिश करते हैं, और हमलावर trust को "धोकर साफ" करने में कुछ हद तक सफल हो जाते हैं। सबसे महत्वपूर्ण तकनीकी लोग trust के बारे में ठीक से नहीं सोच रहे हैं। इस मामले में, थके हुए, बिना भुगतान वाले open source डेवलपर के प्रति समझ है.

  • यह सवाल है कि क्या port knocking कॉन्फ़िगर किया गया SSH server इस backdoor से सुरक्षित होगा। क्योंकि RCE केवल SSH server से कनेक्ट होने के बाद ही किया जा सकता है, इसलिए अगर port किसी उचित TCP/UDP knocking sequence के पीछे छिपा हो, तो शायद समस्या न हो। port knocking उचित SSH configuration का विकल्प नहीं है, लेकिन SSH vulnerability सामने आने पर यह रोकथाम करने या प्रतिक्रिया के लिए समय देने वाली अतिरिक्त defense layer के रूप में उपयोगी है.

  • OpenSSH के Linux-specific patch से जुड़ी समस्या पर एक लिंक है। अगर यह patch न होता, तो समस्या पैदा नहीं होती। यह OpenSSH की नहीं, बल्कि Linux की समस्या है.

  • एक राय है कि लोग अब भी left-pad घटना के बाद भी hard dependency और complexity को लापरवाही से लेते हैं। OpenSSH code की एक विशाल दीवार है। जटिल सिस्टम, चाहे वे किसी भी भाषा में लिखे गए हों, स्वभावतः भरोसा करना कठिन होते हैं.

  • अगर कोई चीनी हैकर दुर्भावनापूर्ण काम करना चाहता, तो वह चीनी नाम/handle क्यों इस्तेमाल करता? open source maintainers से अधिक trust पाने के लिए अंग्रेज़ी/यूरोपीय नाम का उपयोग करना बेहतर होता। दूसरी ओर, अगर कोई गैर-चीनी हैकर दुर्भावनापूर्ण काम करना चाहता, तो चीनी नाम का उपयोग करना अधिक समझ में आता है (चीन बुरा है, वगैरह).

  • Jigar Kumar अकाउंट social engineering attack का हिस्सा लगता है और उस पर बहुत संदेह होना चाहिए.

  • software developer बदल देने योग्य पुर्ज़े नहीं हैं, और कम्युनिटी में comment करने या भाग लेने की अनुमति को सीमित करने के बारे में सोचा जा रहा है। उदाहरण के लिए, अगर GitHub कोई 'gate' लाए, तो पहला gate ऐसा test जोड़ना हो सकता है जो test suite के लिए version number और test output का hash बनाता हो। अगर इस number को profile में जोड़ा जाए, तो GitHub भरोसा कर सकता है कि यूज़र ने कम से कम make test डाउनलोड करके चलाया है। यह कुछ हद तक प्रतिबद्धता दिखाता है.