Linux kernel की vulnerabilities के लिए distributions को पहले से सूचना नहीं मिलती

• Linux kernel की local privilege escalation vulnerability CopyFail हाल के kernel के “make-me-root” (यानी सामान्य user को root बना देने वाली) vulnerabilities में सबसे गंभीर श्रेणी में आती है
• यह vulnerability kernel version 4.14 के एक specific commit में introduce हुई थी, और यह उस समय से मेल खाती है जब CopyFail में इस्तेमाल किए गए authencesn module में in-place optimization जोड़ी गई थी
• इसका fix kernel 6.18.22, 6.19.12, 7.0 में शामिल किया गया, और 6.18.22 व 6.19.12 को 11 अप्रैल को fix backport (ऊपरी version के patch को निचले version पर लागू करना) के साथ release किया गया
• लेकिन अब भी व्यापक रूप से इस्तेमाल होने वाले Longterm kernel (6.12, 6.6, 6.1, 5.15, 5.10) में यह fix शामिल नहीं है, और upstream stable queue में भी इसकी पुष्टि नहीं हुई है
  • चूंकि यह समस्या 2017 में introduce हुई थी, इसलिए यह जांचना ज़रूरी है कि ये पुराने Longterm kernel भी इससे प्रभावित हैं या नहीं
• संबंधित fix patch पुराने kernel पर clean apply (यानी code conflict के बिना साफ़ तौर पर लागू) नहीं होता, और कुछ API बदलावों की वजह से backport की कोशिश भी भरोसे के साथ करना मुश्किल है
• जिन environments में तुरंत कार्रवाई की ज़रूरत है, वहां अस्थायी उपाय के रूप में IPSec के authencesn module को disable करने वाला patch लागू किया जा सकता है; IPSec expert न होने पर भी इसे “perfect नहीं, लेकिन कम बुरा विकल्प” कहा जा सकता है
• यानी संरचनात्मक समस्या Linux kernel vulnerability disclosure process में ही है:
  • Linux kernel vulnerabilities में, जब तक vulnerability reporter खुद linux-distros mailing list (distribution security teams का private channel) पर सूचना न दे, तब तक अलग-अलग distributions को पहले से चेतावनी नहीं मिलती
  • इस CopyFail मामले में भी linux-distros ML के जरिए पहले से heads-up नहीं दिया गया था
  • यानी Ubuntu·RHEL·SUSE जैसे प्रमुख distributions की security teams को vulnerability public होने से पहले patch तैयार करने का मौका नहीं मिला

[unsure4000]

ब्लॉग पोस्ट थोड़ी बचकानी है, लेकिन मुझे लगता है कि इसे सिर्फ नापसंद किए जाने से बढ़कर गलती मानने के बजाय, सिस्टम स्तर की खामी कहीं ज़्यादा बड़ी लगती है।

[GN⁺]

Hacker News की राय

