SSH बॅकडोरिंग
एका दुर्भावनापूर्ण किंवा असुरक्षित देखरेखकर्त्याने नावाच्या लायब्ररीमध्ये दुर्भावनापूर्ण वर्तन समाविष्ट केले. लिब्लझ्माxz कॉम्प्रेशन टूल्स आणि लायब्ररीजचा एक भाग वापरल्यामुळे SSH मध्ये बॅकडोअर तयार झाला आहे. हा एक प्रगत सॉफ्टवेअर सप्लाय चेन हल्ला आहे, कारण बॅकडोअरसाठी लायब्ररीमध्ये हेतुपुरस्सर बदल करण्यात आला होता आणि समीक्षकांपासून हल्ल्याचा पेलोड लपवण्यासाठी ऑबफस्केशन व स्टेल्थ तंत्रांचा वापर करण्यात आला होता.
हे अलीकडेच (गेल्या २९ मार्च रोजी) उघडकीस आले आणि या हल्ल्यावरील कारवाई सुरू आहे. तथापि, यावर त्वरित नियंत्रण मिळवण्यात आले, कारण असे दिसते की याचा परिणाम केवळ मर्यादित वातावरणांच्या (x86_64 आर्किटेक्चरसाठी, GCC सह तयार केलेले DEB आणि RPM पॅकेजेस) प्री-रिलीज आवृत्त्यांवरच होत होता. असो, सीव्ही दिले होते सीव्हीएसएस बेस स्कोअर १० पैकी, जे सर्वात गंभीर सायबरसुरक्षा त्रुटींसाठी राखीव आहे. जर ते स्थिर वितरणांमध्ये आले, तर त्याचा परिणाम जबरदस्त असेल.
हल्ल्याचे तांत्रिक विश्लेषण, ज्यामध्ये खालील गोष्टींचा समावेश आहे xz बॅकडोअरचे सखोल स्पष्टीकरणयाचे विश्लेषण इतरत्र करण्यात आले आहे. या पोस्टमध्ये हल्ल्याची कालक्रमानुसार मांडणी, तो कसा शोधता आला, आजपर्यंत ही घटना कशी हाताळली गेली आणि या हल्ल्यातून कोणते धडे घेता येतील यावर लक्ष केंद्रित केले जाईल.
सुरुवातीच्या पॅचनंतरही बॅकडोअरचा प्रभाव बराच काळ टिकून राहिला आहे. ऑगस्ट २०२५ मध्ये, CVE-2024-3094 उघडकीस आल्यानंतर एका वर्षाहून अधिक काळानंतर, बिनार्ली येथील सुरक्षा संशोधकांना डॉकर हबवर प्रकाशित केलेल्या डझनभर डेबियन डॉकर इमेजेसमध्ये हा बॅकडोअर अजूनही अस्तित्वात असल्याचे आढळले, परंतु डेबियनच्या टीमने त्यांना सक्रिय धोका मानण्याऐवजी, विकासादरम्यानचे ऐतिहासिक अवशेष मानून, त्या काढून टाकण्यास नकार दिला. याव्यतिरिक्त, OpenSSF आणि XZ घटनेनंतर लगेचच OpenJS ने एक संयुक्त इशारा जारी केला की, अशाच प्रकारचे सोशल-इंजिनिअरिंगद्वारे ताबा मिळवण्याचे प्रयत्न यापूर्वीच जावास्क्रिप्ट प्रकल्पांना लक्ष्य करत होते, ज्यामुळे असे सूचित होते की येथे वापरलेला मेंटेनर-ट्रस्ट हल्ल्याचा नमुना इतरत्रही पुन्हा वापरला जात आहे.
XZ बॅकडोअर कसा टाकला गेला
टीप: गिट रिपॉझिटरी यामध्ये आहे git.tukaani.org. तथापि, तेथे एक देखील होते गिटहब होस्टेड रिपॉझिटरी (सध्या ब्लॉक केलेले) ज्या गिटहब खात्यावरून ते बदल पोस्ट केले जात होते जे नंतर गिट रेपॉजिटरीमध्ये समाविष्ट केले गेले.
बॅकडोअरचा एक भाग केवळ 5.6.0 आणि 5.6.1 आवृत्त्यांसाठी वितरित केलेल्या टारबॉल्समध्ये असल्याचे दिसते, गिट रिपॉझिटरीजमध्ये नाही आणि तो एकावर अवलंबून आहे build-to-host.m4 मधील एकच ओळ ऑटो कॉन्फने वापरलेली मॅक्रो फाईल. दुसरा भाग दोन तथाकथित टेस्टफाईल्समध्ये होता. bad-3-corrupt_lzma2.xz आणि good-large_compressed.lzma
ते होते commitटेड “जिया टॅन” या गिटहब खात्याद्वारेJiaT75) मध्ये xz रिपॉझिटरी २३ फेब्रुवारी रोजी, हा एक साधा बदल होता ज्यामध्ये टेस्टफाईल्स (कथितरित्या .lzma आणि .xz कॉम्प्रेस्ड ब्लॉक्स) जोडण्यात आल्या होत्या. विशेष म्हणजे, त्या टेस्ट फाईल्सचा चाचण्यांमध्ये वापरच झाला नाही! .m4 फाईलमधील ओळ, काही अटी जुळल्यास configure च्या शेवटी कार्यान्वित करण्यासाठी एक ऑबफस्केटेड स्क्रिप्ट (जी टारबॉलमध्ये समाविष्ट आहे) इंजेक्ट करते. ती Makefile मध्ये बदल करते... लिब्लझ्मा लायब्ररीमध्ये .xz फाईलमधून डेटा काढणारा कोड असेल, जो डीऑबफस्केशननंतर समाप्त होतो. या स्क्रिप्टमध्ये, हे configure च्या शेवटी कार्यान्वित केले जाते. कोड इंजेक्ट करण्यासाठी बिल्ड प्रक्रियेत बदल करायचा की नाही हे ते ठरवते: केवळ GCC आणि GCC लिंकर अंतर्गत, डेबियन किंवा rpm अंतर्गत, आणि केवळ x86_64 लिनक्ससाठी. जेव्हा हे जुळते, तेव्हा इंजेक्ट केलेला कोड दोन बदलून कार्यान्वयनात अडथळा आणतो. ifunc रिझॉल्व्हर्समुळे काही विशिष्ट कॉल्स बदलले जातात. यामुळे सिम्बॉल टेबल्स मेमरीमध्ये पार्स केले जातात (याला वेळ लागतो, ज्यामुळे हे शोधले गेले, जसे नंतर स्पष्ट केले आहे).
मग गोष्टी रंजक होतात: बॅकडोअर डायनॅमिक लिंकरमध्ये एक ऑडिट हुक स्थापित करतो, जो RSA_public_decrypt फंक्शन सिम्बॉल येण्याची वाट पाहतो, ज्याला बॅकडोअर कोडमधील एका पॉइंटकडे पुनर्निर्देशित केले जाते, जो पुढे कॉल बॅक करतो. libcryptoबहुधा सामान्य प्रमाणीकरण करण्यासाठी. आणि जर चालू असलेल्या प्रोग्रामचे प्रोसेस नाव असेल तर पेलोड सक्रिय होतो. /usr/sbin/sshdहे स्पष्ट होते की SSH सर्व्हर हे लक्ष्य होते. पारंपारिकपणे, एसएसडी ओपनएसएसएच सारखे सर्व्हर जोडलेले नव्हते लिब्लझ्मापण sshd आहे अनेकदा पॅच केलेले systemd-notify ला समर्थन देण्यासाठी, जेणेकरून sshd चालू असताना इतर सेवा सुरू होऊ शकतील. आणि मग liblzma अप्रत्यक्षपणे लोड केले जाते. systemdवर्तुळ पूर्ण करत.
बॅकडोअरचे अद्याप पूर्णपणे विश्लेषण झालेले नाही, पण असे दिसते की... दूरस्थ कमांड अंमलबजावणीला परवानगी देणे (आरसीई) sshd डेमनच्या विशेषाधिकारांसहप्री-ऑथेंटिकेशन संदर्भात चालणारे. रिमोट सर्टिफिकेटमधील माहिती, जेव्हा बॅकडोअरशी जुळते, तेव्हा ती ChaCha20 वापरून डिक्रिप्ट केली जाते आणि यशस्वीरित्या डिक्रिप्ट झाल्यावर ती पुढे पाठवली जाते. सिस्टम()म्हणून, हा मूलतः एक गेटेड RCE आहे, जो केवळ पब्लिक की बायपासपेक्षा खूपच वाईट आहे.
नंतरच्या ५.६.१ टारबॉलमध्ये, खुणा लपवण्यासाठी अतिरिक्त प्रयत्न दिसून आले, ज्यात सिम्बॉलच्या नावांकरिता अधिक अस्पष्टीकरण जोडण्यात आले आणि आढळलेल्या त्रुटी दुरुस्त करण्याचा प्रयत्न करण्यात आला. विस्तार यंत्रणा बॅकडोअरमध्ये समाविष्ट करण्यासाठी विशिष्ट सिग्नेचर शोधण्याकरिता अतिरिक्त चाचणी फाइल्स तपासण्याची व्यवस्था देखील करण्यात आली होती.
स्थिर लिनक्स डिस्ट्रिब्युशन्स उपलब्ध होईपर्यंत हा बऱ्यापैकी अत्याधुनिक हल्ला लक्षात न येता राहू शकतो. सुदैवाने, काही लोकांना असामान्य गोष्टी का घडतात हे तपासायला आवडते.
एक्सझेड बॅकडोअर हल्ल्याचा शोध
बऱ्याच वेळा हेतुपुरस्सर केलेले दुर्भावनापूर्ण वर्तन योगायोगाने किंवा अपघाताने उघडकीस येते. याचे एक उत्तम उदाहरण होते... अप्रचलन चेतावणी (“इशारे कोणाला महत्त्वाचे वाटतात?”) ज्यामुळे याचा शोध लागला इव्हेंट-स्ट्रीम हल्ला ऑक्टोबर २०१८ मध्ये. दुसरा तो वापरकर्ता आहे ज्याने चेतावणी दिली. कोडकोव्ह एप्रिल २०२१ मध्ये त्यांची बॅश अपलोडर स्क्रिप्ट चेकसममध्ये उत्तीर्ण झाली नाही (“चेकसमद्वारे आर्टिफॅक्ट्सच्या अखंडतेची पडताळणी कोण करते?”) एसएसएचमधील विसंगती आणि विचित्र लक्षणे loginएस (login(जास्त CPU वापरल्यामुळे आणि लागणारा वेळ वाढल्यामुळे, तसेच व्हॅलग्राइंडमधील त्रुटींमुळे) उत्सुकता वाढली. आंद्रेस फ्रुंडएक दक्ष PostgreSQL डेव्हलपर, पण सुरक्षा विश्लेषक नाही (जसे त्याने सांगितले).डेबियन सिडवर ओपनएसएसएच (OpenSSH) वापरून काही तपासणी केल्यानंतर, त्याने असा निष्कर्ष काढला की प्रतिसाद वेळेची समस्या एका लायब्ररीवर अवलंबून होती. लिब्लझ्मा, चा भाग xz-utils कॉम्प्रेशन लायब्ररी. कारण: “अपस्ट्रीम xz रेपॉजिटरी आणि xz टारबॉल्समध्ये बॅकडोअर टाकण्यात आले आहेत.हे निदान खूपच अचूक होते! २९ मार्च २०२४ रोजी आंद्रेसने ओपनवॉलवर पहिले विश्लेषण पोस्ट केले: “अपस्ट्रीम xz/liblzma मधील बॅकडोअरमुळे ssh सर्व्हर हॅक होण्याचा धोका.वस्तुस्थिती: XZ Utils 5.6.0 आणि 5.6.1 टारबॉल्समध्ये एक बॅकडोअर आहे. हे टारबॉल्स वर नमूद केलेल्या जिया टॅन खात्याद्वारे तयार आणि स्वाक्षरित केले गेले होते. He मॅस्टोडॉनमध्ये पोस्ट केले त्याच दिवशी नंतर, हा शोध अपघाती होता आणि त्यासाठी अनेक योगायोगांची गरज होती, हे लक्षात आले. इतर वापरकर्त्यांच्या प्रतिक्रिया वाचण्यासारख्या आहेत. गिटहब वापरकर्ता थेसेमसॅम (उर्फ सॅम जेम्स) यांनी एक छान सारांश प्रकाशित केला. xz-utils बॅकडोअरवरील वारंवार विचारले जाणारे प्रश्न जिथे हल्ल्याचा सारांश दिला होता, अधिक माहितीसह सखोल विश्लेषणे हल्ल्याच्या पेलोडचा. ही विश्लेषणे तांत्रिकदृष्ट्या महत्त्वपूर्ण होती आणि त्यामुळे आम्हाला अत्यंत तपशीलवार असलेल्या इंजेक्शन प्रक्रियेला अधिक चांगल्या प्रकारे समजून घेण्यास मदत झाली.- xz/liblzma: बॅश-स्टेज ऑबफस्केशनचे स्पष्टीकरणइंजेक्शन स्क्रिप्टद्वारे चार "टप्प्यांमध्ये" होणाऱ्या डीऑबफस्केशनचे छान विश्लेषण.
- फिलिपो वाल्सोर्डाचा निळ्या आकाशाचा धागा RSA_public_decrypt मधील बॅकडोअरचे विश्लेषण त्याचे स्वरूप दर्शवते: हा एक RCE (रिमोट कोड एक्झिक्युशन) आहे, ऑथेंटिकेशन बायपास नाही, आणि तो गेटेड (जो लेखकाची प्रायव्हेट की स्वीकारतो आणि तसे न झाल्यास, सामान्य स्थितीत परत येतो) / परतफेड न करण्यायोग्य आहे. पकडले जाणे टाळण्यासाठी लेखकाने आपली ओळख गुप्त ठेवण्याचा प्रयत्न केला होता!
- @smx-smx द्वारे XZ बॅकडोअरचे विश्लेषण (प्रगतीपथावर) – बॅकडोअरचे अतिरिक्त विश्लेषण (मी तर सुरुवातीलाच गोंधळून गेलो होतो 😀)
- xz बॅकडोअर डॉक्युमेंटेशन विकी5.6.1 इंजेक्शन स्क्रिप्टचे आणखी एक विश्लेषण.
घटनेचे प्रकरण कसे हाताळले गेले
अँड्रियास फ्रॉइंड यांनी सावधगिरीने खुलासा केला कारण, त्यांच्याच शब्दांत:अपस्ट्रीमचा स्पष्ट सहभाग लक्षात घेता, मी अपस्ट्रीम बगची तक्रार केलेली नाही. सुरुवातीला मला वाटले की ही डेबियन-विशिष्ट समस्या आहे, म्हणून मी security@...ian.org वर एक अधिक प्राथमिक अहवाल पाठवला. त्यानंतर, मी distros@ वर या समस्येची तक्रार केली. CIS'अ' ला एका वितरणाद्वारे सूचित करण्यात आले.
कोणावर हल्ला होत आहे?
एकतर GitHub JiaT75 खाते हॅक झाले होते (लक्षात ठेवा की GitHub ने अलीकडेच 2FA अनिवार्य केले आहे) किंवा त्या खात्याचा प्रत्यक्ष मालक हॅक झाला होता. परंतु, या हल्ल्याची तांत्रिक गुंतागुंत पाहता, हा एक प्रगत आणि सातत्यपूर्ण धोका (APT) असू शकतो, जो कदाचित शासन-समर्थित असेल, असा विचार करण्यास ठोस कारणे आहेत. सायबर सुरक्षा संस्था आणि कायद्याची अंमलबजावणी करणाऱ्या यंत्रणांकडून होणाऱ्या पुढील तपासातूनच हे स्पष्ट होईल… ही नोंद वायकॉम्बिनेटर हॅकर न्यूजमध्ये जिया टॅन यांच्याविषयी हे 'कोण' आहे आणि त्याच्या हालचालींवर प्रकाश टाकते. शिफारस केलेले! वाईट प्रवृत्तीचे लोक सोशल इंजिनिअरिंगचा वापर करून इतर वापरकर्त्यांना कसे फसवण्याचा प्रयत्न करतात, याबद्दल यात बरीच माहिती मिळते.खूप त्रासदायक आहे - बॅकडोअरचा कथित सूत्रधार, xz 5.6.x ला त्याच्या "उत्तम नवीन वैशिष्ट्यांमुळे" फेडोरा 40 आणि 41 मध्ये समाविष्ट करून घेण्यासाठी अनेक आठवड्यांपासून माझ्या (rwmj) संपर्कात होता. आम्ही व्हॅलग्राइंडची समस्या सोडवण्यासाठी त्याच्यासोबत कामही केले (जी आता असे दिसून आले आहे की त्यानेच टाकलेल्या बॅकडोअरमुळे निर्माण झाली होती). काल रात्री निर्बंधांचे अनवधानाने उल्लंघन झाल्यामुळे, ही समस्या सोडवण्यासाठी आम्हाला धावपळ करावी लागली. तो २ वर्षांपासून xz प्रकल्पाचा भाग आहे, सर्व प्रकारच्या बायनरी टेस्ट फाइल्स टाकत आहे, आणि खरे सांगायचे तर, त्याच्या या अत्याधुनिकतेमुळे, जोपर्यंत अन्यथा सिद्ध होत नाही, तोपर्यंत मला xz च्या जुन्या आवृत्त्यांवरही संशय येईल.
जिया टॅनने मागोवा घेतला जाऊ नये यासाठी उपाययोजना केल्या: असे दिसते की, कनेक्ट होण्यासाठी VPN (vpn.singapore.witopia.net) वापरले आहे – जे तसे पाहता ठीकच आहे. आणि अनेक बदल हे, बदल विलीन (मर्ज) करण्याचा आग्रह करणाऱ्या, तात्पुरत्या, एकदाच वापरता येणाऱ्या ईमेलद्वारे (या प्रकरणात प्रोटॉनमेलकडून) समर्थित असल्याचे दिसते.
योगदानकर्ता म्हणून, तो अभिनेता आणखी खोलवर, थेट लिनक्स कर्नलपर्यंत जाण्याचा विचार करू शकतो. xy-एम्बेडेड प्रकल्प. आजपर्यंतच्या प्राथमिक विश्लेषणात गर्भपाताचा कोणताही पुरावा आढळला नाही.
टीप: आणखी एक कमी प्रसिद्ध असलेला XZ योगदानकर्ता “हॅन्स जानसेन“ (गिटहब वापरकर्ता “hansjans162”) आहे छाननी अंतर्गतडेबियनवरील त्याचे खाते आता आहे अवरोधितत्याने debian/xz-utils वर त्याला हवा असलेला एक अपडेट लपवण्यासाठी डेबियन गेम्समध्ये अनेक अपडेट्स केले, तसेच बॅकडोअरच्या वितरणाला गती देण्यासाठी अपस्ट्रीम 5.6.1 मध्येही अपडेट केले. डेबियन/अस्थिर.
सध्यापुरते आपण एवढेच म्हणू शकतो की, हा एक (अद्याप ओळख न पटलेला) APT आहे जो वेगवेगळी खाती वापरत आहे, किमान दोन वर्षांपासून या मोहिमेवर काम करत आहे आणि SSH मध्ये RCE रोपण करण्याचे काम संयमाने करत आहे.
हे लिहीपर्यंत, “जिया टॅन” च्या मागे असलेली ओळख अद्याप निश्चित झालेली नाही. कोणत्याही विशिष्ट व्यक्ती, संस्था किंवा सरकारी घटकाशी याचा विश्वसनीय संबंध असल्याचे सार्वजनिकरित्या सत्यापित झालेले नाही, ज्यामुळे त्या व्यक्तीची कार्यप्रणालीतील शिस्त किती प्रभावी होती हे अधोरेखित होते.
XZ बॅकडोअर हल्ला टाळता आला असता का?
बऱ्यापैकी अवघड.
पहिले म्हणजे, इंजेक्ट केलेल्या बॅकडोअरचा काही भाग अशा कॉम्प्रेस्ड टेस्ट फाइल्समध्ये आला, ज्यांचा वापर टेस्ट्समध्ये केला गेला नव्हता. मागे वळून पाहता, यामुळे काही (अनावश्यक) धोक्याची सूचना मिळू शकते, पण खऱ्या जगात सर्व टेस्ट फाइल्स प्रत्यक्ष टेस्ट्समध्ये वापरल्या जातात की नाही हे तपासण्याची पर्वा कोण करणार? दुसरे म्हणजे, इंजेक्ट केलेल्या बॅकडोअरचा काही भाग मॅक्रो फाइल्समधून रिलीज टारबॉल्समध्ये आला, आणि अपेक्षित टारबॉल्ससोबत काही फरक आहे का हे मॅन्युअली तपासणे अवघड आहे. ऑटोमेशनसुद्धा गुंतागुंतीचे आहे, कारण बिल्डमधून मिळणाऱ्या अपेक्षित परिणामाचे (ज्यांना ऑटोमेक/ऑटोकॉन्फ कसे काम करते हे माहित आहे त्यांच्यासाठी) मॉडेलिंग करणे अवघड आहे, जेणेकरून खरा टारबॉल अपेक्षांशी जुळतो की नाही याचे विश्लेषण करता येईल. काहींनी ते मांडले as गिट ट्रीमधून टारबॉल्स न जुळणे हे एक वैशिष्ट्य आहे, दोष नाही.बायनरी टारबॉलच्या सोर्स कोडमधील उत्पत्तीचा स्रोत निश्चित करणे ही एक अनुत्तरित समस्या आहे.
वापरकर्त्याची प्रतिष्ठा? बरं, पूर्वीच्या नोंदीनुसार JiaTan75 गिटहब खाते काहीही गैरप्रकार करत नव्हते. commitपुरावे गोळा झाल्यानंतरच ते निलंबित करण्यात आले, पण २९ मार्चपर्यंत तो एक सामान्य वापरकर्ता होता जो नेहमीप्रमाणे व्यवहार करत होता. बरं, ते काही इतकंही सामान्य नव्हतं. नंतर commitएस (या, या, याआणि या बॅकडोअरला अपेक्षित असलेल्या स्टॅक लेआउटमधील फरकांमुळे, काही कॉन्फिगरेशनमध्ये येणाऱ्या व्हॅलग्राइंड त्रुटी आणि क्रॅश दुरुस्त करण्याचा प्रयत्न केला गेला (ज्यामध्ये एक्सप्लॉइट कोड समायोजित केला गेला). Commit रिव्ह्यूमध्ये हे शोधता येऊ शकते, पण बायनरी टेस्ट फाईलमधील बदलांचे विश्लेषण करण्याचा किंवा सी सोर्स कोडमधील जीसीसी ॲट्रिब्यूट्समधील बदलामागील खरा हेतू जाणून घेण्याचा धीर कोणामध्ये आहे?
SSH असताना धोक्याची सूचना द्यावी का? login ३०० मिलीसेकंदांऐवजी ८०० मिलीसेकंद लागतात? कदाचित फक्त अतिसावध लोकच याची नोंद घेतील. सिसेरो म्हणाला, अविचारीपणा तारुण्यात आढळतो; विवेक म्हातारपणात.
ifunc पायाभूत सुविधा जून २०२३ मध्ये “हॅन्स जानसेन” आणि “जिया टॅन” यांच्याद्वारे जोडण्यात आली. ही पहिलीच आहे commit crc64_fast.c मध्ये ifunc सपोर्ट जोडणे (ज्याचा वापर नंतर बॅकडोअर टाकण्यासाठी केला गेला). टेस्ट फाईल्समध्ये बॅकडोअर बायनेरीज टाकण्याच्या कित्येक महिने आधी!
टीप: लेखक आणि commitयेथे मतभेद आहेत, पण हे सामान्य आहे: लासे कॉलिन हे प्रकल्पाचे देखभालकर्ते आहेत आणि त्यांनीच हे बदल विलीन केले आहेत. ते “हान्स जानसेन” यांचे आभारही मानतात…
आंद्रेस फ्रॉइंड यांच्या पोस्ट आणि रेडहॅटने तयार केलेल्या CVE च्या आधी कोणीही चिंता व्यक्त केली नव्हती. जर तुम्हाला हे पकडू शकणाऱ्या साधनांची एक साखळी दिसली, तर ती आता प्रभावित घटक शोधून काढते. भूतपूर्व पोस्ट.
बहुधा सर्वोत्तम प्रतिबंध लिनक्स डिस्ट्रिब्युशन्सच्या स्वरूपामुळेच झाला, आणि अस्थिर, अत्याधुनिक आवृत्त्या एका टप्प्याटप्प्याने चालणाऱ्या प्रक्रियेनंतरच स्थिर डिस्ट्रिब्युशन्सकडे हस्तांतरित होतात.
XZ बॅकडोअर हल्ल्यातून मिळालेले धडे
शोधणे किती अवघड आहे हे आम्ही लक्षात घेतले आहे. मुद्दाम बॅकडोअर्स. बॅकडोअर्सना एक अंतर्गत धोका मानले पाहिजे, कारण ते अंतर्गत कर्मचाऱ्यांद्वारे किंवा हॅक झालेल्या अंतर्गत खात्यांमार्फत पेरले जातात. आणि हे लोक बहुतेकदा विश्वासू असतात. आणि जेव्हा बॅकडोअर वितरित केलेल्या आर्टिफॅक्टमध्ये पेरला जातो, तेव्हा त्याला शोधणे अधिक कठीण होते.
केविन ब्यूमोंटसारखे काही लेखक बोट दाखवले प्रणालीयामुळे बॅकडोअरसाठी तृतीय-पक्ष सेवांचा एक मोठा हल्ला-क्षेत्र खुला होतो. येथे दुर्भावनापूर्ण व्यक्तीने याचाच गैरवापर केला. सिस्टमडीवर अनेक लोकांची नजर असते, पण साखळीत पुढे असलेली एक्सझेड (XZ) ही एक अज्ञात लायब्ररी आहे. “जेव्हा प्रवाहाचा वरचा भाग दूषित असतो, तेव्हा प्रवाहाच्या खालच्या भागातील प्रत्येकजण विषारी पाणी पितो”.
सिस्टममधील एका असंबंधित बदलाच्या विनंतीसाठी डायनॅमिकली लोडिंग कॉम्प्रेशन लायब्ररीबॅकडोअर काढून टाकणारे ते, प्रणालीमध्ये आधीच विलीन केले गेले होते परंतु अद्याप वितरित केले गेले नव्हते. libsystemd मुळे निर्माण होणारे अतिरिक्त अवलंबित्व हे असुरक्षिततेचे स्रोत असू शकतात.आणि काल ही विनंती उघडण्यात आली होती..
A टिप्पणी "xz: समस्या सोडवण्यासाठी ifunc अक्षम करा" मध्ये commit अशा प्रकारच्या कारवायांना प्रतिबंध करायचा असेल तर कुठे लक्ष केंद्रित करायला हवे, यावर एक अचूक अंतर्दृष्टी दिली (ठळक अक्षरे माझी आहेत):
एक समाज म्हणून आपण शिकायला हवा तो धडा म्हणजे अधिक सुरक्षित राहणे. software supply chain security सर्वांगीणपणे, केवळ सोर्स कोडच्या पलीकडे जाऊन बिल्ड सिस्टीमचे ऑडिट करणे. जसे की सोलरविंड्स डेटा चोरीची घटना, जिथे हल्लेखोरांनी सोलरविंड्सच्या क्लोज्ड-सोर्स मॉनिटरिंग सॉफ्टवेअरसाठीच्या सॉफ्टवेअर अपडेट्समध्ये बदल केले होते.”
FAQ
XZ बॅकडोअर आजही धोकादायक आहे का?
बहुतांशी नियंत्रणात आले आहे, पण पूर्णपणे नाहीसे झालेले नाही. ऑगस्ट २०२५ मध्ये, संशोधकांना अनेक डेबियन डॉकर हब इमेजेसमध्ये बॅकडोअर अजूनही अस्तित्वात असल्याचे आढळले, ज्यांना डेबियनने निष्क्रिय ऐतिहासिक अवशेष म्हणून गणले आहे. २०२४ च्या पॅचने हा दरवाजा पूर्णपणे बंद केला आहे असे गृहीत धरण्याऐवजी, टीम्सनी हे पडताळून पाहावे की ते कालबाह्य, पॅच न केलेल्या बेस इमेजेसवर बिल्ड करत नाहीत.
