KVM एस्केप त्रयी

ITScape (CVE‑2026‑46316)

Januscape (CVE‑2026‑53359)

Zapscape (CVE‑2026‑64561)

Zapscape: KVM/x86 में गेस्ट-से-होस्ट एस्केप

सार

यह दस्तावेज़ Zapscape (CVE-2026-64561) भेद्यता का वर्णन करता है, जिसे Hyunwoo Kim (@v4bel) द्वारा खोजा और रिपोर्ट किया गया था। यह एक KVM एस्केप भेद्यता है जो KVM/x86 वातावरण में गेस्ट को होस्ट तक एस्केप करने और होस्ट पर कर्नेल (रूट) विशेषाधिकार के साथ कमांड चलाने की अनुमति देती है।

Zapscape, KVM/x86 की shadow MMU एमुलेशन में एक use-after-free भेद्यता है, विशेष रूप से रिकर्सिव zap पथ में, जो shadow pages के पुनः प्राप्त (reclaim) होने पर चलता है। यह केवल गेस्ट-साइड क्रियाओं से बग को ट्रिगर कर होस्ट कर्नेल के shadow page को भ्रष्ट कर सकता है, और यह उन KVM/x86 होस्ट्स के गेस्ट-होस्ट अलगाव को खतरे में डाल सकता है जो अविश्वसनीय गेस्ट स्वीकार करते हैं और नेस्टेड वर्चुअलाइज़ेशन उजागर करते हैं, विशेष रूप से मल्टी-टेनेंट x86 पब्लिक क्लाउड्स को।

विस्तृत तकनीकी जानकारी के लिए, यहाँ देखें.

[!NOTE] इस भेद्यता को [email protected] पर रिपोर्ट करने के बाद, सहमत एम्बार्गो समाप्त हो गया है, इसलिए एक्सप्लॉइट oss-security पर पोस्ट किया गया है और यह Zapscape दस्तावेज़ प्रकाशित किया गया है। प्रकटीकरण समयरेखा के लिए, तकनीकी विवरण दस्तावेज़ देखें।

PoC संरचना

PoC को AMD को लक्षित करने के लिए लिखा गया है, और सुरक्षित परीक्षण के लिए इसे QEMU TCG के अंतर्गत चलाने की अनुशंसा की जाती है। PoC की संरचना निम्नलिखित है।

L0: Linux 7.1.3 + KVM_AMD on an x86_64 CPU (AMD SVM/NPT) emulated by QEMU TCG. The escape target
  └─ L1: the guest poc creates. Switching long -> PAE aliases one shadow page as both child and pinned root, and L1 then escalates the UAF into L0 kernel code-exec
       └─ L2: the guest L1 VMRUNs. Its memory touches trigger L0's quota reclaim -> recursive zap with no root_count guard -> UAF

यह PoC एक weaponized एक्सप्लॉइट नहीं है जो क्लाउड वातावरण में तुरंत चल जाए, बल्कि प्रदर्शन कोड है जो QEMU TCG के ऊपर भेद्यता और पूर्ण एक्सप्लॉइट श्रृंखला को पुन: उत्पन्न करता है। इसे वास्तविक क्लाउड वातावरण में उपयोग करने के लिए, PoC द्वारा किए जाने वाले L1 कार्यों को गेस्ट कर्नेल मॉड्यूल में स्थानांतरित किया जाना चाहिए, और होस्ट कर्नेल के kconfig से मेल खाने के लिए एक्सप्लॉइट को पोर्ट किया जाना चाहिए। यह कोई कठिन कार्य नहीं है।

PoC उपयोग

1. वल्नरेबल v7.1.3 कर्नेल स्रोत डाउनलोड करें, फिर बंडल किए गए kconfig के आधार पर कर्नेल इमेज बनाएं।
2. PoC बनाएं, फिर BusyBox या उसी तरह की चीज़ का उपयोग करके एक उपयुक्त initramfs तैयार करें और निर्मित PoC को initramfs में डालें।

# gcc -O2 -g -static -pthread poc.c -o poc

3. Linux 7.1.3 टारगेट को निम्न कमांड के साथ बूट करें। QEMU v9.2.0 या बाद के संस्करण पर परीक्षण करें।

# ./qemu.sh bzImage initramfs.cpio.gz

4. QEMU TCG बूट होने के बाद, PoC चलाएँ। सफल एक्सप्लॉइट पर, यह गेस्ट से एस्केप करता है और होस्ट पर रूट के स्वामित्व वाली /Zapscape फ़ाइल बनाता है।

 /$$$$$$$$  /$$$$$$  /$$$$$$$
