⚠️ إخلاء المسؤولية

هذا المستودع مخصص لأبحاث الأمن المصرّح بها، وتحليل الثغرات، ومسابقات CTF، والاختبار الدفاعي فقط.

لا تستخدم هذا البحث ضد أنظمة لا تملكها أو لا تملك إذنًا صريحًا باختبارها.

📌 نظرة عامة على الثغرة

🧬 وصف الثغرة

توجد الثغرة في مسار معالجة IPv6 AH6.

يقوم الكود المتأثر بالتلاعب بترويسة التوجيه من خلال:

net/ipv6/ah6.c

على وجه التحديد، يتضمن المنطق المتأثر:

ipv6_rearrange_rthdr()

فشلت الدالة في التحقق بشكل كافٍ من العلاقة بين:

hdrlen

و:

segments_left

وبالتالي يمكن لمهاجم قادر على إرسال حزمة IPv6 مصممة خصيصًا أن يتسبب في قيام النواة بالعمل على ذاكرة خارج حدود ترويسة التوجيه المتوقعة.

قد يؤدي هذا إلى:

Malformed IPv6 packet
        │
        ▼
AH6 / XFRM processing
        │
        ▼
Invalid routing-header state
        │
        ▼
Out-of-bounds memory operation
        │
        ▼
Kernel memory corruption
        │
        ▼
Potential privilege escalation

🔬 السبب الجذري

المشكلة الأساسية هي التحقق غير الكافي من قيمة segments_left في ترويسة التوجيه IPv6 Routing Header.

من الناحية المفاهيمية، يمكن تمثيل الحالة المتأثرة على النحو التالي:

segments_left > available routing-header addresses

يجب على النواة التأكد من أن عدد المقاطع المطلوبة بواسطة ترويسة التوجيه متوافق مع طول الترويسة الفعلي قبل التلاعب ببيانات العنوان المرتبطة.

بدون هذا التحقق، قد تعمل عمليات الذاكرة اللاحقة خارج حدود المخزن المؤقت الصالح.

💥 التأثير الأمني

قد يسمح الاستغلال الناجح لمهاجم يمتلك القدرات/البيئة المحلية المطلوبة بإتلاف ذاكرة النواة.

تشمل العواقب المحتملة:

• تلف ذاكرة النواة
• انهيار النواة
• حجب الخدمة
• تنفيذ تعليمات برمجية عشوائية في النواة
• تصعيد الصلاحيات المحلي
• انتقال محتمل من سياق غير مميز إلى صلاحيات النواة/الجذر

تعتمد قابلية الاستغلال الفعلية على إعدادات النواة، والمساحات/القدرات المتاحة، وظروف بيئية أخرى.

🧪 التحليل التقني

المكوّن المتأثر

net/ipv6/ah6.c

المعالجة ذات الصلة:

AH6
 └── IPv6 Routing Header
      └── ipv6_rearrange_rthdr()

يتضمن السيناريو الإشكالي بيانات وصفية غير متسقة لترويسة التوجيه.

على سبيل المثال، من الناحية المفاهيمية:

hdrlen        → describes a limited number of addresses
segments_left → claims more addresses than are available

يجب رفض هذا التعارض قبل أن تقوم النواة بإعادة ترتيب العناوين.

🩹 تحليل الترقيع

يقدّم الإصلاح في المنبع التحقق من قيمة segments_left في ترويسة التوجيه Routing Header قبل أن تقوم النواة بالعملية المتأثرة.

الالتزام المرتبط في المنبع هو:

7bad4bda74dc4713f398d3b7624ff05478e3a568

xfrm: ah6: validate routing header segments_left

يمكن تلخيص الإصلاح الأمني على النحو التالي:

Before:
    Trust segments_left
          ↓
    Rearrange addresses
          ↓
    Potential OOB access

After:
    Validate segments_left
          ↓
    Reject malformed header
          ↓
    Safe AH6 processing

🖥️ إصدارات النواة المتأثرة

تعتمد الإصدارات المتأثرة على تاريخ النقل العكسي في المنبع والمورّد.

