page_inject - AF_ALG aead क्रॉस-कंटेनर एस्केप

AF_ALG aead भेद्यता क्रॉस-कंटेनर शोषण -- एक समझौता किए गए कंटेनर से उसी libc.so.6 इमेज लेयर को साझा करने वाले प्रत्येक सहोदर कंटेनर में घुसपैठ करना।

यह एक एस्केप प्रिमिटिव है: यह एक अविशेषाधिकार प्राप्त कंटेनर के अंदर से चलता है जिसे हमलावर पहले ही समझौता कर चुका है, और AF_ALG authencesn ESN-रोटेशन 4-बाइट आर्बिट्ररी-राइट बग (CVE-2026-31431) का उपयोग करके libc.so.6 के पेज-कैश पृष्ठों में एक स्थायी read() हुक लगाता है। क्योंकि Docker/containerd overlayfs की निचली परतों को साझा इनोड के साथ बैक करते हैं, वे पृष्ठ उसी इमेज से तत्कालित प्रत्येक सहोदर कंटेनर को दिखाई देते हैं -- हुक उनकी प्रक्रियाओं में भी सक्रिय हो जाता है, और हमलावर को प्रत्येक के अंदर कमांड निष्पादन मिल जाता है।

खतरा मॉडल

• हमलावर के पास एकल कंटेनर (इसे victim कहते हैं) तक शेल पहुंच है, जो उसी इमेज से victim के रूप में अन्य कंटेनर (siblings) चलाने वाले होस्ट पर होता है।
• victim डिफ़ॉल्ट Docker/k8s स्थिति के साथ चलता है: कंटेनर के उपयोगकर्ता नामस्थान के अंदर अविशेषाधिकार प्राप्त uid, डिफ़ॉल्ट seccomp प्रोफ़ाइल, डिफ़ॉल्ट AppArmor प्रोफ़ाइल, कोई विशेष क्षमता नहीं, कोई होस्ट बाइंड माउंट नहीं।
• victim के पास केवल:
  • अपने libc तक पढ़ने की पहुंच (/usr/lib/x86_64-linux-gnu/libc.so.6 या जहां भी डिस्ट्रो इसे स्थापित करता है)
  • मानक socket(AF_ALG, ...) सिस्कॉल परिवार
  • मानक splice / vmsplice सिस्कॉल
  • एक निर्देशिका तक लिखने की पहुंच जिसे वह chmod +x कर सकता है (जैसे /tmp)
• कर्नेल CVE-2026-31431 (अपस्ट्रीम रिवर्ट फिक्स से पहले कोई भी algif_aead + authencesn बिल्ड) के प्रति संवेदनशील होना चाहिए।

बस इतना ही। कोई विशेष CAP_* नहीं, कोई होस्ट फाइलसिस्टम पहुंच नहीं। हमलावर कंटेनर के अंदर एक स्व-निहित स्थैतिक रूप से लिंक किया गया बाइनरी ड्रॉप करता है, इसे चलाता है, और पेज-कैश भ्रष्टाचार -- और इसलिए हुक -- प्रत्येक सहोदर को दिखाई देने लगता है।

शोषण कैसे श्रृंखलाबद्ध होता है

1. पेज-कैश पृष्ठ पहचान। ओवरलेफ़्स कंटेनर के अंदर, /usr/lib/.../libc.so.6 निचली इमेज लेयर के ext4 इनोड द्वारा प्रदान किया जाता है। एक ही इमेज से शुरू किया गया प्रत्येक कंटेनर उस बैकिंग इनोड को साझा करता है, और कर्नेल का पेज कैच अंतर्निहित इनोड द्वारा कुंजीबद्ध होता है -- ओवरले या नामस्थान द्वारा नहीं। इसलिए पेज-कैश पृष्ठ में एकल 4-बाइट लेखन उन सभी सहोदर कंटेनरों की प्रक्रियाओं को दिखाई देता है जिनके पास वह पृष्ठ mmap'd है।