• लिंक किए गए लेख के लेखक Sam James Gentoo डेवलपर हैं
  जो भी हो, यह लगभग एक आपदा जैसा था, और distros के fix जारी करने से पहले exploit सार्वजनिक करना बेहद गैर-जिम्मेदाराना था
  इससे कितने shared hosting प्रदाता hack हुए होंगे, यह कहना मुश्किल है
  यह भी चिंता की बात है कि kernel security team और distro maintainer के बीच कोई संचार नहीं दिखता
  सहज रूप से लगता है कि पहला समूह दूसरे को सूचित करेगा, लेकिन वास्तव में संरचना ऐसी दिखती है कि vulnerability खोजने वाले पर ही ज़िम्मेदारी डाल दी जाती है

  • रिपोर्ट किए गए पक्ष में patch शामिल होने के 30 दिन बाद सार्वजनिक करना अपने-आप में मुझे गलत नहीं लगता
    संदर्भ के लिए, Google Project Zero भी इसी तरह की “90+30” नीति इस्तेमाल करता है: https://projectzero.google/vulnerability-disclosure-policy.h...
    असली समस्या यह है कि kernel security team और distro maintainer के बीच कोई संचार चैनल नहीं है
    vulnerability खोजने वाले पर हर downstream को अलग-अलग रिपोर्ट करने की ज़िम्मेदारी नहीं होनी चाहिए
    kernel टीम को distro security contacts की सूची पर patch की गंभीरता और 30 दिन बाद होने वाले disclosure schedule की सूचना देनी चाहिए थी
  • इस बार का disclosure सुरक्षा से ज़्यादा marketing जैसा था
    disclosure पेज पर “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, “[Try Xint Code]” जैसे वाक्य भी थे
    जितना ज़्यादा भ्रम फैले, उत्पाद उतना आकर्षक दिखे—ऐसा तरीका लग रहा था
  • एक user और admin के रूप में मैं “बेहद गैर-जिम्मेदाराना” वाली बात से सहमत नहीं हूँ
    Responsible Disclosure जैसा शब्द “Secure Boot” की तरह भाषाई रूप से बहुत सोच-समझकर गढ़ा गया लगता है, और व्यवहार में यह मेरे कंप्यूटर और मेरे बीच मौजूद corporate/foundation मध्यस्थ संस्थाओं की प्रतिष्ठा-रक्षा जैसा दिखता है
    उन्हें इस बात से ज़्यादा मतलब है कि “RHEL vulnerable है”, “Ubuntu vulnerable है” जैसी बात न कही जाए, बजाय इसके कि मेरा व्यक्तिगत कंप्यूटर vulnerable है या नहीं
    vulnerability तो वैसे भी मौजूद रहती है, इसलिए चुपचाप fix का इंतज़ार करने के बजाय जोखिम जानकर उसे कम करने का मौका होना बेहतर है
    मेरे हिसाब से तुरंत disclosure ही एकमात्र ऐसा विकल्प है जिसे गैर-जिम्मेदाराना नहीं कहा जा सकता
  • disclosure प्रक्रिया पर रुख जो भी हो, अगर कोई hosting provider इससे hack हुआ, तो वह पहले से ही हारने वाली संरचना में था
    एक-दूसरे पर भरोसा न करने वाले tenant workloads को एक shared kernel के नीचे चलाना ठीक नहीं है
    Kernel LPE कोई दुर्लभ बात नहीं है, और यह मामला बस खास तौर पर सरल और portable था; इसकी मूल capability लगभग CNE commodity जैसी है
  • Linux kernel सुरक्षा सीमा के रूप में इस्तेमाल करने के लिए उपयुक्त नहीं है
    अगर shared hosting करनी है और hack नहीं होना है, तो gVisor या Firecracker VM जैसे दूसरे साधन इस्तेमाल करने चाहिए
    इसे security boundary की तरह इस्तेमाल करने वाला महत्वपूर्ण सिस्टम शायद Android है, जहाँ APK install के लिए user approval, सख्त SELinux और seccomp policies, और GrapheneOS hardening जैसी mitigations मौजूद हैं
    इस मामले में mitigation सफल भी रही: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...

• मुझे समझ नहीं आता कि लोग ऐसा क्यों कहते हैं कि “Linux kernel vulnerability के मामले में, जब तक reporter उसे सीधे linux-distros ML में न ले जाए, distros को पहले से सूचना नहीं मिलती”
  reporter से यह अपेक्षा करना कि वह distros के साथ सीधे समन्वय करे, Linux project के बारे में बहुत ऊँचे स्तर की जानकारी मानकर चलता है
  vulnerability submit करने वाले पर Linux kernel के हर downstream consumer के साथ सीधे काम करने की ज़िम्मेदारी नहीं होनी चाहिए
  अगर ऐसा है, तो क्या Linux को अपने उपकरणों में इस्तेमाल करने वाले हर manufacturer से भी सीधे संपर्क करना चाहिए?
  मेरे हिसाब से reporter ने Linux को जिम्मेदारी से रिपोर्ट करके और patch शामिल होने तक इंतज़ार करके अपनी ओर से पर्याप्त किया
  Linux project के भीतर ऐसे लोग होने चाहिए जिनके पास security vulnerability को लेकर अधिकार और ज़िम्मेदारी हो, और downstream distro को सूचित करने का काम भी उन्हें ही करना चाहिए

  • यह बात इसलिए और भी सही लगती है क्योंकि reporter से distro टीमों को पहले सूचित न करने का स्पष्ट अनुरोध किया जाता है
    https://docs.kernel.org/process/security-bugs.html
    As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
  • reporter के पास अपनी वेबसाइट पर Ubuntu/RHEL/SUSE जैसे खास distros की जाँच करके उनका उल्लेख करने का समय था
    कम-से-कम उन distros की security teams को सूचित करना जिम्मेदाराना व्यवहार होता
  • reporter ने Ubuntu, RedHat, Amazon, SUSE को स्पष्ट रूप से नाम लेकर वेबसाइट बनाई, फिर भी उन्हें सूचित नहीं किया—इसे उचित कहना मुश्किल है
    ऐसा भी नहीं लगता कि उन्हें पता न हो कि वे distros kernel टीम के downstream हैं
  • यह शायद अनिवार्य शर्त न हो, लेकिन मुझे लगता है कि reporter safe remediation से ज़्यादा प्रसिद्धि में रुचि रखते थे, और इसी वजह से सबको ज़्यादा नुकसान उठाना पड़ा
  • Linux distro को ऐसे security issue की रिपोर्ट कैसे करें, यह ढूँढना बहुत आसान है
    Google search से भी मिल जाता है: https://share.google/aimode/eihDKXZJy94Z5lC1p
    इसके बारे में सोचे बिना सबको exploit के सामने खुला छोड़ देना समझना मुश्किल है, और कुछ jurisdictions में यह गंभीर अपराध माना जाए तो भी आश्चर्य नहीं होगा

