ssh-keysign-pwn - Linux 0-day के लिए PoC, जिससे बिना विशेषाधिकार वाला उपयोगकर्ता root-स्वामित्व वाली फाइलें पढ़ सकता है

• ssh-keysign-pwn एक Linux vulnerability PoC है जो बिना विशेषाधिकार वाले उपयोगकर्ता को root-स्वामित्व वाली फाइलें पढ़ने देता है, और बताता है कि 31e62c2ebbfd से पहले के kernel इसके दायरे में आते हैं
• मुख्य bug यह है कि __ptrace_may_access() में task->mm == NULL होने पर dumpable जाँच छोड़ दी जाती है, और do_exit() में exit_mm() को exit_files() से पहले चलाया जाता है, जिससे file descriptor खुले रहने की एक window बनती है
• इस window में अगर caller का uid target process से मेल खाता है, तो pidfd_getfd(2) सफल हो जाता है, जिससे समाप्त हो रही process के खुले file descriptor हासिल किए जा सकते हैं
• sshkeysign_pwn /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key हासिल करता है, और उस flow का उपयोग करता है जिसमें ssh-keysign.c 0600 permission वाली keys खोलने के बाद permanently_set_uid() से पहले EnableSSHKeysign=no के कारण exit हो जाता है और खुला fd पीछे छूट जाता है
• chage_pwn /etc/shadow हासिल करता है, और उस flow में exit race को निशाना बनाता है जिसमें chage -l <user> spw_open(O_RDONLY) के बाद setreuid(ruid, ruid) से विशेषाधिकार पूरी तरह छोड़ देता है
• इसे चलाने का तरीका make के बाद ./sshkeysign_pwn से host keys, और ./chage_pwn root से /etc/shadow की सामग्री standard output पर प्रिंट करना है; इसमें बताया गया है कि 100~2000 spawns के भीतर hit मिल जाता है
• सत्यापित environment हैं Raspberry Pi OS Bookworm 6.12.75, Debian 13, Ubuntu 22.04 / 24.04 / 26.04, Arch, और CentOS 9
• नियंत्रित target PoC के रूप में vuln_target.c /etc/shadow खोलने के बाद privileges छोड़ता है, और exploit_vuln_target.c process के जीवित रहते EPERM तथा SIGKILL के बाद fd hijack दिखाता है
• vulnerability Qualys ने report की थी और Linus ने 2026-05-14 को इसे fix किया; साथ ही बताया गया है कि Jann Horn ने 2020 के अक्टूबर में FD hijack के इस रूप की ओर संकेत किया था
• README NVD entry के रूप में https://nvd.nist.gov/vuln/detail/CVE-2026-46333 प्रस्तुत करता है

[GN⁺]

Lobste.rs की राय

• सिर्फ ptrace को disable करना काफ़ी नहीं है। commit message और function name की वजह से गलतफ़हमी हो सकती है, लेकिन ptrace_may_access कई paths में call होता है और यह proof of concept (PoC) भी असल में ptrace का इस्तेमाल नहीं करता
  mitigation के लिए बहुत अच्छे विकल्प नहीं दिखते, और फिलहाल 1) सिर्फ इस खास PoC के खिलाफ़ कमज़ोर-सा बचाव करने के लिए /usr/lib64/misc/ssh-keysign से execute bit पूरी तरह हटाना, या 2) eBPF या systemtap जैसी किसी चीज़ से pidfd_getfd block करना, इतना ही संभव लगता है। पहला तरीका बस तब सोचने लायक है जब आप kernel patch नहीं कर सकते या system बंद नहीं कर सकते और अभी तुरंत सोना है
  मैंने PoC की समीक्षा नहीं की है, और इंटरनेट से मिले किसी भी random PoC को चलाने में हमेशा की तरह सावधानी ज़रूरी है
  Qualys advisory अभी सार्वजनिक नहीं हुई है, और Linux kernel security policy की वजह से उन्होंने linux-distros distribution को बहुत खेद के साथ बंद करने की बात कही थी। अब LLM संदिग्ध दिखने वाले fix commit से बहुत तेज़ी से PoC तक बना सकते हैं, इसलिए हालात और खराब हो गए हैं; पहले शायद कुछ दिन इंतज़ार करना संभव होता
  Qualys वाकई एक शानदार टीम है, इसलिए अफ़सोस है कि उन्हें इस बार इसे ठीक से खुद announce करने का मौका नहीं मिला। सार्वजनिक होने पर advisory निश्चित ही बेहतरीन होगी
  openssh इस हमले के लिए सिर्फ़ एक सुविधाजनक target है, गलती उसकी नहीं है; दूसरे setuid binaries को भी target बनाया जा सकता है

  • Qualys update के मुताबिक अगर /proc/sys/kernel/yama/ptrace_scope को 2(admin-only attach) या 3(no attach) पर set किया जाए तो सभी ज्ञात exploits रुक जाते हैं। हालांकि सैद्धांतिक रूप से exploit के दूसरे तरीके हो सकते हैं
  • एक तेज़ mitigation के तौर पर मैंने LLM Opus से pidfd_getfd को block करने वाली systemtap script लिखवाई, और नतीजा यहाँ है। इसे stap -g block_pidfd_getfd.stp के साथ चलाना होगा, और इंटरनेट से मिली हर चीज़ की तरह script को चलाने से पहले ज़रूर review करें
  • क्या linux-distros announcement का कोई link है? मुझे नहीं मिल रहा

