CHARON

  ____  _   _    _    ____   ___  _   _
 / ___|| | | |  / \  |  _ \ / _ \| \ | |
| |    | |_| | / _ \ | |_) | | | |  \| |
| |___ |  _  |/ ___ \|  _ <| |_| | |\  |
 \____||_| |_/_/   \_\_| \_\\___/|_| \_|

  फ़ेरी fds को exit-mm() Styx के पार ले जाता है
  CVE-2026-46333  /  Linux <= 6.12.89

"जीवित परमेश्वर के हाथों में पड़ना भयानक है।" — इब्रानियों 10:31

यह क्या है

CVE-2026-46333 के लिए एक कड़ा, बिना-निर्भरता वाला PoC: __ptrace_may_access mm==NULL बाईपास, जिसे Qualys ने 2026-05-15 को खोजा था। Charon pidfd_getfd(2) को एक मरते हुए SUID-root प्रक्रिया के विरुद्ध दौड़ाता है ताकि वह do_exit() में संक्षिप्त mm-NULL विंडो के माध्यम से अपने खुले /etc/shadow फ़ाइल डिस्क्रिप्टर को उठा सके। इसे प्रभावित मशीन पर एक अविशेषाधिकार प्राप्त उपयोगकर्ता के रूप में चलाएँ; यह /etc/shadow को stdout पर डंप करता है।

$ ./charon
[banner on stderr]
[*] lure /usr/bin/chage   target /etc/shadow
root:$y$j9T$ztS5H...$hz9W87TlqxEW...:...
daemon:*:20582:0:99999:7:::
bin:*:20582:0:99999:7:::
...

सामान्य हिट दर: 4-कोर VM पर एक सेकंड से कम, स्मोक टेस्ट में ~137 प्रयास।

बग, 30 सेकंड में

__ptrace_may_access() अपनी डंपेबिलिटी जांच को तब छोटा कर देता है जब task->mm == NULL होता है। फास्ट-पथ कर्नेल थ्रेड्स (स्वैपर आदि) के लिए लिखा गया था, जिनके पास वैध रूप से कोई mm नहीं है और कभी भी ptrace नहीं किया जाना चाहिए। लेकिन do_exit() exit_files() से पहले exit_mm() चलाता है, जिसका अर्थ है कि एक यूज़रस्पेस SUID प्रक्रिया के पास संक्षिप्त रूप से:

• task->mm == NULL (mm पुनः प्राप्त) → डंपेबिलिटी जांच छोड़ी गई
• फ़ाइल तालिका अभी भी भरी हुई है → fds अभी भी प्राप्त किए जा सकते हैं
• क्रेड्स post-setreuid() ड्रॉप को दर्शाते हैं → पहुँच जांच पास होती है

pidfd_getfd(2) उस पहुँच जांच पर भरोसा करता है और हमलावर को SUID प्रक्रिया के खुले फ़ाइल डिस्क्रिप्टर दे देता है।

do_exit()
  ├── exit_mm()      ← task->mm = NULL
  ├── ...            ← __ptrace_may_access() अब झूठ बोलता है
  └── exit_files()   ← fd तालिका पुनः प्राप्त

Jann Horn ने अक्टूबर 2020 में lore.kernel.org पर FD-चोरी के आकार को फ़्लैग किया था। यह फिक्स लगभग 6 वर्षों तक मेंटेनर समीक्षा में पड़ा रहा इससे पहले कि Qualys इसे फिर से कतार के सामने लाया।

अपस्ट्रीम फिक्स: 31e62c2ebbfd (Linus 2026-05-14)। 2026-05-15 तक बैकपोर्ट linux-6.12.y या linux-6.6.y स्थिर में नहीं उतरा है।

प्रभावित कर्नेल

स्थिर ट्री	स्थिति
linux-6.12.y (≤ 6.12.89)	❌ असुरक्षित
linux-6.6.y (फिक्स बैकपोर्ट से पहले)	❌ असुरक्षित
mainline ≥ 6.15-rc1	✅ पैच किया गया (31e62c2ebbfd)

डिस्ट्रो	कर्नेल	स्थिति (2026-05-15)
Debian trixie	6.12.86+deb13	❌
AlmaLinux 10.1	6.12.0-124.55.3	❌
Ubuntu 26.04	7.0.0-15	⚠️ जाँचें
Fedora 44	7.0.4-200	⚠️ जाँचें

जैसे-जैसे बैकपोर्ट उतरेंगे, PR / रोलिंग-स्थिति तालिका अद्यतन की जाएगी।

बिल्ड

# छोटा 38 KB स्थिर बाइनरी (अनुशंसित)
sudo apt-get install musl-tools
make static

# या केवल मानक glibc बिल्ड
make

आउटपुट: एक एकल ELF ./charon।

चलाएँ