2. AF_ALG aead भेद्यता एक ऐसे लेखन को कई में बदल देती है। algif_aead उपयोगकर्ता RX iovec को spliced TX SGL के अनुगामी authsize बाइट्स के साथ जोड़ता है, और authencesn का ESN रोटेशन AAD के seq_high फ़ील्ड को dst[assoclen + cryptlen] पर रखता है -- जो उस जंजीरबद्ध विदेशी पूंछ का पहला बाइट है। Spliced पृष्ठ एक फ़ाइल का पेज-कैश पृष्ठ है जिस तक हमलावर के पास केवल पढ़ने की पहुंच है, लेकिन सिफर वैसे भी उसमें बाइट्स कॉपी करता है, बिना किसी गंदे बुककीपिंग के। (अंतर्निहित यांत्रिकी के लिए crypto/algif_aead.c और crypto/authencesn.c देखें।)

3. एक कॉल करने योग्य प्रिमिटिव को बूटस्ट्रैप करना। सबसे पहली चीज़ जो page_inject करता है वह Zone A को बूटस्ट्रैप करना है -- उसी AF_ALG डांस का एक asm-एन्कोडेड पुनर्कार्यान्वयन (write_cache.asm), जो libc के गुफा के अंदर रखा जाता है। यह 4-बाइट लेखन को किसी भी भविष्य के हुक पेलोड से एक नियमित बनाता है, बिना प्रति-कॉल सॉकेट सेटअप की आवश्यकता के।

बिल्डिंग

इंजेक्टर को पीड़ित कंटेनर के बाहर बनाया जाता है -- आमतौर पर हमलावर की अपनी डेवलपमेंट मशीन पर -- क्योंकि अधिकांश प्रोडक्शन कंटेनर इमेज कंपाइलर नहीं भेजती हैं। एक मानक Linux x86_64 डेव वातावरण जिसमें gcc (-static लिंक सपोर्ट के साथ) और nasm हो, पर्याप्त है।

make            # .asm स्रोतों को gen_arrays.sh के माध्यम से असेंबल करता है, स्थैतिक page_inject लिंक करता है
make shellcode  # निरीक्षणीय .bin फ्लैट बाइनरी भी उत्पन्न करता है
make clean      # उत्पन्न फ़ाइलों और बाइनरी को हटाता है

आउटपुट एक एकल स्थैतिक रूप से लिंक किया गया ELF (./page_inject) है जो किसी भी आधुनिक x86_64 Linux कर्नेल पर चलता है।

डिलीवरी और उपयोग (पीड़ित कंटेनर से)

एक बार जब हमलावर के पास victim पर शेल है, तो वे बाइनरी को एक लिखने योग्य निर्देशिका (आमतौर पर /tmp) में अपलोड करते हैं:

# समझौता किए गए कंटेनर के अंदर, हमलावर सत्र
victim$ ./page_inject

बिना तर्कों के, page_inject डिफ़ॉल्ट रूप से /usr/lib/x86_64-linux-gnu/libc.so.6 (मर्ज के बाद Debian/Ubuntu स्थान) का उपयोग करता है। अन्य डिस्ट्रो के लिए libc एक अलग पथ पर है; या तो इसे स्पष्ट रूप से पास करें या कंटेनर के रूट से अंतर्निहित लुकअप तालिका को स्कैन करने के लिए --root / का उपयोग करें:

# Fedora / Rocky / CentOS
victim$ ./page_inject /usr/lib64/libc.so.6

# Arch
victim$ ./page_inject /usr/lib/libc.so.6

# ऑटो-डिटेक्ट, डिस्ट्रो की परवाह किए बिना:
victim$ ./page_inject --root /

दोनों आह्वान एक ही काम करते हैं: कंटेनर के अंदर libc को ELF-पार्स करें, उसके पेज कैच में हुक स्थापित करें, सहोदर के पंजीकरण के दौरान ~30 सेकंड के लिए स्लॉट तालिका की निगरानी करें, और एक सैनिटी जांच के रूप में पंजीकृत होने वाले पहले सहोदर के खिलाफ एक एकल-शॉट id चलाएं।