• disclosure से जुड़ा सबसे दिलचस्प आदान-प्रदान इस लिंक में है
  https://www.openwall.com/lists/oss-security/2026/05/01/3
  greg k-h का जवाब है: “हम किसी को भी पहले से नहीं बता सकते। क्योंकि तब हमें हर चीज़ के बारे में सबको बताना पड़ेगा। कानूनी और सरकारी एजेंसियों ने हमारे संचालन के लिए केवल इसी नीति पर सहमति दी है, इसलिए हम मजबूर हैं।”

  • मुझे Linux पसंद है, लेकिन यह नीति मूर्खतापूर्ण लगती है

• reporter को दोष देना बंद कर kernel process को ठीक करने की माँग करनी चाहिए
  Linux kernel अब कोई खिलौना परियोजना नहीं है, और इसमें कई कंपनियों द्वारा नियुक्त full-time कर्मचारी हैं
  distros को सूचित करने का काम किसी रैंडम व्यक्ति के बजाय उन्हीं को करना चाहिए था

  • अगर किसी घोषणा-उन्मुख, वस्तुतः marketing ब्लॉग पोस्ट में खास distros को affected कहकर नाम लिया गया था, तो disclosure से पहले heads-up देना उचित और अपेक्षित व्यवहार था
    अगर RHEL 14 जैसी बातें वहाँ न लिखी गई होतीं, तो शायद इतनी आलोचना भी न होती
    यह कोई व्यक्तिगत security researcher या academic स्थिति नहीं थी, बल्कि professional communications विभाग वाली एक security company ने distro maintainer की ओर उंगली उठाई थी
  • distros और kernel developers को high severity patches पर संवाद करके जल्दी कार्रवाई करनी चाहिए, यह सही है
    लेकिन reporter ने उस प्रक्रिया के होने का इंतज़ार नहीं किया, इसलिए असली लोगों को नुकसान हुआ हो सकता है, और उसकी ज़िम्मेदारी reporter पर है
  • vulnerability की रिपोर्ट करना और ऐसा शक्तिशाली exploit प्रकाशित करना जिसे कोई भी उठाकर इस्तेमाल कर सके, ये पूरी तरह अलग बातें हैं
    प्रमुख distros को पहले से सूचित किए बिना उसे दुनिया के सामने छोड़ देना गैर-जिम्मेदाराना था

• जिन लोगों का kernel AF_ALG को module की जगह सीधे kernel में link करता है, उनके लिए एक eBPF आधारित workaround पोस्ट किया गया है: https://github.com/Dabbleam/CVE-2026-31431-mitigation
  मैं इसे अभी production में चला रहा हूँ, यह हमले को mitigate कर रहा है, और अब तक कोई अप्रत्याशित side effect नहीं दिखा है

