luigigubello/cve-2025-64512-polyglot-pocCVE-2025-64512 के लिए पॉलीग्लॉट फ़ाइल का उपयोग करने वाला एक प्रूफ-ऑफ-कॉन्सेप्ट।
पिछले हफ्तों में (नवंबर 2025 में), pdfminer.six में एक दिलचस्प कमजोरी (CVE-2025-64512) का खुलासा हुआ, जो PDF फ़ाइलों को प्रोसेस करने के लिए एक लोकप्रिय Python प्रोजेक्ट है, जिसका उपयोग विशेष रूप से AI पाइपलाइनों में किया जाता है। यह कमजोरी pickle.loads() के माध्यम से अविश्वसनीय डेटा को deserialize करके रिमोट कोड निष्पादन (remote code execution) सक्षम बनाती है, और PDF फ़ाइल का उपयोग अटैक वेक्टर के रूप में करती है। अब तक सब ठीक है: यह एक लोकप्रिय Python पैकेज में एक महत्वपूर्ण कमजोरी है। मेरा ध्यान इसकी exploitability पर गया 👀।
Linux-जैसे सिस्टम पर केवल फाइल सिस्टम पर मौजूद फाइलों को ही हल (resolve) किया जा सकता है। हमलावर को प्रोसेसिंग के लिए दुर्भावनापूर्ण PDF उपलब्ध करानी होगी और दुर्भावनापूर्ण pickle फ़ाइल को लक्षित सिस्टम पर ऐसे स्थान पर मौजूद होना होगा जो हमलावर को पहले से पता हो, क्योंकि इसे PDF में ही सेट करना आवश्यक होता है। कई मामलों में इसका शोषण करना मुश्किल होगा, क्योंकि भले ही हमलावर PDF और pickle फ़ाइल दोनों एक साथ उपलब्ध करा दे, फिर भी pickle फ़ाइल का पूरा पथ पहले से जानने का कोई तरीका नहीं होगा। [...] कुल मिलाकर, Linux या Linux-जैसे सिस्टम पर आम तौर पर जोखिम कम होता है।
तो, जाहिर तौर पर, Linux-जैसे सिस्टम पर इस कमजोरी का शोषण करने के लिए, हमलावर को चाहिए:
क्या हम दुर्भावनापूर्ण pickle फ़ाइल का फ़ाइलपथ जाने बिना एक वैध PDF फ़ाइल बना सकते हैं जो कमजोरी को ट्रिगर करे?
"वैध" का अर्थ है कि pdfminer.six फ़ाइल को अस्वीकार नहीं करता और उसे प्रोसेस करना शुरू कर देता है (क्योंकि PDF फ़ाइल वही है जिसे PDF रीडर खोलता है)।
उत्तर है हाँ, एक polyglot payload (एक प्रकार का) बनाना। विचार यह है कि एक ऐसी फ़ाइल बनाई जाए जो एक वैध pickle.gz और एक वैध PDF फ़ाइल दोनों हो, ताकि pdf2txt.py एक PDF फ़ाइल को प्रोसेस करना शुरू कर सके और फिर GZIP प्रारूप में pickle कोड लोड करने के लिए उसकी ओर इशारा कर सके।
अक्सर - लेकिन हमेशा नहीं 🥲 - एक फ़ाइल PDF फ़ाइल होती है यदि उसमें %PDF- कहीं हो, आम तौर पर पहले 1024 बाइट्स में (1 - 2)। pdfminer.six के लिए, एक वैध PDF फ़ाइल में बस एक /Root ऑब्जेक्ट होना चाहिए (pdfdocument.py#L752)।
GZIP फ़ाइल के विशिष्ट प्रारंभिक बाइट्स होते हैं (RFC 1952 - Sec. 2.3.1), लेकिन यह कमेंट्स (FCOMMENT, RFC 1952 - Sec. 2.3.1) का समर्थन करती है।
तो, यह है polyglot फ़ाइल डिज़ाइन: एक वैध GZIP बनाएं जिसमें दुर्भावनापूर्ण pickle payload हो, और GZIP FCOMMENT फ्लैग में एक वैध PDF फ़ाइल एम्बेड करें। फिर इस फ़ाइल का उपयोग pdf2txt.py के साथ एक वैध PDF के रूप में करके कमजोरी को ट्रिगर करें, और उसी फ़ाइल का उपयोग दुर्भावनापूर्ण pickle को निष्पादित करने के लिए करें।
(2025.12.12) संपादन:
हमारे पास एकमात्र बाधा फ़ाइल नाम है: इसे .pickle.gz के साथ समाप्त होना चाहिए (यह ।pdfminer.six कोड में एम्बेडेड है, cmapdb.py#L235)
हमारे पास दो बाधाएँ हैं:
pdfminer.six कोड में एम्बेडेड है, cmapdb.py#L235);मैं थोड़ा आश्चर्यचकित हूं कि यह CVE इतना कम आंका गया है, इस प्रोजेक्ट की लोकप्रियता (GitHub पर 6k ⭐️, लेकिन GitHub आँकड़ों के अनुसार 34k प्रोजेक्ट्स द्वारा उपयोग किया जाता है) और उपयोग-मामलों (कमांड-लाइन टूल्स, AI वर्कफ़्लो, पाइपलाइन, संक्षेप में, सभी प्रकार के इंफ्रास्ट्रक्चर जिन्हें आप अपडेट नहीं करना चाहते यदि वे ठीक से काम कर रहे हैं) को देखते हुए।
उदाहरण के लिए, Microsoft टूल markitdown 0.1.3 (microsoft/markitdown, GitHub पर 84k ⭐️ और 2k प्रोजेक्ट्स द्वारा उपयोग किया जाता है), जो 1 दिसंबर से पहले इंस्टॉल किया गया था, pdfminer.six के माध्यम से मनमाना कोड निष्पादन (arbitrary code execution) के प्रति संवेदनशील है। Microsoft टीम ने 1 दिसंबर को एक पैच, 0.1.4 जारी किया, लेकिन कोई सुरक्षा अलर्ट नहीं, इसलिए मुझे नहीं लगता कि अन्य इंजीनियरिंग टीमों ने अपडेट को प्राथमिकता दी है।
अन्य प्रोजेक्ट्स भी CVE-2025-64512 से प्रभावित हो सकते हैं, और इसका शोषण करना काफी आसान है।
असुरक्षित प्रोजेक्ट्स की एक (अपूर्ण) सूची:
docker build -t cve-2025-64512-poc .
docker run --rm -it cve-2025-64512-poc
pdf2txt.py payload.pickle.gz
docker build -t cve-2025-64512-poc .
docker run --rm -it cve-2025-64512-poc
markitdown markitdown-payload.pickle.gz -x pdf -o output.md