|_____ $$  /$$__  $$| $$__  $$
     /$$/ | $$  \ $$| $$  \ $$
    /$$/  | $$$$$$$$| $$$$$$$/
   /$$/   | $$__  $$| $$____/
  /$$/    | $$  | $$| $$
 /$$$$$$$$| $$  | $$| $$
|________/|__/  |__/|__/

[+] /Zapscape created by the target KVM host kernel (owner uid=0, mode=0644).
[+] exploit completed - verify with: ls -la /Zapscape
zapscape(uid=65534)$ ls -la /Zapscape
-rw-r--r--    1 root     root             0 Jul 29 05:27 /Zapscape
zapscape(uid=65534)$

यह PoC सटीक जानकारी प्रदान करने के लिए है। इसे उन सिस्टमों पर उपयोग न करें जिन्हें आप परीक्षण करने के लिए अधिकृत नहीं हैं।

प्रभावित संस्करण

Zapscape (CVE-2026-64561) f95eec9bed76 (2020-07-08) से 2abd5287f083 (2026-07-21) तक की सीमा को कवर करता है।

FAQ

इस भेद्यता का प्रभाव क्या है?

Januscape (CVE-2026-53359) के समान:

1. KVM एस्केप: केवल गेस्ट-साइड क्रियाओं से, एक हमलावर अपने VM को चलाने वाले होस्ट से समझौता कर सकता है। उदाहरण के लिए, एक हमलावर जिसने पब्लिक क्लाउड पर केवल एक इंस्टेंस किराए पर लिया है, वह होस्ट कर्नेल को पैनिक करके उसी भौतिक मशीन पर चल रहे अन्य सभी टेनेंट VM को नीचे ला सकता है (DoS), या होस्ट पर रूट विशेषाधिकार के साथ कोड चलाकर होस्ट और उस पर मौजूद सभी गेस्ट को अपने अधीन कर सकता है (RCE)।
2. LPE: RHEL जैसे डिस्ट्रीब्यूशन पर, /dev/kvm विश्व-लेखन योग्य (0666) है, इसलिए एक विशेषाधिकार प्राप्त (unprivileged) उपयोगकर्ता भी रूट प्राप्त करने के लिए इस भेद्यता को LPE के रूप में उपयोग कर सकता है। जब इसे LPE के रूप में उपयोग किया जाता है, तो होस्ट-साइड VMM ioctls उपलब्ध होते हैं, इसलिए एक्सप्लॉइट आसान और अधिक स्थिर हो जाता है।

यह Januscape से कैसे संबंधित है?

यह उसी shadow MMU में होती है, लेकिन यह एक अलग मूल कारण वाली पृथक भेद्यता है।

फिर भी, Januscape के विपरीत, Intel पर इसे केवल तब ट्रिगर किया जा सकता है जब EPT पेज वॉक लंबाई 4 और 5 दोनों L1 के लिए उजागर हों। प्रभावित दायरे का आकलन करते समय यह एक महत्वपूर्ण बिंदु है, इसलिए इसे सटीक रूप से समझा जाना चाहिए। तकनीकी विवरण दस्तावेज़ देखें।

क्या यह भेद्यता QEMU में होती है?

नहीं। Januscape की तरह, यह इन-कर्नेल KVM में होती है, इसलिए यह QEMU के एमुलेशन से स्वतंत्र रूप से ट्रिगर होती है। इस वजह से, यह उन बड़े पब्लिक क्लाउड्स को भी खतरे में डाल सकती है जो अपना स्वयं का वर्चुअलाइज़ेशन स्टैक लागू और उपयोग करते हैं।

क्या मुझे गेस्ट VM के अंदर रूट की आवश्यकता है?

हाँ। L1 कर्नेल विशेषाधिकार आवश्यक है। जब आपको पब्लिक क्लाउड पर एक इंस्टेंस आवंटित किया जाता है, तो आपके पास आमतौर पर अपने VM पर रूट होता है, इसलिए यह शर्त पूरी हो जाती है। गेस्ट रूट के बिना परिदृश्य में, इसे Dirty Frag जैसे LPE के साथ जोड़ा जाना चाहिए।

क्या आपको लगता है कि KVM भेद्यताएँ आती रहेंगी?

हाँ। मैं होस्ट हाइपरवाइज़र के लिए एक सतत पैचिंग प्रक्रिया स्थापित करने की अनुशंसा करता हूँ। सर्दी आ रही है।

क्या आप त्रयी के बाद सीक्वल की योजना बना रहे हैं?

मुझे उम्मीद है कि नहीं।