Xz: Linux Landlock को निष्क्रिय करने वाला सिर्फ एक अक्षर

 (git.tukaani.org)
1 पॉइंट द्वारा GN⁺ 2024-03-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • xz.git के CMakeLists.txt में बदलाव Landlock sandbox detection को header की मौजूदगी जांचने से वास्तविक compile test में बदलने की प्रक्रिया में हुआ, जिसमें test code के अंदर अकेला . character शामिल हो गया
  • नया check उन systems को filter करने के लिए जोड़ा गया जहां linux/landlock.h मौजूद होने पर भी जरूरी syscall definitions नहीं हो सकतीं
  • compile test में <linux/landlock.h>, <sys/syscall.h>, <sys/prctl.h> शामिल किए जाते हैं और prctl, SYS_landlock_create_ruleset, SYS_landlock_restrict_self, LANDLOCK_CREATE_RULESET_VERSION को reference किया जाता है
  • पुराना criterion HAVE_LINUX_LANDLOCK_H बदलकर HAVE_LINUX_LANDLOCK हो गया है, और SANDBOX_COMPILE_DEFINITION व SANDBOX_FOUND settings भी इसी result को follow करती हैं
  • commit Autotools और CMake builds के Linux Landlock feature test में सुधार है, और दिया गया diff CMake-side change दिखाता है

CMake में Landlock detection method में बदलाव

  • target file xz.git की CMakeLists.txt है, और change point # Sandboxing: Landlock block है
  • पुरानी CMake logic में, जब ENABLE_SANDBOX ON या landlock होता था और SANDBOX_FOUND नहीं होता था, तब check_include_file(linux/landlock.h HAVE_LINUX_LANDLOCK_H) से सिर्फ header की मौजूदगी जांची जाती थी
  • बदलाव के बाद, check_c_source_compiles से छोटा C code वास्तव में compile करके Landlock की availability जांची जाती है
    • कुछ systems में linux/landlock.h होने पर भी Linux Landlock के लिए जरूरी syscall definitions नहीं हो सकतीं
    • test code में <linux/landlock.h>, <sys/syscall.h>, <sys/prctl.h> शामिल हैं
    • my_sandbox() के अंदर prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0), SYS_landlock_create_ruleset, SYS_landlock_restrict_self, LANDLOCK_CREATE_RULESET_VERSION को reference किया जाता है

अकेला character और variable name में बदलाव

  • insert किए गए compile test code के include block के बाद अकेली . line है
  • result variable HAVE_LINUX_LANDLOCK_H से बदलकर HAVE_LINUX_LANDLOCK हो गया है
  • conditional भी if(HAVE_LINUX_LANDLOCK_H) से बदलकर if(HAVE_LINUX_LANDLOCK) हो गया है
  • SANDBOX_COMPILE_DEFINITION value "HAVE_LINUX_LANDLOCK_H" के बजाय "HAVE_LINUX_LANDLOCK" का उपयोग करती है
  • इसके बाद SANDBOX_FOUND ON setting बरकरार रहती है

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