• काश kernel main branch में fix को public commit करके खुद 0-day public करना बंद करे। commit में “Reported-by: Qualys” तक लिखा है, इसलिए साफ़ है कि यह security fix है

  • पिछले हफ़्ते इस मुद्दे पर बड़ी बहस हुई थी
    Greg K-H ने लिखा था कि kernel security team security fixes के pre-disclosure recipients चुन नहीं सकती, इसलिए नतीजतन किसी को भी pre-disclosure नहीं मिलता
  • तो फिर इसकी जगह क्या करना चाहिए?

• यह ssh की नहीं बल्कि Linux की समस्या है। शीर्षक में भी यह दिखना चाहिए

  • मैं मानता हूँ कि शीर्षक भ्रमित कर रहा है, लेकिन इसे क्या नाम दूँ, इसका कोई बेहतर विचार मेरे पास नहीं था। अभी बदल सकता हूँ, तो सुझाव अच्छे रहेंगे
  • सही, लेकिन साथ ही अगर ssh-keysign private host key खोलने से पहले EnableSSHKeysign=yes को check करता, तो जिन systems पर यह option default की तरह बंद है वे host key theft के प्रति vulnerable नहीं होते। यह चौंकाने वाला है कि ssh-keysign सबसे पहले यही option check नहीं करता

• proof of concept सुखद रूप से छोटा है, और मेरी machines भी वास्तव में vulnerable थीं
  लगता है कि कुछ conditions में यह setuid executable द्वारा खोले गए file descriptors तक पहुँच दे देता है। यह सिर्फ़ पढ़ने तक सीमित क्यों होगा, समझ नहीं आता, और लगता है कि इसे hash crack किए बिना local privilege escalation (LPE) में बदला जा सकता है
  कम से कम इस PoC को chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage से तोड़ा जा सकता है। ssh-keysign का path बदलना पड़ सकता है और manual page भी देखी जा सकती है। लेकिन इससे मूल समस्या ठीक नहीं होती, और bypass भी संभव लगता है। जहाँ तक मुझे पता है, दूसरी mitigation नहीं है
  यह समस्या ptrace: slightly saner 'get_dumpable()' logic में fix की गई, और इसी वजह से सार्वजनिक हो गई। यह बस 10 घंटे पहले की बात है
  oss-security पर Qualys की public announcement भी है। उनका कहना है कि distributions और users को patch करने का समय देने के लिए advisory अभी सार्वजनिक नहीं की जा रही। यह काफ़ी दिलचस्प लगती है, और तब तक grsecurity के Brad Spengler की व्याख्या देखी जा सकती है। लगता है इसी tweet ने इस PoC development को trigger किया

  • मैंने PoC चलाकर देखा, लेकिन race नहीं जीत पाया। इसके बजाय exploit_vuln_target/vuln_target जोड़ी ने ठीक काम किया। यह अच्छी बात नहीं है

• व्यवहारिक रूप से यह उन systems को प्रभावित करता दिखता है जहाँ किसी user के पास पहले से unprivileged account है। यानी अगर valid login नहीं है, तो SSH internet-exposed server पर इससे सीधे remote code execution हासिल नहीं किया जा सकता, सही?

  • सही। लेकिन कुछ दिन पहले आए nginx remote code execution जैसे मामलों में, अगर किसी दूसरी service के ज़रिए RCE मिल जाए तो बात अलग है