szybnev/cve-2026-7482CVE-2026-7482 में Ollama GGUF लोडिंग और क्वांटाइज़ेशन में हीप आउट-ऑफ-बाउंड्स रीड को पुनः उत्पन्न करता है, साथ ही OOB प्रभाव को प्रदर्शित करने के लिए क्वांटाइज़्ड आर्टिफैक्ट्स का विभेदक विश्लेषण करता है।
इस रिपॉजिटरी में CVE-2026-7482 के लिए मेरी स्थानीय रिप्रोडक्शन स्क्रिप्ट है, जो कमजोर Ollama GGUF लोडिंग और क्वांटाइज़ेशन पथों में एक हीप आउट-ऑफ-बाउंड्स रीड है।
इस कार्य का महत्वपूर्ण परिणाम संकीर्ण है: मैं हीप OOB स्थिति को विश्वसनीय रूप से घटित करने और OOB-प्रभावित क्वांटाइज़्ड GGUF आर्टिफैक्ट उत्पन्न करने में सक्षम था। मैं स्पष्ट ब्लैक-बॉक्स प्रभाव जैसे विश्वसनीय प्लेनटेक्स्ट सीक्रेट रिकवरी या परिणामी आर्टिफैक्ट से कैनरी स्ट्रिंग्स का सीधा निष्कर्षण प्रदर्शित करने में सक्षम नहीं था।
exp.py दो GGUF फ़ाइलें बनाता है:
यह दोनों फ़ाइलों को स्थानीय Ollama API के माध्यम से एक कमजोर Ollama इंस्टेंस पर अपलोड करता है, /api/create के साथ क्वांटाइज़ेशन ट्रिगर करता है, स्थानीय Docker कंटेनर से उत्पन्न GGUF ब्लॉब्स की प्रतिलिपि बनाता है, और दुर्भावनापूर्ण आउटपुट की तुलना शून्य-नियंत्रण आउटपुट से करता है।
विभेदक तुलना उपयोगी है क्योंकि यह दिखाती है कि कमजोर क्वांटाइज़ेशन पथ ने उन बाइट्स का उपयोग किया जो मूल दुर्भावनापूर्ण GGUF फ़ाइल में मौजूद नहीं थे। मेरे परीक्षणों में, यह व्यवहार Ollama 0.17.0 पर स्थिर था और फिक्स्ड 0.17.1 पथ द्वारा अस्वीकार कर दिया गया था।
requests के साथ Python 30.17.0ollama-old-testउदाहरण लैब लक्ष्य:
docker run -d --name ollama-old-test -p 11435:11434 ollama/ollama:0.17.0
एकमात्र Python निर्भरता स्थापित करें:
python3 -m pip install requests
http://localhost:11435 और कंटेनर ollama-old-test के विरुद्ध डिफ़ॉल्ट परीक्षण चलाएँ:
python3 exp.py
स्पष्ट तर्क:
python3 exp.py http://localhost:11435 ollama-old-test Q4_K_M F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F32
स्क्रिप्ट स्थानीय आर्टिफैक्ट लिखती है जैसे:
malicious_model.ggufcontrol_model.ggufquantized_model.ggufcontrol_quantized_model.ggufq8_dequantized_f32.binq8_pseudo_f16.binq8_pseudo_f16.txtमेरे स्थानीय परीक्षणों में, कमजोर Ollama संस्करण ने क्वांटाइज़्ड आउटपुट बनाए जहां दुर्भावनापूर्ण टेंसर पेलोड शून्य-नियंत्रण टेंसर से भिन्न था, इस तथ्य के बावजूद कि दुर्भावनापूर्ण GGUF फ़ाइल में वे बाइट्स नहीं थे।
यह OOB-प्रभावित आर्टिफैक्ट दिखाने के लिए पर्याप्त है। यह व्यावहारिक ब्लैक-बॉक्स डेटा प्रकटीकरण का दावा करने के लिए पर्याप्त नहीं है।
मैंने समवर्ती मॉडल प्रॉम्प्ट्स में कैनरी-शैली डेटा का भी परीक्षण किया और उत्पन्न आर्टिफैक्ट्स, Q8_0 डीक्वांटाइज़्ड फ्लोट32 बाइट्स, और स्यूडो-F16 पुनर्निर्माण आउटपुट खोजा। मैं सटीक कैनरी या सार्थक प्लेनटेक्स्ट टुकड़े पुनर्प्राप्त नहीं कर सका।
संभावित कारण यह है कि बाइट्स को कच्चे हीप मेमोरी के रूप में कॉपी नहीं किया जाता है। वे मॉडल रूपांतरण और क्वांटाइज़ेशन पाइपलाइन से गुजरते हैं:
heap bytes -> interpreted as F16/F32 tensor values -> converted/quantized -> GGUF tensor output
यह पथ हानिपूर्ण है, विशेष रूप से Q4_K_M जैसे क्वांटाइज़्ड प्रारूपों के साथ। Q8_0 Q4_K_M की तुलना में अधिक संख्यात्मक जानकारी संरक्षित करता है, लेकिन फिर भी यह मेरे ब्लैक-बॉक्स-शैली परीक्षणों में विश्वसनीय प्लेनटेक्स्ट पुनर्प्राप्ति उत्पन्न नहीं करता था।
यह एक स्थानीय लैब रिप्रोडक्शन और आर्टिफैक्ट विश्लेषण सहायक है।
यह एक विश्वसनीय रिमोट सीक्रेट एक्सफिल्ट्रेशन प्रिमिटिव प्रदान नहीं करता है। इसे परीक्षण कंटेनर से Ollama के उत्पन्न ब्लॉब की प्रतिलिपि बनाने के लिए स्थानीय Docker पहुंच की भी आवश्यकता होती है, इसलिए विश्लेषण चरण एक शुद्ध रिमोट ब्लैक-बॉक्स वर्कफ़्लो नहीं है।
मेरे परीक्षणों से व्यावहारिक निष्कर्ष है:
0x0OZ द्वारा एक अलग PoC रिपॉजिटरी भी है:
वह कार्यान्वयन उत्पन्न मॉडल आर्टिफैक्ट को एक नियंत्रित रजिस्ट्री में धकेल कर एक मजबूत व्हाइट-बॉक्स-शैली वर्कफ़्लो प्रदर्शित करता है। मेरे PR से रजिस्ट्री अपलोड-फ्लो फिक्स के साथ, यह मेरे स्थानीय लैब में सफलतापूर्वक पूरा होता है:
उस बेहतर एंड-टू-एंड आर्टिफैक्ट संग्रह पथ के साथ भी, वही डेटा-गुणवत्ता चेतावनी महत्वपूर्ण बनी रहती है: आउटपुट क्वांटाइज़्ड/मॉडल-रूपांतरित डेटा है, प्रत्यक्ष कच्चा हीप डंप नहीं।
यह रिपॉजिटरी केवल अधिकृत भेद्यता अनुसंधान और रक्षात्मक रिप्रोडक्शन के लिए है। केवल उन प्रणालियों के विरुद्ध परीक्षण करें जिनके स्वामी आप हैं या जिनका आकलन करने की स्पष्ट अनुमति आपके पास है।