Januscape: 16 साल पुरानी KVM खामी जो एक गेस्ट VM को होस्ट पर एस्केप करने देती है

टैनेंट्स के बीच की दीवार में दरार आ गई है

क्लाउड कंप्यूटिंग का पूरा वादा एक शांत धारणा पर टिका है: आप जो वर्चुअल मशीन (virtual machine) किराए पर लेते हैं, वह उस फिजिकल होस्ट तक नहीं पहुँच सकती और न ही उसे छू सकती है जिस पर वह चलती है, और निश्चित रूप से वह अपने पास बैठी किसी अनजान व्यक्ति की VM को भी नहीं छू सकती। उस दीवार को हाइपरवाइज़र आइसोलेशन (hypervisor isolation) कहा जाता है, और Linux पर इसे KVM — Kernel-based Virtual Machine द्वारा लागू किया जाता है जो दुनिया के बहुत बड़े हिस्से के क्लाउड सर्वरों को संचालित करता है।

4 जुलाई, 2026 को, Linux कर्नल मेंटेनर्स ने उस खामी को बंद करने के लिए आपातकालीन स्टेबल रिलीज़ की एक लहर जारी की, जिसने सोलह वर्षों से चुपचाप उस दीवार को कमजोर कर दिया था। CVE-2026-53359 के रूप में ट्रैक की गई और "Januscape" उपनाम वाली यह खामी एक साधारण गेस्ट VM के भीतर चल रहे कोड को होस्ट कर्नल को दूषित करने की अनुमति देती है — Intel और AMD दोनों प्रणालियों पर। यह अब इसलिए मायने रखता है क्योंकि पैच आने का मतलब है कि विवरण सार्वजनिक हैं, और जहाँ सार्वजनिक फिक्स होता है, वहाँ जल्द ही एक सार्वजनिक एक्सप्लॉइट भी होता है।

वास्तव में Januscape क्या है

Januscape एक यूज़-आफ्टर-फ्री (use-after-free) भेद्यता है। सरल शब्दों में, यूज़-आफ्टर-फ्री तब होता है जब कोई प्रोग्राम मेमोरी के किसी टुकड़े का उपयोग करना जारी रखता है, भले ही उसे पहले ही वापस सौंप दिया गया हो और किसी अन्य चीज़ के लिए पुनः उपयोग किया गया हो — जैसे टैनेंट्स के चले जाने और अजनबियों के आ जाने के बाद किसी पते पर पत्र भेजना। हमलावर सिस्टम को उस "मुक्त" (freed) स्थान पर जो कुछ भी लिखने के लिए मना सकता है, उसे ऐसे माना जाता है जैसे कि वह अभी भी मूल, विश्वसनीय डेटा हो।

यह बग KVM के shadow MMU में रहता है। जब कोई गेस्ट VM चलता है, तो उसके पास मेमोरी एड्रेस का अपना विचार होता है, लेकिन वे होस्ट के वास्तविक एड्रेस नहीं होते हैं। किसी चीज़ को दोनों के बीच अनुवाद करना होता है, और वह चीज़ मेमोरी मैनेजमेंट यूनिट (memory management unit) है। कई कॉन्फ़िगरेशन पर KVM "shadow" पेज टेबल का उपयोग करके सॉफ़्टवेयर में यह अनुवाद करता है जो गेस्ट की टेबल को होस्ट की वास्तविक टेबल में मिरर करती है। Januscape उस shadow-MMU इम्यूलेशन में एक खामी है: केवल गेस्ट-साइड क्रियाओं के साथ, एक हमलावर होस्ट कर्नल के shadow पेज को दूषित कर सकता है — वही संरचना जो गेस्ट को बाड़ के भीतर रखने के लिए मानी जाती है।

"Intel और AMD दोनों" डरावना हिस्सा क्यों है

