Hacker News के जवाब में...

मैं देख रहा हूँ कि [नारंगी वेबसाइट][hn] पर तुम मज़ाकिया लोग मुझे परेशान कर रहे हो। मैं नीचे कुछ चुनिंदा जवाब दूँगा, लेकिन पहले मैं एक चुनौती पेश करता हूँ: मैं अपने $500 उस पहले व्यक्ति को भेजूँगा जो ifunc के बिना इस हमले को प्रदर्शित कर सके। मुझे वास्तव में दिलचस्पी है, और मैं ज्ञान के लिए भुगतान करने को तैयार हूँ। इस रेपो को फोर्क करें और अपने काम करने वाले PoC के साथ PR सबमिट करें, यदि आप जीतते हैं तो मैं निजी तौर पर आपका मेलिंग पता माँगूँगा। अब जवाब:

यह गलत पेड़ पर भौंक रहा है।

बच्चे, मैं तो गलत पेड़ में ही रहता हूँ, मैं जिस पर चाहूँ भौंक सकता हूँ।

यह एक्सप्लॉइट के लिए आवश्यक नहीं था,

तुम एक्सप्लॉइट के लिए आवश्यक नहीं हो!

अगर हम रूट के रूप में मनमाने कोड चलने से बचाव जोड़ना चाहें तो हमेशा selinux है।

एक बार लोड होने के बाद, इस हमले को किसी और syscall सीमा को पार करने की आवश्यकता नहीं थी। तो हाँ, हम एक "बोनस" रूट सेशन को सीमित कर सकते थे, लेकिन फिर भी मशीन पर बिन बुलाए मेहमान होते!

यह क्या है, बिल्बो का जन्मदिन?? पार्टी के काम के अलावा कोई प्रवेश नहीं!!

1. IFUNC मेन से पहले कोड चलाने का एकमात्र तरीका तो बिल्कुल नहीं है।

लेकिन यह मेमोरी सुरक्षा सेट होने से पहले कोड चलाने का एक अनावश्यक तरीका है

2. उनका प्रस्तुत विकल्प संभवतः कम सुरक्षित है क्योंकि फंक्शन पॉइंटर प्रोसेस के जीवनकाल तक लिखने योग्य बना रहेगा,

हम mprotect के साथ काम चला सकते हैं! Modifying LD_PRELOAD उपधारा के ऊपर वाला अंतिम वाक्य देखें।

हाँ, यह ब्लॉग भ्रमित है।

क्षमा करें, यह ब्लॉग अनिर्देशित था। ये सारी शरारतें मैंने खुद कीं! किसी ने मुझे इस बेवकूफी के लिए बहकाया नहीं।

IFUNC को [क्लाइंट] सॉफ़्टवेयर द्वारा ही लागू किया जाना चाहिए,

@CountWSS 💯 बिल्कुल सही

स्पष्ट प्रोसेस विफलताओं की एक श्रृंखला Github मेंटेनर की ओर से से ...

यह एकमात्र बिंदु है जिसका मैं गंभीरता से जवाब दूँगा:

मुझे लगता है कि xz-utils मेंटेनर के साथ यह बेहद अन्यायपूर्ण है और समुदाय के लिए काफी खतरनाक है कि इसे उनकी ओर से एक गलती से शुरू होना माना जाए। यह इस बात से शुरू हुआ कि इस प्रोजेक्ट को मेंटेन करने में मदद करने की किसी को परवाह नहीं थी। हमलावर ने ifunc पर एक तकनीकी भेद्यता के रूप में निर्भर किया और xz-utils की हमारी सामूहिक उपेक्षा पर एक सामाजिक भेद्यता के रूप में। मुझे लगता है कि श्री कोलिन के कार्यों को एक वीरतापूर्ण, वर्षों लंबे सामुदायिक सेवा समर्पण के अलावा किसी और रूप में देखना शर्मनाक है।

साथ ही ब्रूस श्नाइयर मुझसे सहमत हैं तो... बुरा लगेगा, तुम्हारी दलील खत्म।