• मेरे हिसाब से nosuid और शायद nodev default filesystem mount options होने चाहिए
  /dev तो पहले से ही एक विशेष devtmpfs है, और initrd का न्यूनतम /dev चाहिए हो तो initrd tmpfs rootfs को dev और suid के साथ स्पष्ट रूप से mount किया जा सकता है
  SUID binaries को कहीं भी “मौजूद” रहने देना बड़ा security risk है
  जब external storage mount किया जाए, तो उसमें मौजूद SUID binaries दुर्भावनापूर्ण नहीं हैं, इसे सत्यापित कैसे करेंगे?
  इसके अलावा, यह exploit तभी काम करता दिखता है जब SUID binary चलाने वाला user उस binary को पढ़ भी सकता हो
  non-root users के पास SUID binary पर read permission होने की कोई वजह नहीं है
  NixOS इसे सही तरीके से संभालता है
  सामान्य package install directory /nix/store में SUID नहीं होता, और क्योंकि packages उससे बाहर leak नहीं होते, दूसरे mountpoints पर सुरक्षित रूप से nosuid इस्तेमाल किया जा सकता है
  अपवाद केवल single-purpose /run/wrappers.$hash directory है, जिसमें सिर्फ सुरक्षित executable-only SUID wrappers रखे जाते हैं

  • मुझे भी suid पसंद नहीं है, लेकिन यहाँ suid मूल समस्या नहीं है
    exploit होने वाला bug दरअसल लगभग मनमाना page cache poisoning संभव बनाता है
    उस बिंदु तक पहुँचने के बाद खेल लगभग खत्म हो चुका होता है, और suid program को patch करना root shell पाने का सबसे आसान तरीका हो सकता है, लेकिन वह एकमात्र तरीका नहीं है
  • proof of concept exploit सचमुच सिर्फ एक attack vector दिखाने के लिए है
    और भी कई तरीके हैं
    अगर लक्ष्य सिर्फ proof-of-concept exploit को रोकना है, तो blacklist जैसे आसान तरीके भी हैं, लेकिन उससे चीज़ें अधिक सुरक्षित नहीं हो जातीं
    इस vulnerability से page cache में छेड़छाड़ की जा सकती है
    ld.so में बदलाव करके मनचाहे system calls पर hook लगाया जा सकता है, uid को 0 किया जा सकता है, या कई अन्य तरीकों से privilege escalation किया जा सकता है
    mount point का इस समस्या से कोई लेना-देना नहीं है
    हाँ, user-writable areas में suid को रोकना और suid files को पढ़ने से रोकना हमेशा अच्छा विचार है, लेकिन वह दूसरी वजहों से है
    NixOS भी इस vulnerability को ठीक नहीं करता और दूसरे distros की तरह ही vulnerable है
  • अगर read permission न हो, तो binary चल नहीं सकती, और यह बात समझ में आती है
    binary को चलाने के लिए उसे disk से पढ़कर memory में लोड करना पड़ता है
    वास्तव में अगर किसी खास binary पर read permission हो लेकिन executable permission न हो, तो linker को सीधे बुलाकर उसे चलाया भी जा सकता है
    उदाहरण के लिए, /bin/ld.so.1 /path/to/binary की तरह चलाने पर linker binary को पढ़कर लोड करता है और exec() call के बिना entry point पर jump कर जाता है

• नीचे दिए गए Bleeping Computer लिंक में patch तैयार होने तक के संभावित mitigations दिए गए हैं
  https://www.bleepingcomputer.com/news/security/new-linux-cop...

  • यह workaround केवल उन kernels पर लागू होता है जहाँ प्रभावित code module के रूप में compile किया गया हो
    RHEL, Fedora, Gentoo—तीनों इस code को सीधे kernel में build करने के लिए configured हैं
    patch या config change के बिना, जैसा Sam ने Gentoo के बारे में संकेत किया, ये distros vulnerable ही रहेंगे
  • RedHat और उसके derivative distros में प्रभावित code module नहीं बल्कि static रूप से compile किया गया है, इसलिए यह mitigation वहाँ काम नहीं करती

• NixOS को भी सूचना नहीं मिली थी
  https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...

  • किसी भी distro को सूचना नहीं मिली थी

• Hyperbola GNU राजनीतिक कारणों और स्थिरता की वजह से अभी भी Python 3.8 इस्तेमाल कर रहा था, इसलिए सुरक्षित रहा

• Ubuntu ने patch जारी कर दिया है, और patch से पहले और बाद—दोनों स्थितियों में testing भी पूरी हो चुकी है