अधिकांश वर्चुअल-मशीन एस्केप बग वेंडर-विशिष्ट होते हैं। वे Intel के VT-x या AMD के AMD-V की किसी ख़ासियत का फायदा उठाते हैं, इसलिए एक चिप चलाने वाला प्रदाता जोखिम में होता है जबकि दूसरा सुरक्षित होता है। Januscape अलग है। यह shadow-MMU कोड में स्थित है जिसे KVM दोनों वेंडरों के बीच साझा करता है, यही वजह है कि इसे सार्वजनिक रूप से जाना जाने वाला पहला ऐसा गेस्ट-टू-होस्ट एस्केप बताया गया है जिसे Intel और AMD दोनों x86 प्रणालियों पर ट्रिगर किया जा सकता है।

मिश्रित हार्डवेयर वाले क्लाउड ऑपरेटर के लिए, यह सामान्य एस्केप हैच (बचाव का रास्ता) को समाप्त कर देता है। बेड़े को माइग्रेट करने के लिए कोई "सुरक्षित" प्रोसेसर नहीं है। यह अकेली तकनीक हर जगह काम करती है जहाँ संवेदनशील कोड चलता है।

यह वास्तव में कितना बुरा है

सार्वजनिक रूप से जारी किया गया प्रूफ़-ऑफ़-कॉन्सेप्ट नुकसान का "सभ्य" संस्करण करता है: यह होस्ट को पैनिक कर देता है। यह हानिकारक रहित नहीं है — पैनिक पूरी भौतिक मशीन और उस पर चल रही हर टैनेंट VM को क्रैश कर देता है, जो उस बॉक्स पर मौजूद सभी लोगों के लिए एक डिनायल-ऑफ़-सर्विस (denial-of-service) है।

इससे भी बुरा हिस्सा वह है जो जारी नहीं किया गया था। सुरक्षा शोधकर्ता Hyunwoo Kim (@v4bel), जिन्होंने बग की खोज की और रिपोर्ट की, उनका कहना है कि एक अलग, गैर-जारी एक्सप्लॉइट उसी खामी को पूर्ण होस्ट कोड निष्पादन (full host code execution) में बदल देता है। यह दुःस्वप्न का परिदृश्य है: एक सस्ती VM से हमलावर कोड होस्ट के रूप में चल रहा है, जो पड़ोसी टैनेंट की हर मशीन को पढ़ने और फिर से लिखने में सक्षम है। यह बग Google के kvmCTF में शून्य-दिवस (zero-day) के रूप में प्रस्तुत किए जाने के लिए पर्याप्त गंभीर था, जो कि नियंत्रित इनाम कार्यक्रम है जो पूर्ण गेस्ट-टू-होस्ट एस्केप की ठीक इसी श्रेणी के लिए 250,000 अमेरिकी डॉलर तक का भुगतान करता है। और यह लगभग सोलह वर्षों तक साफ़ नज़र के सामने छिपा रहा।

वास्तव में कौन जोखिम में है

आपके लिए एक सक्रिय खतरा होने के लिए दो शर्तों का सच होना आवश्यक है:

आप अविश्वासी गेस्ट्स को स्वीकार करते हैं। पब्लिक क्लाउड्स, VPS प्रदाता, साझा CI/CD रनर्स, सैंडबॉक्स सेवाएं — कहीं भी जहाँ कोई अनजान व्यक्ति आपके द्वारा चलाए जाने वाले हार्डवेयर पर VM चालू कर सकता है।

आप नेस्टेड वर्चुअलाइजेशन को उजागर करते हैं। हमला पथ उन गेस्ट्स के लिए नेस्टेड वर्चुअलाइजेशन सक्षम होने पर निर्भर करता है।

यदि आप एक सिंगल-टैनेंट सर्वर चलाते हैं जो केवल आपके स्वयं के वर्कलोड की मेज़बानी करता है, तो आपका जोखिम बहुत कम है — हमलावर को पहले से ही आपके अपने VM में से किसी एक के भीतर होना होगा। लेकिन यदि आप कंप्यूट बेचते हैं या साझा करते हैं, तो इसे तत्काल समझें।