बूटस्ट्रैप के बाद, किसी भी पंजीकृत सहोदर को चलाने के लिए कमांड शेल में प्रवेश करें:

victim$ ./page_inject --shell --no-bootstrap
=== page-cache shell ===
Containers (3):
  [0] 0x0018598d  <- target
  [1] 0x001859ab
  [2] 0x001859cd

inject:0018598d> exec id
uid=0(root) gid=0(root) groups=0(root)
inject:0018598d> target 0x001859ab
inject:001859ab> exec hostname
1ccd66abee9d
inject:001859ab> exec cat /etc/shadow
root:$6$.....
inject:001859ab> unhook
... read() prologue restored, slot table zeroed ...

unhook एक ही शॉट में प्रत्येक सहोदर कंटेनर से हुक को साफ करता है और हुक चाइल्ड को स्वयं समाप्त करने देता है।

Usage: page_inject [OPTIONS] [LIBC_PATH]

Options:
  --root <prefix>   अंतर्निहित निश्चित-पथ लुकअप तालिका का उपयोग करके
                    <prefix> के तहत libc.so.6 को स्वचालित रूप से हल करें।
                    पीड़ित कंटेनर के अंदर वह सामान्यतः --root / होता है।
  --shell [0xKEY]   इंजेक्शन के बाद इंटरैक्टिव कमांड शेल में प्रवेश करें।
                    वैकल्पिक KEY लक्ष्य को पूर्व-चुनता है।
  --no-bootstrap    इंजेक्शन छोड़ें (केवल शेल; हुक पहले से ही पेज कैश
                    में जीवित होना चाहिए)।
  --timeout SEC     --shell मोड में स्लॉट निगरानी टाइमआउट
                    (डिफ़ॉल्ट 30 सेकंड)।
  --help, -h        सहायता दिखाएँ।

डिफ़ॉल्ट libc (जब कोई --root और कोई LIBC_PATH नहीं दिया गया हो):
  /usr/lib/x86_64-linux-gnu/libc.so.6

दोहरा इंजेक्शन पथ

विभिन्न glibc बिल्ड निष्पादन योग्य LOAD सेगमेंट और अगले केवल-पढ़ने वाले LOAD के बीच .text गुफा स्थान की अलग-अलग मात्रा छोड़ते हैं। page_inject इंजेक्शन के समय दो लेआउट के बीच चयन करता है:

• पथ A -- केवल libc (डिफ़ॉल्ट)। Zone C और Zone A दोनों libc के .text गुफा में रहते हैं। स्लॉट तालिका + CMD + OUTPUT क्षेत्र libc के .hash अनुभाग में रहते हैं -- विरासत SysV हैश डेटा जिसे ld.so रनटाइम पर नहीं पढ़ता क्योंकि यह इसके बजाय .gnu.hash का उपयोग करता है। जब .hash अनुपस्थित होता है (Arch के आधुनिक टूलचेन), page_inject स्लॉट क्षेत्र को इसके बजाय .eh_frame_hdr के पूंछ से तराशता है, पहले fde_count फ़ील्ड को सिकोड़ता है ताकि अनवाइंडर अब मुक्त बाइट्स को FDE बाइनरी-सर्च इंडेक्स का हिस्सा नहीं मानता (अनवाइंडर पारदर्शी रूप से किसी भी IP के लिए .eh_frame के रैखिक स्कैन में गिर जाता है जिसका FDE छंटनी की गई श्रेणी में होता था -- LSB-अनिवार्य व्यवहार)।