1 टिप्पणियां

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

  • जवाब: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd...
    अगर आपको Linux Landlock access control system के बारे में ज़्यादा जानकारी नहीं है, तो इसकी व्याख्या यहाँ है: https://docs.kernel.org/userspace-api/landlock.html
    xz का आधिकारिक (शायद...) incident response page: https://tukaani.org/xz-backdoor/

    • तो क्या वह function बाद में आने वाले C code के compile होने की जाँच करता था, और सिर्फ उसी स्थिति में Landlock को enable करता था?
      लेकिन diff के बाएँ किनारे के पास चिपके हुए एक छोटे से period की वजह से C code हमेशा invalid हो गया, और इसलिए Landlock हमेशा disabled रहा?
      यह घटियापन की हद तक प्रभावशाली है, और प्रभावशालीपन की हद तक घटिया। मैंने भी पहली बार पढ़ते समय इसे नहीं देखा
    • इसमें plausible deniability है
      छिपाना हो तो Unicode lookalike characters बदलने का और बेहतर तरीका भी है। कुछ तो font के हिसाब से pixel level तक एक जैसे दिखते हैं
      हो सकता है मुझसे flow छूट गया हो, लेकिन क्या यहाँ इरादतन किया गया होना पक्का हो चुका है?
    • यह इतना शातिर है कि PR के दौरान मौके पर पकड़े जाने पर भी कोई कह सकता है, “ओह, मेरे IDE auto-format ने ऐसा कर दिया”
    • Lasse Collin फिर से सामने आए हैं, और लगता है काफ़ी नाराज़ हैं
    • मेरा version control system ऐसे solid green/red strings की बजाय बदले हुए character को ज़्यादा अच्छे से highlight करता है

  • मैं सावधानी से स्कैन कर रहा था और एक ऐसी जगह period दिखा जहाँ वह बिल्कुल नहीं होना चाहिए था, तो मैंने सोचा “अरे, यह तो उम्मीद से आसान है”
    मैंने स्क्रीन को हल्का सा थपथपाया, और वह period हिल गया
    कमबख्त monitor dust

  • यक़ीन नहीं होता कि system security सटीकता की इतनी ढीली chain पर निर्भर करती है। इसे रोकने के लिए कितने ही points थे
    + # A compile check is done here because some systems have
    + # linux/landlock.h, but do not have the syscalls defined
    + # in order to actually use Linux Landlock.
    ऐसे systems के headers को ठीक करके उन्हें explicit रूप से exclude करना चाहिए। अगर कोई header अपनी capability declare ही नहीं करता, तो उसका मतलब क्या है?
    और यह भी समझ नहीं आता कि binary blob बन जाने के बाद, चाहे वह open source से compile हुआ हो, security intact है या नहीं यह verify करने वाला एक भी test क्यों नहीं है
    कोई भी website payment functionality को core feature के end-to-end tests के बिना deploy नहीं करेगा। यहाँ ऐसा लगता है कि feature additions को reliability से ऊपर रखा गया है — यानी priority mismatch
    उम्मीद है कि fix सिर्फ . हटाने भर का नहीं होगा। मैंने अभी HN की दूसरी पोस्ट में . हटाते हुए दिखाया

    • उसने पूरी तरह नया test framework introduce किया, और फिर 2 साल में धीरे-धीरे backdoor डाला
    • जो quote किया गया है वह Jia Tan की बात है [1]। वही comment उस malicious actor ने लिखा था जबकि वह जानबूझकर check को तोड़ रहा था
      header fix या extra tests से इसे रोका नहीं जा सकता था। शुरू में header के टूटे होने का कोई संकेत नहीं था, और extra tests को भी किसी और तरीके से corrupt किया जा सकता था या release tarball में ignore किया जा सकता था
      [1] https://git.tukaani.org/?p=xz.git;a=commit;h=328c52da8a2bbb8...
    • थोड़ा side note है, लेकिन GCC 9.4.0 ने एक टूटा हुआ arm_acle.h header ship किया था [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985] — उस header को include करने वाला code हमेशा compile fail करता था
      चूँकि कोई user GCC 9.4.0 पर compile करने की कोशिश कर सकता था, और उस header पर निर्भर feature application के लिए critical नहीं था, इसलिए build system ने header टूटे होने का पता चलने पर बस उस feature को disable किया और warning दे दी
      xz पर वापस आएँ तो, अगर security सबसे ऊपर की priority न हो, तो optional feature failure को ignore करके आगे बढ़ना भी तर्कसंगत लग सकता है। बेशक बाद में बैठकर उंगली उठाना आसान है, लेकिन उस context के बिना यह पूरी तरह बेतुका फैसला नहीं था
    • open source user के तौर पर मैं इतना जानकार नहीं हूँ कि ऐसा सुझाव दे सकूँ, इसलिए अगर आप खुद इसे develop करके contribute करें तो अच्छा लगेगा
    • क्या आपको पता है कि quoted comment code सच में सही है?

  • अरे, उसका आख़िरी commit तो security reporting को और बदतर बना रहा है: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=af071ef7702...

    • यह स्वीकार कैसे कर लिया गया? सच में जानना चाहता हूँ

  • Landlock को कहाँ/कैसे इस्तेमाल करने के लिए बनाया गया था?
    compression/decompression जैसी general-purpose libraries में इसे वास्तव में इस्तेमाल करना मुश्किल लगता है। लाइब्रेरी को यह नहीं पता होता कि प्रोग्राम को क्या करना है, और क्या सीमित करना है।
    अगर प्रोग्राम हो, तो यह ज़्यादा स्पष्ट हो सकता है।
    sshd हमला liblzma को लाइब्रेरी के रूप में इस्तेमाल कर रहा था। तो फिर Landlock को बंद करना असंबंधित लगता है, नहीं? क्या यह इस बात का संकेत है कि अभी तक न मिला कोई और बुरा कोड था, या बाद में डालने की योजना थी?

    • शायद sshd खुद execution के किसी खास बिंदु के बाद अपनी permissions लॉक करने के लिए इसका इस्तेमाल करता।
      Landlock को हटा देने पर daemon खुद को लॉक नहीं करेगा, इसलिए exploit के उस चरण तक पहुँचने पर payload चलाना आसान हो जाएगा।
      मुझे नहीं लगता कि ये दोनों असंबंधित हैं। लगता है कि वे पहले से payload को ध्यान में रखे हुए थे, और समझ गए थे कि यह एक रुकावट बनेगा।
    • अजीब है। एक ही प्रोजेक्ट में एक-दूसरे से असंबंधित backdoor-जैसे काम दो बार करना मुझे सच में बहुत भद्दा लगता है। इससे फायदा कम और पकड़े जाने का जोखिम कहीं ज़्यादा बढ़ता है।
      यह मामला बहुत उलझाने वाला है। कुछ हिस्से इतने परिष्कृत हैं कि यक़ीन करना मुश्किल है, जबकि दूसरे हिस्से काफ़ी ढीले-ढाले लगते हैं।
    • इसका इस्तेमाल किया जा सकता है और यह अच्छा विचार है, लेकिन इसका मकसद जानबूझकर डाले गए backdoor से ज़्यादा vulnerability exploitation को रोकना है।
      विचार यह है कि लाइब्रेरी किसी अलग thread में कोई जटिल काम शुरू करे, और user code द्वारा कॉल किए गए API के अंदर उसी thread का इंतज़ार करे। वह thread खुद पर Landlock लागू करे और फिर काम शुरू करे। अगर कुछ गड़बड़ हो जाए, तो कोड अलग-थलग रहेगा।
      बेशक इस मामले में यह काम नहीं करेगा, क्योंकि sandbox पर हमलावर का नियंत्रण है। हमलावर उसे बस बंद कर सकता है या मूल से कमज़ोर बना सकता है। फिर भी इसे दूसरे तरीक़ों से किया जा सकता है।

  • आख़िर यहाँ लक्ष्य क्या रहा होगा? क्या बाद में और backdoor, या ज़्यादा plausibly deniable backdoor डालने का इरादा था? मुझे तो लगता है कि oss-fuzz और यह बदलाव, दोनों में से कोई भी मिले हुए backdoor को वास्तव में ढूंढ नहीं पाते।
    फिर सारे backdoor वाले अंडे एक ही टोकरी, यानी एक ही लाइब्रेरी में क्यों रखे गए?

    • वह लाइब्रेरी काफ़ी गहराई तक जमी हुई थी, उस पर काफ़ी भरोसा किया जाता था, और मुख्य डेवलपर मानसिक स्वास्थ्य समस्याओं के कारण लंबे समय तक इंटरनेट से दूर भी रहे थे।
      और ऊपर से लक्ष्य खुद लाइब्रेरी को backdoor करना नहीं था, बल्कि उसे इस्तेमाल करने वाले टूल्स को निशाना बनाना था। यह “Reflections on trusting trust” वाली शैली है।
      नाकाम होने तक यह एकदम परफ़ेक्ट योजना लगती है।
    • लेकिन किसने कहा कि वह सिर्फ़ एक ही लाइब्रेरी थी?

  • सोच रहा हूँ कि xz में Landlock चालू होने से रोकना क्यों उपयोगी था। क्या बाद के किसी चरण में xz archive में malicious content inject करने की योजना थी? अगर ऐसा था, तो xz में ही malicious behavior सीधे क्यों नहीं डाल दिया गया?

    • जानबूझकर डाली गई vulnerability को असली malicious content की तुलना में छिपाना कहीं आसान होता है।
      किसी maintain किए जा रहे C प्रोजेक्ट में buffer overflow या use-after-free को चुपके से डाल देना शायद बिना पकड़े संभव हो सकता है। असली trojan horse वितरित करना कहीं ज़्यादा मुश्किल है, और xz-to-sshd backdoor में यही सामने आया।
    • ssh को निशाना बनाने के अलावा xz खुद के लिए भी कोई ज़्यादा सूक्ष्म backdoor हो सकता था। साफ़ है कि लक्ष्य गोपनीयता था।

  • यह उम्मीद से ज़्यादा नज़र आने वाला है। feature बंद करने की तकनीक चतुर है और commit भी काफ़ी plausible है। लेकिन सिर्फ़ spelling गलती करने के बजाय इतनी साफ़ syntax error क्यों चुनी गई? उदाहरण के लिए, अगर गलती PR_SET_NO_NEW_PRIV होती, तो क्या किसी ने नोटिस किया होता?
    उस तरफ़ इनकार की गुंजाइश भी ज़्यादा होती।

  • अलग से देखें तो, इस malware टीम ने सुरक्षा समस्याएँ पहचानने के लिए AI को ट्रेन करने हेतु शानदार dataset बना दिया है। हर commit में security issue है, और open source community उन्हें एक-एक करके देख कर निकाल ही लेगी।
    सफ़ाई का काम कर रहे maintainers का धन्यवाद। यह निश्चित ही मज़ेदार काम नहीं होगा।

    • नहीं लगता कि यह अच्छी तरह generalize होगा। ज़्यादा से ज़्यादा यह एक arms race ही है।
    • AI के इस्तेमाल में यह काफ़ी शानदार उदाहरणों में से एक है जो मैंने देखा है।
    • मैंने इसके बारे में पहली बार सुना है, क्या कोई इससे जुड़ी जानकारी पोस्ट कर सकता है?

  • इसी वजह से मुझे अपने-आप features चालू-बंद करने वाले configure-style build systems बिल्कुल पसंद नहीं हैं। अगर मुझे कुछ चाहिए, तो मैं उसे साफ़ तौर पर चालू करना चाहता हूँ। अगर किसी feature को default रखने की पर्याप्त वजह है, तो कम से कम उसे साफ़ तौर पर बंद करने का विकल्प होना चाहिए।

    • packaging करते समय यह बहुत बड़ा सिरदर्द होता है। आप पैकेज configure करते हैं, build होने तक dependencies जोड़ते जाते हैं, और सोचते हैं कि काम खत्म हो गया। फिर पता चलता है कि feature X गायब है। क्या हुआ? अरे, libY नहीं था, इसलिए वह चुपचाप बंद हो गया। फिर वापस जाकर उसे जोड़ते हैं। उसके बाद user रिपोर्ट करता है कि feature Z नहीं है।
      बस एक default feature bundle होना चाहिए और ज़रूरत के हिसाब से --enable-a --disable-b की अनुमति देनी चाहिए।
      जाँच प्रक्रिया में आए bugs को चुपचाप निगल जाना तो एक अलग ही समस्या है।