./charon                     # /etc/shadow डंप करें (डिफ़ॉल्ट)
./charon -q                  # कोई बैनर / प्रगति नहीं, केवल shadow stdout पर
./charon -v                  # प्रति-हिट + अंतिम आँकड़े दिखाएँ
./charon -r 5000             # धीमी प्रणालियों के लिए अधिक धैर्य
./charon -t /etc/ssh/ssh_host_ecdsa_key   # अलग लक्ष्य (ssh-keysign बैट का उपयोग करता है)
./charon -a                  # यदि अंतर्निहित चूक जाते हैं तो SUID/SGID बैट्स स्वतः खोजें
./charon -L                  # बिना प्रयास किए उम्मीदवार बैट्स सूचीबद्ध करें
./charon --help

स्वतः-खोज

--auto /usr/bin, /usr/sbin, /usr/local/{bin,sbin}, /usr/lib/openssh, /usr/libexec, /bin, /sbin में चलता है, हर SUID/SGID नियमित फ़ाइल (इंटरैक्टिव बैट्स जैसे su, sudo, newgrp, pkexec को छोड़कर) ढूँढता है, और प्रत्येक को अनुरोधित लक्ष्य के विरुद्ध बैट के रूप में आज़माता है। प्रति-बैट बजट तंग है (5 राउंड × 2000 आंतरिक) इसलिए एक पूर्ण स्कैन ~10 सेकंड में समाप्त होता है, भले ही कुछ मेल न खाए।

--list-baits केवल-पढ़ने का संस्करण है — यह शोषण को चलाए बिना समान उम्मीदवारों की गणना करता है। यह सर्वेक्षण करने के लिए उपयोगी है कि कौन से डिस्ट्रो कौन से बैट भेजते हैं।

एग्ज़िट कोड

कोड	अर्थ
0	सफलता — फ़ाइल सामग्री stdout पर
1	इस सिस्टम पर कोई SUID ल्यूर अनुरोधित फ़ाइल नहीं खोलता
2	कर्नेल पैच किया हुआ प्रतीत होता है (CVE-2026-46333 बंद)
3	बिना हिट के राउंड समाप्त (दुर्लभ; -r 5000 आज़माएँ)
4	CLI / IO त्रुटि

ल्यूर

Charon चार ज्ञात SUID ल्यूर के साथ आता है:

बाइनरी	यह फ़ाइल खोलता है	डिस्ट्रो कवरेज
/usr/bin/chage (chage -l <user>)	/etc/shadow	अधिकांश Debian, Ubuntu, Fedora
/usr/sbin/chage	/etc/shadow	RHEL / Rocky / Alma परिवार
/usr/bin/passwd (passwd -S <user>)	/etc/shadow	अधिकांश डिस्ट्रो
/usr/lib/openssh/ssh-keysign	/etc/ssh/ssh_host_*_key	HostbasedAuthentication सक्षम वाले डिस्ट्रो

एक ल्यूर जोड़ना charon.c में lures[] सरणी में 3-पंक्ति का संपादन है।

शमन जब तक आपका डिस्ट्रो बैकपोर्ट नहीं भेजता

• सीधे 31e62c2ebbfd लागू करें।
• उत्पादन होस्ट पर seccomp के माध्यम से pidfd_getfd(2) अक्षम करें।
• chage और passwd से setuid बिट हटाएँ यदि आपको अविशेषाधिकार प्राप्त उपयोगकर्ताओं को पासवर्ड एजिंग पूछने की आवश्यकता नहीं है।
• कंटेनरीकृत वर्कलोड के लिए, होस्ट पर no_new_privs सक्षम करना पूरी तरह से आदिम को अवरुद्ध करता है — कंटेनर के अंदर हर "SUID" निष्क्रिय हो जाता है, जिससे Charon के पास कोई शिकार नहीं बचता।

कर्नेलCTF VRP उम्मीदवार नहीं

Google kernelctf VRP चैलेंज VM प्लेयर के bash को एक nsjail सैंडबॉक्स में clone_newuser:true (uid 0 अनमैप्ड), chroot:/chroot, और no_new_privs:1 के साथ चलाता है। no_new_privs के तहत setuid बिट निष्क्रिय है, इसलिए सैंडबॉक्स के अंदर कोई वास्तविक SUID शिकार नहीं है, और /flag chroot के बाहर होस्ट पर रहता है। इसलिए Charon kCTF VRP नहीं जीत सकता। यह बेयर-मेटल Debian / Ubuntu / RHEL परिवार स्थापनाओं पर एक वैध Linux LPE बना हुआ है।

उत्पत्ति

• बग की खोज और खुलासा Qualys → oss-security 2026-05-15.
• @0xdeadbeefnetwork द्वारा संदर्भ PoCs.
• Charon ल्यूर-एंड-रेस लूप को एक एकल कठोर बाइनरी में फिर से लिखता है, CLI एर्गोनॉमिक्स, पैच किए गए कर्नेल स्वचालित पहचान, और प्रति-डिस्ट्रो ल्यूर फ़ॉलबैक जोड़ता है।

लाइसेंस

केवल शैक्षिक और अधिकृत-रक्षात्मक उपयोग।

                        ⛵ STYX ⛵
              ╔══════════════════════════════╗
              ║  do_exit():                  ║
              ║   ├── exit_mm()   ← task->mm ║
              ║   │                = NULL    ║
              ║   ├── ...      ←  फ़ेरी     ║
              ║   └── exit_files()           ║
              ╚══════════════════════════════╝