يجب على المستخدمين التحقق من الاستشارة الأمنية الخاصة بتوزيعهم بدلاً من الاعتماد فقط على رقم الإصدار في المنبع.

تتضمن أمثلة إصدارات المنبع المستقرة المُرقّعة:

🔎 الكشف

تحقق من النواة قيد التشغيل:

uname -a

أو:

uname -r

تحقق من معلومات النواة التفصيلية:

cat /proc/version

للأنظمة المبنية على Debian/Kali:

apt-cache policy linux-image-amd64

للأنظمة المبنية على RPM:

rpm -q kernel

غالبًا ما تقوم نوى التوزيعات بنقل إصلاحات الأمان عكسيًا دون تغيير إصدار المنبع بطريقة واضحة. تحقق دائمًا من استشارة/سجل تغييرات المورّد.

🛡️ التخفيف

التخفيف الأساسي هو الترقية إلى نواة تحتوي على الإصلاح الأمني.

Debian/Kali:

sudo apt update
sudo apt full-upgrade

ثم أعد التشغيل:

sudo reboot

تحقق:

uname -r

بالنسبة لأنظمة الإنتاج، راجع الاستشارة الأمنية الرسمية لتوزيعة لينكس قبل تطبيق تحديثات النواة.

🧰 بيئة البحث

البيئة المعزولة الموصى بها:

Host
 │
 ├── Kali Linux
 │
 └── Vulnerable Linux VM
       │
       ├── Debug kernel
       ├── IPv6 enabled
       ├── AH6/XFRM support
       └── Kernel symbols

أدوات التصحيح المفيدة:

gdb
gef
pwndbg
crash
dmesg
pahole
objdump
readelf

تصحيح النواة:

sudo dmesg -w

فحص رموز النواة:

cat /proc/kallsyms

📂 هيكل المستودع

CVE-2026-80844-DirtyAH6/
│
├── README.md
│
├── exploit/
│   ├── poc.c
│   └── Makefile
│
├── analysis/
│   ├── vulnerability.md
│   ├── root-cause.md
│   └── patch-analysis.md
│
├── kernel/
│   ├── vulnerable.patch
│   └── fixed.patch
│
├── docs/
│   └── research-notes.md
│
├── screenshots/
│
└── LICENSE

🧪 إثبات المفهوم

يجب تنفيذ مواد إثبات المفهوم فقط داخل بيئة مختبرية معزولة.

يركز تنفيذ البحث على إظهار حالة ترويسة التوجيه IPv6 Routing Header المشوّهة ومراقبة سلوك النواة الناتج.

سير عمل البحث المتوقع:

Craft malformed IPv6 header
          ↓
Transmit inside isolated lab
          ↓
AH6/XFRM processing
          ↓
Observe kernel behavior
          ↓
Capture dmesg / crash information
          ↓
Compare vulnerable vs patched kernel

مثال على المراقبة:

sudo dmesg -w

يجب أن ترفض النواة المُرقّعة المدخلات المشوّهة دون الوصول إلى عملية الذاكرة المتأثرة.

📊 المتأثر مقابل المُرقّع

🧠 الدرس الأمني الرئيسي

توضح هذه الثغرة لماذا يجب ألا تثق محللات الشبكة في النواة أبدًا بحقول الطول أو العدد التي يوفرها المهاجم.

يجب أن يتبع التحليل الحساس أمنيًا:

Input
 ↓
Bounds validation
 ↓
Relationship validation
 ↓
State validation
 ↓
Memory operation

بدلاً من:

Input
 ↓
Memory operation
 ↓
Validation

حتى التناقض الصغير بين حقلي بيانات وصفية للحزمة يمكن أن يصبح ثغرة أمان ذاكرة على مستوى النواة.

📚 المراجع

• CVE: CVE-2026-80844
• Linux Kernel: IPv6 / XFRM / AH6
• إصلاح المنبع: 7bad4bda74dc4713f398d3b7624ff05478e3a568
• عنوان الإصلاح: xfrm: ah6: validate routing header segments_left