airineiandrei/tarmageddon-cve-2025-62518-CVE-2025-62518 के लिए PoC जो tokio-tar PAX हेडर पार्सिंग के माध्यम से tar संग्रह तस्करी प्रदर्शित करता है, दुर्भावनापूर्ण पेलोड और एक कमजोर निकालने वाला बनाकर आपूर्ति-श्रृंखला इंजेक्शन दिखाता है।
वीडियो: https://youtu.be/EYBB4BHsp9E
./output में निकालता हैmalicious.tar संग्रह बनाता है, टिप्पणियाँ बताती हैं कि चरण दर चरण और ब्लॉक दर ब्लॉक क्या किया जा रहा हैदिए गए reproduce script का उपयोग करें या मैन्युअल रूप से करें
malicious-payload चलाएँ ताकि पेलोड उत्पन्न हो
malicious.tarइस फ़ाइल को हमारे vulnerable-extract ऐप में पास करने पर प्राप्त होता है:
/vulnerable-extract$ ll output/
total 12
drwxrwxr-x 2 airinei airinei 4096 Jan 19 22:40 ./
drwxrwxr-x 5 airinei airinei 4096 Jan 19 22:40 ../
-rw-rw-r-- 1 airinei airinei 0 Jan 1 1970 benign_file.txt
-rw-rw-r-- 1 airinei airinei 18 Jan 1 1970 sh_profile_hijack
जबकि हमारे OS द्वारा प्रदत्त tar ((GNU tar) 1.35 इस मामले में) उपयोगिता चलाने पर प्राप्त होता है:
malicious-payload$ tar -tvf malicious.tar
---------- 0/0 1024 1970-01-01 02:00 benign_file.txt
ध्यान दें कि यह फ़ाइल का आकार 1024 देखता है
वैकल्पिक रूप से परित्यक्त tokio-tar 0.3.1 के बजाय astral-tokio-tar 0.5.6 का उपयोग करने पर संग्रह सही ढंग से निकलता है।
CVE-2025-62518 (TARmageddon) एक सुरक्षा भेद्यता है जो tokio-tar Rust लाइब्रेरी में पाई गई है (Rust भेद्यता 😮)। यह tar प्रारूप के हेडर को पार्स करने के तरीके में एक तार्किक त्रुटि है, जो एक हमलावर को फ़ाइलों की तस्करी करने की अनुमति देती है।
दोष PAX विस्तारित हेडर को संभालने वाले तर्क में मौजूद है। TAR संग्रह में, विभिन्न हेडर प्रकार होते हैं:
USTAR: मानक हेडर जिसमें फ़ाइल नाम, अनुमतियाँ और आकार होता है।PAX (Type x): एक विस्तार हेडर जो संग्रह में अगली फ़ाइल के लिए मेटाडेटा (जैसे बहुत बड़ा फ़ाइल आकार) प्रदान करने के लिए उपयोग किया जाता है।जब कोई PAX हेडर मौजूद होता है, तो एक पार्सर को PAX मेटाडेटा को मानक USTAR हेडर पर प्राथमिकता देते हुए फ़ाइल का वास्तविक आकार हल करना होता है।
लेकिन क्यों ऐसे 2 प्रकार के हेडर हैं जिनमें समान चीज़ के लिए प्राथमिकताएँ हैं? क्योंकि TAR प्रारूप पुराना है (1988 में मानकीकृत), और USTAR की अपनी सीमाएँ हैं (8GB तक का आकार, फ़ाइल नाम 256 वर्ण तक)। यह एक समस्या है, इसलिए 2001 में बड़ी फ़ाइलों और लंबे फ़़इल नामों की अनुमति देने के लिए PAX हेडर जोड़ा गया था।
tokio-tar के कमजोर संस्करणों में, पार्सर फ़ाइल सामग्री पाठक के लिए PAX हेडर से आकार को सही ढंग से अपनाता है, लेकिन यह गलत तरीके से USTAR हेडर से आकार का उपयोग यह निर्धारित करने के लिए करता है कि अगला फ़ाइल हेडर कहाँ से शुरू होता है।
समस्या का मूल एक पॉइंटर बेमेल है। जब कमजोर लाइब्रेरी एक फ़ाइल को संसाधित करती है, तो यह स्ट्रीम को पढ़ने के लिए दो अलग-अलग आंतरिक "हेड" का उपयोग करती है:
एक सामान्य संग्रह में, ये दो हेड सहमत होते हैं। TARmageddon में, हम उन्हें असहमत होने के लिए मजबूर करते हैं। PAX आकार को 1024 और USTAR आकार को 0 पर सेट करके, हम एक विरोधाभास बनाते हैं:
benign_file.txt में डालता है।0 देखता है और सोचता है, "मैं पहले से ही फ़ाइल के अंत में हूँ।" यह ठीक वहीं रहता है।परिणामस्वरूप, पार्सर हेड 1024-बाइट ब्लॉक के अंदर के डेटा को निर्देशों के अगले सेट के रूप में मानता है। यदि वह डेटा एक मान्य TAR हेडर जैसा दिखता है, तो लाइब्रेरी एक दूसरी फ़ाइल को "खोज" और निकाल लेगी जो तकनीकी रूप से संग्रह की वैश्विक संरचना के अनुसार मौजूद नहीं है।
तस्करी पेलोड:
पेलोड 512-बाइट ब्लॉक के अनुक्रम के रूप में तैयार किया गया है। malicious-payload जनरेटर में उपयोग किया गया लेआउट यहाँ दिया गया है:
| ब्लॉक | भूमिका | विवरण |
|---|---|---|
| 1 और 2 | PAX मेटाडेटा | दावा करता है कि अगली फ़ाइल 1024 बाइट लंबी है। |
| 3 | आधार हेडर | benign.txt। महत्वपूर्ण रूप से आकार 0 पर सेट करता है। |
| 4 | तस्करी किया गया हेडर | backdoor.sh। "डेटा" क्षेत्र के अंदर छिपा हुआ। |
| 5 | तस्करी किया गया डेटा | दुर्भावनापूर्ण सामग्री (जैसे, शैल उपनाम)। |
| 6 और 7 | अंत | मानक नल-ब्लॉक समाप्ति। |
क्योंकि मानक उपकरण (जैसे GNU tar) PAX आकार का सही ढंग से पालन करते हैं, वे ब्लॉक 4 और 5 को benign_file.txt से संबंधित हानिरहित बाइनरी डेटा के रूप में देखते हैं। वे ब्लॉक 4 में हेडर को कभी "निष्पादित" नहीं करते।
इस क्रेट में भेद्यता होने का शोषण कैसे किया जा सकता है, किसी संग्रह में तस्करी की गई फ़ाइल क्यों मायने रखती है?
एक हमलावर बिल्ड सिस्टम में दुर्भावनापूर्ण फ़ाइलों की तस्करी करता है। इसे विकास के लिए या CI मशीन पर निकालने पर, वैध बिल्ड फ़ाइलों को अधिलेखित किया जा सकता है, उस मशीन से समझौता किया जा सकता है और यहाँ तक कि बिल्ड सिस्टम को दुर्भावनापूर्ण फ़ाइलों पर हस्ताक्षर करने के लिए धोखा दिया जा सकता है।
एक स्कैनर किसी .tar का निरीक्षण करता है, उसे केवल सही मोड में स्कैन करता है, निकालने पर अवांछित फ़ाइलें मौजूद हो सकती हैं लेकिन स्कैन नहीं की गईं
इस राइटअप से प्रेरित