offline-ant/tcp2kaslrCVE-2026-98432: خادم IPv4 TCP عادي معرّض للثغرة، وMPTCP ليس هو المُحفّز. مُحفّز الخطأ والأدلة والتحليل.
كُتب بواسطة DeepSeek.
خادم IPv4 TCP عادي معرّض للثغرة. MPTCP ليس هو المُحفِّز.
قمنا ببناء Linux 6.18.55 من tarball الإصدار وجعلنا النواة تقرأ ذاكرة
مُحرَّرة على مستمع IPPROTO_TCP عادي. أبلغ KASAN عن ذلك مرتين. لم يتم
إنشاء أي مقبس MPTCP قط، وفي إحدى التجارب كانت MPTCP مُعطَّلة في النواة.
الثغرة نفسها تجعل النواة تنسخ بايتات من كائن مُحرَّر إلى الرد الذي ترسله مرة أخرى. هذا هو الأساس الذي يحتاجه كسر KASLR، وقد لاحظنا حدوثه في عمل غير منشور. لم نقم ببناء تسريب لعنوان النواة، ولم نُثبت كتابة.
ما تم إثباته هنا، بالكود والسجلات: أن use-after-free حقيقي، وأن TCP القياسي يصل إليه، وأن الإصلاح في المنبع يوقفه.
| النواة | MPTCP | المحاولات | الوقت | النتيجة |
|---|---|---|---|---|
| 6.18.55، بدون إصلاح | غير مستخدم | 134,955 | 34 ث | KASAN use-after-free |
| 6.18.55، بدون إصلاح | مُعطَّل | 191,431 | 80 ث | KASAN use-after-free |
| 6.18.55 + إصلاح | غير مستخدم | 439,316 | 411 ث | نظيف |
صعبة جدًا. مع KASAN يكون القارئ بطيئًا، لذا تظهر الثغرة خلال بضع مئات الآلاف من المحاولات. على نواة عادية فهي أندر بكثير: عبر حوالي 48 مليون محاولة رأينا حدثين، وكلاهما خلال نفس الخمس ثوانٍ.
هذا قليل جدًا لذكر معدل. أقصى ما سنَدّعيه هو حدّ تقريبي قدره
1e-7 لكل محاولة، وحتى ذلك هو أفضل حالة، لأن أداة الاختبار لدينا تفرض
الحزمتين على وحدتي معالجة (CPU) وبطاقة شبكة حقيقية عادةً ترسل تدفقًا واحدًا إلى
وحدة معالجة واحدة.
لذا فإن تشغيلًا نظيفًا لا يعني نواة آمنة. اقرأ القسمين 5.2
و6 من ANALYSIS.md قبل اقتباس أي رقم.
يستقبل خادم TCP حزمة SYN. تحمل حزمة SYN خيار IPv4 (Record Route أو Timestamp). تحفظ النواة تلك الخيارات على مقبس الطلب.
تصل حزمة SYN ثانية لنفس الاتصال. تبني النواة لها SYNACK وتقرأ الخيارات المحفوظة.
في الوقت نفسه تنتهي المصافحة. يحصل المقبس الابن على نفس
المؤشر، وليس نسخة. يُغلق الخادم الابن، وتُحرِّر النواة
الخيارات باستخدام kfree() العادي.
لا يزال كود SYNACK يقرأ تلك الذاكرة. هذا هو use-after-free. القراءة نفسها هي ما يضع البايتات المُحرَّرة في الحزمة.
إنه مُحفِّز ثغرة، وليس استغلالًا. لا يسرّب عناوين النواة، ولا يكتب في ذاكرة النواة، ولا يحصل على صلاحيات الجذر. إنه يُظهر النواة وهي تقرأ ذاكرة مُحرَّرة؛ KASAN هو الحكم.
يتوقف المستودع عند هذا الحد عن قصد. تم العمل على المراحل اللاحقة بشكل خاص وهي غير منشورة هنا.
scripts/get-kernel.sh # fetch 6.18.55, sha256 checked, into linux/
scripts/build-kernel.sh vuln # KASAN kernel, no fix
scripts/build-kernel.sh patched # KASAN kernel, with the fix
scripts/build-harness.sh # builds harness/init + initramfs
scripts/run.sh vuln 90 selftest # checks the wiring only
scripts/run.sh vuln 600 # expect a KASAN report
scripts/run.sh patched 600 # expect nothing
تحتاج إلى gcc وmake وbison وflex وbc وqemu-system-x86_64. يساعد KVM كثيرًا.
تستهلك الآلة الافتراضية 2 GB من الذاكرة العشوائية و8 وحدات vCPU.
قد لا يُظهر تشغيل واحد شيئًا. هذا ليس دليلًا على نواة آمنة. شغّله
عدة مرات، واقرأ التحذيرات في ANALYSIS.md.
لا تثق بسلسلة الإصدار. انظر إلى الشيفرة في الملف الثنائي.
scripts/check-free-sites.py
يجد الموقعين الحرّين في النواة قيد التشغيل ويُظهر أي دالة يستدعيها كل منهما: kfree (سيئ) أو kvfree_call_rcu (مُصلَح).
على الجهاز الذي كُتب هذا عليه (6.18.59_1) يستخدم الموقعان kvfree_call_rcu، لذا فإن تلك النواة مُصلَحة.
يكون المضيف معرّضًا إذا تحققت الشروط الثلاثة جميعًا:
المُهاجم يتحكم في النقطة 2. لذا فإن معظم خوادم الإنترنت معرّضة، و"نحن لا نستخدم MPTCP" لا يساعد.
ملاحظتان:
accept_source_route=0 لا يحميك. فهو يحجب التوجيه المصدري فقط، وليس Record Route أو Timestamp.| المسار | الوصف |
|---|---|
ANALYSIS.md | التقرير الكامل: مسار المصدر، والمنهجية، والنتائج، والحدود |
harness/ | مُحرّض الخلل الذي يعمل كـ /init في QEMU |
patches/ | الإصلاح من المنبع، المستخدم في بناء التحكم |
scripts/ | مساعدات الجلب والبناء والتشغيل والفحص |
evidence/ | تقارير KASAN، وسجلات التشغيل، ومقارنة البناء |
نوى الاختبار فقط، وفقط تلك التي تملكها. لا ينبغي توجيه أي شيء هنا إلى أنظمة لا تتحكم بها.
MIT لكودنا ونصّنا. يحتوي patches/ على إيداع في نواة Linux ويبقى تحت GPL-2.0. انظر LICENSE.