airineiandrei/tarmageddon-cve-2025-62518-إثبات المفهوم لـ CVE-2025-62518 يوضح تهريب أرشيف tar عبر تحليل رأس PAX في tokio-tar، وإنشاء حمولات ضارة ومستخرج ضعيف لإظهار حقن سلسلة التوريد.
فيديو: https://youtu.be/EYBB4BHsp9E
./outputmalicious.tar بسيطًا مع بعض الأمثلة على المحتوى المهرب، وتشرح التعليقات ما يتم فعله خطوة بخطوة وكتلة بكتلةاستخدم نص إعادة الإنتاج المقدم أو افعل ذلك يدويًا
قم بتشغيل 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
بينما تشغيل الأداة المساعدة tar المقدمة من نظام التشغيل ((GNU tar) 1.35 في هذه الحالة) ينتج:
malicious-payload$ tar -tvf malicious.tar
---------- 0/0 1024 1970-01-01 02:00 benign_file.txt
لاحظ أنها ترى أن حجم الملف هو 1024
بدلاً من ذلك، استخدام astral-tokio-tar 0.5.6 بدلاً من tokio-tar 0.3.1 المهجور يستخرج الأرشيف بشكل صحيح.
CVE-2025-62518 (TARmageddon) هي ثغرة أمنية موجودة في مكتبة Rust tokio-tar (ثغرة Rust 😮). هذا خطأ منطقي في كيفية تحليل رؤوس تنسيق tar، مما يسمح للمهاجم بتهريب الملفات.
الخلل موجود في منطق معالجة رؤوس PAX الموسعة. في أرشيف TAR، هناك أنواع مختلفة من الرؤوس:
USTAR: الرأس القياسي الذي يحتوي على اسم الملف، والأذونات، والحجم.PAX (النوع x): رأس تمديد يستخدم لتوفير بيانات وصفية (مثل حجم ملف كبير جدًا) للملف التالي في الأرشيف.عند وجود رأس PAX، يجب على المحلل حل الحجم الفعلي للملف عن طريق إعطاء أولوية لبيانات PAX على رأس USTAR القياسي.
ولكن لماذا يوجد 2 أنواع من الرؤوس ذات أولويات لما يبدو متشابهًا؟ لأن تنسيق TAR قديم (تم توحيده في 1988)، وUSTAR له حدوده (حجم يصل إلى 8GB، واسم ملف يصل إلى 256 حرفًا). هذه مشكلة لذا تمت إضافة رأس PAX في 2001 للسماح بملفات أكبر وأسماء ملفات أطول.
في الإصدارات الضعيفة من tokio-tar، يتبنى المحلل بشكل صحيح الحجم من رأس PAX لقارئ محتوى الملف، لكنه يستخدم بشكل غير صحيح الحجم من رأس USTAR لتحديد مكان بداية رأس الملف التالي.
جوهر المشكلة هو عدم تطابق المؤشر. عندما يعالج المكتبة الضعيفة ملفًا، فإنها تستخدم "رأسين" داخليين مختلفين لقراءة التدفق:
في الأرشيف العادي، يتفق هذان الرأسان. في TARmageddon، نجبرهما على الاختلاف. عن طريق تعيين حجم PAX إلى 1024 وحجم USTAR إلى 0، نخلق مفارقة:
benign_file.txt.0 في رأس USTAR ويعتقد، "أنا بالفعل في نهاية الملف." يبقى بالضبط حيث هو.وبالتالي، يعامل رأس المحلل البيانات الموجودة داخل كتلة 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، ومسحه فقط بالوضع الصحيح، قد تكون ملفات غير مرغوب فيها موجودة عند الاستخراج ولكن لم يتم مسحها ضوئيًا
مستوحى من هذا الشرح