• पथ B -- libc ट्रैम्पोलिन + ld.so पेलोड। कुछ glibc बिल्ड libc गुफा को पूर्ण Zone C + Zone A पेलोड के लिए आवश्यक आकार से नीचे सिकोड़ते हैं (Ubuntu 24.04 / glibc 2.39 एक 711 B गुफा भेजता है)। उस स्थिति में page_inject libc के गुफा में एक 36 B ट्रैम्पोलिन लिखता है -- यह फास्ट-पथ .bss-कुंजी गेट इंट्रा-libc करता है -- और धीमे पथ पर यह libc के GOT स्लॉट से _rtld_global (एक ld.so-पक्ष प्रतीक जिसे प्रत्येक glibc निजी रूप से आयात करता है) के लिए ld.so के रनटाइम बेस की गणना करता है और के गुफा में Zone C के बेस-रजिस्टर संस्करण में कूदता है। स्लॉट तालिका + CMD + OUTPUT + कुंजी सभी libc में रहते हैं; ld.so-पक्ष Zone C ट्रैम्पोलिन द्वारा को सीड करने के बाद के माध्यम से उन तक पहुँचता है।

यदि कोई भी लेआउट फ़िट नहीं होता है, तो page_inject डिस्क या पेज कैश में libc या ld.so में कुछ भी लिखे बिना साफ़ रूप से मना कर देता है।

read() प्रस्तावना संभालना

विभिन्न glibc संस्करण read() में अलग-अलग प्रारंभिक अनुक्रम उत्सर्जित करते हैं। इंजेक्टर प्रत्येक को पहचानता है, उन बाइट्स को वापस पढ़ता है जिन्हें हुक विस्थापित करता है, और उन्हें Zone C के फास्ट-पथ में अनुकरण करता है ताकि एकल-थ्रेडेड read() read+N पर सही ढंग से फिर से शुरू हो:

Zone C में फास्ट-पथ अनुकरण स्लॉट सबसे लंबी ज्ञात प्रस्तावना (8 बाइट्स) और 5-बाइट rel32 jmp के लिए आकारित है; छोटी प्रस्तावनाएँ अनुगामी स्लॉट बाइट को NOP फिलर से भरती हैं ताकि कुल स्लॉट लंबाई स्थिर रहे।

फ़ाइल लेआउट

page_inject/
  page_inject.c           मुख्य इंजेक्टर: ELF पार्सिंग, भेद्यता प्रिमिटिव,
                          डुअल-पथ लेआउट चयन, इंजेक्ट + अनहुक।
  zone_c.asm              पथ-A हुक डिस्पैचर शेलकोड।
  zone_c_ld.asm           पथ-B हुक डिस्पैचर (rbp-बेस संस्करण)।
  trampoline.asm          पथ-B 36-बाइट libc-पक्ष स्टब।
  write_cache.asm         Zone A (भेद्यता लेखन प्रिमिटिव शेलकोड)।
  gen_arrays.sh           .asm -> asm_bytecode.c असेंबल करें।
  asm_bytecode.c          [उत्पन्न] शेलकोड बाइट ऐरे।
  Makefile                बिल्ड सिस्टम।

परीक्षण और समर्थित मैट्रिक्स

शोषण को निम्नलिखित कंटेनर स्नैप डिस्ट्रो पर एंड-टू-एंड सत्यापित किया गया है। प्रत्येक प्रविष्टि में एक कंटेनर के अंदर से page_inject इंजेक्ट किया गया है और उसी इमेज से शुरू किए गए सहोदर कंटेनर में इसके हुक को फायर करते देखा गया है; पेज-कैश चैनल के माध्यम से कमांड सही ढंग से निष्पादित हुए; और अनहुक ने libc पृष्ठ स्थिति को साफ़ रूप से बहाल किया।

परिचालन नोट्स

• page_inject जानबूझकर स्थैतिक रूप से लिंक किया गया है ताकि हमलावर की अपनी प्रक्रिया उस हुक से प्रभावित न हो जो वह स्थापित करता है।
• page_inject एक "पहले से हुक किए गए" libc को पहचानता है (read() की प्रस्तावना पर E9 + nops) और पुनः-इंजेक्ट करने से इनकार करता है। यदि आप परीक्षण वातावरण में हैं और आपका पेज कैश उस स्थिति में अटका हुआ है, तो इमेज का उपयोग करने वाले सभी कंटेनरों को रोकें और रीसेट करने के लिए drop_caches चलाएं।