चरण 1: पता करें कि क्या आप जोखिम में हैं

चल रहे कर्नल संस्करण की जाँच करें और यह भी कि क्या नेस्टेड वर्चुअलाइजेशन सक्षम है:

# Which kernel am I running?
uname -r

# Is nested virtualization on? (Intel host)
cat /sys/module/kvm_intel/parameters/nested

# Or on an AMD host
cat /sys/module/kvm_amd/parameters/nested

यदि दोनों में से कोई भी कमांड लौटाता है Y (या 1) और आपका कर्नल नीचे दी गई फिक्स की गई रिलीज़ से पुराना है, तो आप दायरे में हैं।

चरण 2: एक फिक्स किए गए कर्नल पर पैच करें

फिक्स किए गए स्टेबल कर्नल 4 जुलाई, 2026 को शिप किए गए थे। इनमें से कम से कम एक लाइन पर अपडेट करें और इसमें रीबूट करें:

7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260

अधिकांश डिस्ट्रिब्यूशन पर यह एक सामान्य पैकेज अपडेट है:

sudo apt update && sudo apt full-upgrade   # Debian / Ubuntu
sudo dnf update kernel                       # Fedora / RHEL family
# then reboot into the new kernel
sudo reboot

के साथ पुष्टि करें uname -r रीबूट के बाद कि आप एक पैच किए गए बिल्ड पर हैं।

चरण 3: यदि आप तुरंत पैच नहीं कर सकते हैं, तो नेस्टेड वर्चुअलाइजेशन को अक्षम करें

उन होस्ट्स के लिए जो अविश्वासी गेस्ट्स को स्वीकार करते हैं लेकिन तुरंत रीबूट नहीं कर सकते हैं, नेस्टेड वर्चुअलाइजेशन को हटाना हमला पथ को समाप्त कर देता है:

# Intel host
echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.conf

# AMD host
echo "options kvm_amd nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.conf

इसके प्रभावी होने के लिए मॉड्यूल को पुनः लोड करें (या रीबूट करें)। इसके समझौते (trade-off) को समझें: यह आपके टैनेंट्स पर निर्भर किसी भी वैध नेस्टेड वर्चुअलाइजेशन को तोड़ देता है — VMs के भीतर चल रहे VMs। यह एक अस्थायी उपाय (stopgap) है, कर्नल पैच का विकल्प नहीं।

निष्कर्ष

Januscape एक अनुस्मारक है कि क्लाउड कंप्यूटिंग में सबसे मजबूत दीवार अभी भी सॉफ़्टवेयर से बनी है, और सोलह साल पहले लिखा गया सॉफ़्टवेयर पूरी इंडस्ट्री को खतरे में डालने के लिए काफी लंबे समय तक एक ही गलती को छिपा कर रख सकता है। अच्छी खबर यह है कि फिक्स पहले से ही उपलब्ध है और शमन आसान है। कंप्यूट साझा करने वाले प्रत्येक ऑपरेटर के सामने का कार्य अनग्लैमरस लेकिन स्पष्ट है: अपने कर्नल की जाँच करें, इसे पैच करें, और यदि आप आज पैच नहीं कर सकते हैं, तो नेस्टेड वर्चुअलाइजेशन को तब तक बंद कर दें जब तक आप कर न सकें। सार्वजनिक पैच और सार्वजनिक रूप से हथियारबंद एक्सप्लॉइट के बीच का समय महीनों में नहीं, बल्कि दिनों में मापा जाता है।

गुण