भाषा जितनी कठोर होनी चाहिए थी उससे ज़्यादा कठोर रही होगी

तुम यकीन नहीं करोगे कि मेरे दोस्तों ने पहले इसे कितना हल्का करवाया।

लिनक्स डिस्ट्रीब्यूशन्स को खुद को इतना ऊँचा नहीं समझना चाहिए कि वे OpenBSD से अपेक्षा करें कि वह उनकी गड़बड़ के अनुरूप ढल जाए

@debazel!!! मुझे पसंद है।

क्या बकवास है।

ठीक है, वह हिस्सा सही है।

IFUNC'd up

आपको [CVE-2024-3094][nvd] के लिए xz-utils को दोष देना क्यों बंद कर देना चाहिए। साथ ही मेरा ETSA Talk भी देखें!

CVE-2024-3094, जिसे आमतौर पर "The xz-utils backdoor" के नाम से जाना जाता है, वैश्विक साइबर सुरक्षा के लिए एक बाल-बाल बची घटना थी। अगर इस हमले को [आंद्रेस फ्रायंड][freund] द्वारा ठीक समय पर खोजा न गया होता, तो हमारे ग्रह के अधिकांश SSH सर्वर इस हमले के पीछे वाले पक्ष को रूट एक्सेस देना शुरू कर चुके होते।

दुर्भाग्य से, बहुत अधिक विश्लेषण इस बात पर केंद्रित रहा कि [दुर्भावनापूर्ण कोड][JiaT75] xz-utils रेपो में कैसे पहुँचा। इसके बजाय, मैं यह तर्क देना चाहूँगा कि महत्वपूर्ण ओपन सोर्स सॉफ़्टवेयर में दो पुराने डिज़ाइन निर्णयों ने इस हमले को संभव बनाया: [OpenSSH को SystemD के साथ लिंक करना][biebl], और [GNU IFUNC][sourceware] का अस्तित्व।

शुरू करने से पहले: इस चर्चा का बहुत हिस्सा लिनक्स पर डायनामिक लिंकिंग की जटिलताओं से संबंधित है। अगर आपको रिफ्रेशर की आवश्यकता हो, तो dynamic_linking.md देखें।

CVE-2024-3094 का संक्षिप्त पुनरावलोकन

xz-utils बैकडोर के उच्च-स्तरीय विवरणों की रूपरेखा देने वाले बहुत सारे अच्छे लेख हैं, जैसे डैन गुडिन का [What we know about the xz Utils backdoor that almost infected the world][goodin1] और सैम जेम्स का [FAQ on the xz-utils backdoor (CVE-2024-3094)][thesamesam] gist। हमें यहाँ उन सब को दोहराने की आवश्यकता नहीं है, इसलिए इस लेख के उद्देश्य के लिए, यहाँ एक बहुत मोटा पुनरावलोकन है:

• कुछ लिनक्स डिस्ट्रो OpenSSH को संशोधित करके उसे SystemD पर निर्भर बनाते हैं
• SystemD xz-utils पर निर्भर करता है, जो GNU IFUNC का उपयोग करता है
• अतः, xz-utils OpenSSH के एड्रेस स्पेस में पहुँच जाता है
• यह ifunc को SSH सर्वर में कोड संशोधित करने की अनुमति देता है```mermaid flowchart TD G["GNU IFUNC"] A["OpenSSH (OpenBSD)"] B["Portable OpenSSH
  (Linux / macOS / etc)"] C[OpenSSH + IFUNC] D[xz-utils] E["SystemD (Linux)"] A -->|Remove OpenBSD specifics| B B -->|Add SystemD specifics| C D --> E E --> C C --> F["Mayhem"] G --> D

## Linux डिस्ट्रोस OpenSSH को क्यों संशोधित करते हैं?
संक्षिप्त उत्तर यह है कि उन्हें करना पड़ता है। OpenSSH को
OpenBSD समुदाय द्वारा, OpenBSD समुदाय के लिए विकसित किया जाता है, और वे Linux की
बिल्कुल भी परवाह नहीं करते। [Portable OpenSSH][mindrot] प्रोजेक्ट
पैचों का एक best-effort संग्रह है जो OpenBSD-विशिष्ट
घटकों को सामान्य POSIX घटकों से बदल देता है, और जहाँ लागू हो वहाँ कुछ
प्लेटफ़ॉर्म-विशिष्ट कोड भी जोड़ता है। SSH की सॉफ़्टवेयर आपूर्ति-श्रृंखला
व्यवहार में कुछ इस तरह दिखती है:```mermaid
flowchart TD
  subgraph OpenBSD Folks
    A[OpenBSD]
    B[OpenSSH]
    H[improvements]
  end
  B-->A
  A-->H
  H-->B

  B-->C
  C[Portable OpenSSH]

  subgraph Debian Folks
    D[Debian SSH]
    G[improvements]
  end
  C-->D
  D-->G
  G-->C

  subgraph Fedora Folks
    J[Fedora SSH]
    K[improvements]
  end
  C-->J
  J-->K
  K-->C