• फिक्स पहले से ही मौजूद है। जिस दिन खामी सार्वजनिक हुई, उसी दिन पैच किए गए स्टेबल कर्नल जारी किए गए थे, इसलिए उपचार (remediation) एक नियमित अपडेट है, न कि कोई शोध परियोजना।
• एक स्वच्छ, तत्काल शमन। नेस्टेड वर्चुअलाइजेशन को अक्षम करना नए कर्नल में रीबूट करने से पहले ही हमला पथ को बंद कर देता है।
• समन्वित प्रकटीकरण ने काम किया। यह बग Google के kvmCTF इनाम कार्यक्रम के माध्यम से मेंटेनर्स तक पहुँचा, और एक हथियारबंद एक्सप्लॉइट से पहले पैच शिप कर दिया गया था।

दोष

• सोलह वर्षों का गुप्त जोखिम। कोई भी निश्चितता के साथ यह नहीं कह सकता कि प्रकटीकरण से पहले कभी भी इस खामी का चुपचाप उपयोग नहीं किया गया था।
• क्रॉस-वेंडर पहुँच। चूँकि यह साझा shadow-MMU कोड में रहता है, इसलिए वापस लौटने के लिए कोई "सुरक्षित" Intel या AMD चिप नहीं है।
• एक पूर्ण-RCE एक्सप्लॉइट निजी रूप से मौजूद है। सार्वजनिक PoC केवल होस्ट को क्रैश करता है, लेकिन शोधकर्ता पुष्टि करते हैं कि एक अधिक मजबूत, गैर-जारी संस्करण होस्ट कोड निष्पादन प्राप्त करता है।

सावधानी

सार्वजनिक प्रूफ़-ऑफ़-कॉन्सेप्ट को जोखिम की सीमा न मानें। यह केवल होस्ट को पैनिक करता है; असली खतरा निजी एक्सप्लॉइट है जो कथित तौर पर पूर्ण होस्ट निष्पादन प्राप्त करता है। यदि आप मल्टी-टैनेंट इन्फ्रास्ट्रक्चर संचालित करते हैं, तो सुविधा से अधिक कर्नल पैच को प्राथमिकता दें, और के साथ पुष्टि करें uname -r कि प्रत्येक होस्ट वास्तव में फिक्स किए गए बिल्ड में रीबूट हो गया है — एक पैच किया गया पैकेज जो अभी भी पुराना कर्नल चला रहा है, कुछ भी सुरक्षित नहीं करता है।

अक्सर पूछे जाने वाले प्रश्न

क्या यह मेरे व्यक्तिगत लैपटॉप या डेस्कटॉप को प्रभावित करता है? केवल अप्रत्यक्ष रूप से। यदि आप नेस्टेड वर्चुअलाइजेशन के साथ अविश्वासी गेस्ट VMs नहीं चला रहे हैं, तो आप इस हमले के लक्षित दर्शक नहीं हैं — लेकिन अपने कर्नल को पैच करना अभी भी अच्छी स्वच्छता है।

क्या नेस्टेड वर्चुअलाइजेशन को अक्षम करना अपने आप में पर्याप्त है? यह अविश्वासी गेस्ट्स के लिए ज्ञात हमला पथ को हटा देता है, लेकिन यह एक अस्थायी उपाय है। जितनी जल्दी हो सके कर्नल पैच लागू करें और केवल पैच किए गए होस्ट्स पर नेस्टेड वर्चुअलाइजेशन को पुनः सक्षम करें।

क्या मेरा क्लाउड प्रदाता इसे मेरे लिए ठीक कर सकता है? प्रमुख प्रदाता अपनी ओर से होस्ट हाइपरवाइज़र को पैच करते हैं; आपके स्वयं के गेस्ट VMs संवेदनशील घटक नहीं हैं। यदि आप हैं प्रदाता — कंप्यूट फिर से बेच रहे हैं या साझा रनर्स चला रहे हैं — तो जिम्मेदारी आपकी है।

इसे "Januscape" क्यों कहा जाता है? यह नाम Janus की याद दिलाता है, जो दो चेहरों वाले रोमन देवता हैं — यह उस खामी के लिए उपयुक्त है जो x86 दुनिया के Intel और AMD दोनों चेहरों तक फैली हुई है।

टैग

security, linux, virtualization, kvm, cve