OpenBSD का OpenSSH संस्करण बाकी सब चीज़ों का upstream है, और इसमें अधिकांश सुधार OpenBSD समुदाय के भीतर से आते हैं। ये बदलाव downstream में Portable OpenSSH प्रोजेक्ट तक पहुँचते हैं, जो नई सुविधाओं को OpenBSD-विशिष्ट न होने वाले तरीकों से फिर से लागू करने का प्रयास करता है। यही कारण है कि SSH Linux, macOS, FreeBSD, और यहाँ तक कि Windows जैसे प्लेटफ़ॉर्म पर काम कर पाता है।

लेकिन यह यहीं ख़त्म नहीं होता। कुछ ऑपरेटिंग सिस्टम Portable OpenSSH जो प्रदान करता है उससे आगे जाकर और अनुकूलन लागू करते हैं। उदाहरण के लिए, Apple ssh-add में [--apple-use-keychain][keith] फ़्लैग जोड़ता है ताकि यह macOS पासवर्ड मैनेजर के साथ एकीकृत हो सके।

CVE-2024-3094 के मामले में, Fedora और Debian ने [sshd पुनःआरंभ से जुड़ी race condition][schmidt] को ठीक करने के लिए अपने OpenSSH फ़ोर्क्स के लिए अपने स्वयं के [SystemD पैच][biebl] बनाए रखे। तो SSH की वास्तविक supply chain इस तरह दिखने लगी:```mermaid flowchart TD A[OpenSSH] B[Portable OpenSSH] C[Debian SSH] D[Fedora SSH] A-->B B-->C B-->D C<-->|SystemD Patches|D

ये पैच कभी Portable OpenSSH में नहीं गए, क्योंकि Portable
OpenSSH वालों की ["libsystemd पर निर्भरता लेने में कोई रुचि नहीं थी"][djmdjm]। और ये कभी upstream OpenSSH में भी नहीं गए, क्योंकि
OpenBSD को SystemD का समर्थन करने की कोई आवश्यकता नहीं है।



### "Separation of Concerns" के बारे में चिंताएँ
यह काफी हानिरहित लगता है, लेकिन यह Open Source में, विशेष रूप से Linux में, एक बहुत बड़ी समस्या का उदाहरण है: ऑपरेटिंग सिस्टम के महत्वपूर्ण घटक उन लोगों द्वारा विकसित किए जाते हैं जो एक-दूसरे को नहीं जानते, और एक-दूसरे से बात नहीं करते।

* क्या SystemD के लिए OpenSSH को पैच करने वाले लोग जानते थे (या परवाह करते थे) कि libsystemd xz-utils पर निर्भर करता है?
* क्या SystemD वाले लोग जानते थे (या परवाह करते थे) कि xz-utils ने ifunc का उपयोग करना शुरू कर दिया था?
* क्या OpenSSH वाले लोग जानते थे (या परवाह करते थे) कि ifunc एक चीज़ है? OpenBSD पर यह निश्चित रूप से कोई चीज़ नहीं है।