captain-woof/cve-2026-25243إثبات مفهوم مستقر لـ CVE-2026-25243 (Redis RESTORE double-free -> تنفيذ تعليمات برمجية عن بُعد)
تم التحقق على Rocky Linux 8.10، بمعمارية aarch64، مع Redis 8.6.2 وjemalloc 5.3.0.
المرجع: https://www.zeroday.cloud/blog/redis-cve-2026-25243-deep-dive
TLDR؛ استغلال مستقر، يعمل على مجموعة متنوعة من توزيعات أنظمة التشغيل والمعماريات.
ما هذا؟ ثغرة تلف في الذاكرة في Redis تتيح لمهاجم مُصادَق تنفيذ أوامر عشوائية بصلاحيات مستخدم Redis. الهجوم حقيقي في العالم الفعلي ولا يتطلب سوى أمر RESTORE واحد — وهو عملية Redis عادية، وليست مقتصرة على المشرفين. يُثبت هذا الاستغلال تنفيذ تعليمات برمجية كاملًا عن بُعد (RCE) في أقل من ثانية واحدة.
التأثير؟ يمكن لأي عميل Redis مُصادَق تشغيلها، والضرر شامل: تنفيذ تعليمات برمجية عشوائية داخل عملية Redis (التي غالبًا ما تعمل بصلاحيات root في الحاويات). لا توجد طريقة للتخفيف من المخاطر دون تصحيح Redis نفسه.
كيف تعمل في لمحة؟ لدى Redis ميزة تسلسل (RESTORE) تأخذ كتلة من البيانات الثنائية وتعيد بناءها ككائن Redis. تختلف الشيفرة التي تتحقق من تنسيق الكتلة عن الشيفرة التي تلغي تسلسلها في كيفية تحليل تسلسلات معينة — وهو خلل يستغله المهاجم لإفساد الكومة (heap). وبمجرد إفساد الكومة، يكتسب المهاجم القدرة على قراءة وكتابة أي عنوان ذاكرة في عملية Redis، ومن هناك يختطف الحالة الداخلية للخادم لتنفيذ أمر قشرة (shell).
تقنية الاستغلال الحقيقية: هذه ليست مجرد انهيار بسيط. إنها سلسلة استغلال للكومة (heap): إفساد ← تداخل ← قراءة/كتابة عشوائية ← تسريب معلومات ← العثور على بنية الخادم ← اختطاف مؤشرات الدوال ← RCE. يعمل الاستغلال عبر 9 مراحل ويتطلب تسريب عناوين متعددة وقت التشغيل، وفحص بنى ثنائية، واكتشاف التزايُف (memory aliasing). ما يجعله يعمل عبر معماريات مختلفة (x86-64 وaarch64 وغيرها) أن جميع العناوين تُسرَّب من الهدف نفسه، وليست مفترضة.
CVE-2026-25243 هي زوج من ثغرات التحرير المزدوج (double-free) يمكن الوصول إليها من أمر RESTORE مُصادَق واحد. يلغي RESTORE key ttl <serialized-value> تسلسل كتلة RDB يتحكم بها المهاجم؛ تعيش كلتا الثغرتين في الفجوة بين المُتحقِّق (validator) الذي يفحص الكتلة والمحوِّل (converter) الذي يجسّدها.
الخلل 1 — تحويل zipmap القديم (CWE-415، المسار الذي يستخدمه هذا الاستغلال). يختلف مُتحقِّق zipmap (zipmapValidateIntegrity()) عن المحوِّل (zipmapNext()) حول ترميز طول زائد عن الحاجة. يمكن قانونيًا كتابة الطول الصغير 4 بالصيغة الطويلة المكونة من خمسة بايتات FE 04 00 00 00. يستهلك المُتحقِّق عددًا من البايتات، بينما يستهلك المحوِّل عددًا آخر — أي فقدان تزامن في التحليل بمقدار 4 بايتات. لذلك يمشي المحوِّل عبر بنية مختلفة عن تلك التي تم التحقق منها، فتفشل lpSafeToAdd() بعد أن أُدرج الحقل بالفعل في القاموس، ويحرر مسار التنظيف الحقل مرتين: مرة عبر dictRelease() ومرة أخرى عبر sdsfree().
الخلل 2 — تحميل PEL لمستهلك الدفق (CWE-415). في rdbLoadStreamConsumersGroup()، تؤدي PEL لمستهلك تحتوي على معرّف إدخال مكرر إلى فشل استدعاء raxTryInsert() الثاني، الذي يستدعي streamFreeNACK() على كائن streamNACK لا يزال مملوكًا لـ PEL العام للمجموعة. فيُحرَّر مرتين. (يمكن اختياره باستخدام --vuln-type stream.)
كل خلل من هذين يمنح المهاجم قطعة ذاكرة حرة ومُشارًا إليها في الوقت نفسه — نقطة البداية الكلاسيكية لاستغلال تداخل الكومة (heap-overlap).
التأثير: عميل Redis مُصادَق (بدون صلاحيات إدارية؛ RESTORE أمر بيانات عادي) يكتسب تنفيذ تعليمات برمجية عشوائية بصلاحيات مستخدم redis — أي root في صورة الحاوية الافتراضية.
تسع مراحل، كل واحدة منها تحوّل بدائية أضعف إلى أخرى أقوى:
| المرحلة | البدائية المكتسبة | الآلية |
|---|---|---|
| 0 | ملف تعريف الهدف | INFO server / INFO memory → الإصدار، المعمارية، التوزيعة، pid، مسار الملف التنفيذي، وقت البدء، المخصّص |
| 1 | تحرير مزدوج | أمر RESTORE لبيانات zipmap (أو stream) مشوّهة |
| 2 | مفتاحان يتشاركان نفس الذاكرة | رشّ مفاتيح علامة على القطعة المحرَّرة، وكشف التزايُف، ثم الكتابة فوق ترويسة SDS لأحد المفتاحين عبر توأمه لتضخيمها إلى نافذة "memview" بحجم 1 ميجابايت |
| 3 | قراءة/كتابة عشوائية | العثور على كائن INCRBYFLOAT داخل memview واختطاف حقل ptr الخاص به: GETRANGE/SETRANGE على ذلك المفتاح يقرآن/يكتبان الآن أي عنوان |
| 4 | مؤشر الصورة | فحص الكومة بالاتجاه الخلفي بحثًا عن قيمة داخل صورة redis-server |
| 5 | &server | النزول حتى ترويسة ELF، وفحص program headers، وتفريغ القطاع القابل للكتابة، ومطابقة server.pid |
| 6 | حمولة في الذاكرة | كتابة "/bin/sh", "-c", "<cmd>" مع مصفوفة argv داخل memview |
| 7 | بنية مختطفة | استبدال server.executable و server.exec_argv و server.enable_debug_cmd |
| 8 | RCE | DEBUG CRASH-AND-RECOVER → restartServer() → execve(server.executable, server.exec_argv, environ) |
python3 exploit.py --host 127.0.0.1 --port 6379 \
--password mypassword --cmd 'id > /tmp/pwned123.txt'
التحقق:
cat /tmp/pwned123.txt
# uid=0(root) gid=0(root) groups=0(root)
نقطة البداية: كان الاستغلال مقتصرًا على x86-64 وكان يفشل في المرحلة 3 على هدف aarch64. الحالة النهائية: RCE كامل على aarch64 / Rocky Linux 8.10 في أقل من ثانية واحدة، بـ 116 أمر Redis.
أ) البصمة الرقمية للهدف وقت التشغيل (جديد، المرحلة 0). لم يعد يُفترض أي شيء بشأن الهدف. يعطي INFO server + INFO memory إصدار Redis، ومعمارية وحدة المعالجة (من سطر os:)، وعائلة التوزيعة (مستنتجة من gcc_version)، والمخصّص (allocator)، والأهم من ذلك — ثلاث نقاط تحقق مرجعية: process_id و executable و stat_starttime بالضبط (server_time_usec/1e6 - uptime_in_seconds). تقارن المراحل اللاحقة قيمها بهذه النقاط بدلًا من التخمين.
ب) تخطيط ذاكرة مستقل عن المعمارية. استُبدلت الثوابت الأربعة المثبتة لمعمارية x86-64 (BINARY_ADDR_MIN/MAX، HEAP_ADDR_MIN/MAX) بجدول لكل معمارية (ARCH_PROFILES) يغطي x86_64 وaarch64 (بمساحتي العناوين الافتراضية 39 و48 بت) وriscv64 وppc64le وs390x، مع مواضع ET_EXEC وET_DYN لكل منها، بالإضافة إلى بديل عام واسع لأي شيء غير مُدرج. كان هذا هو السبب الفعلي لفشل الاستغلال على هذا الهدف: المؤشر المُسرَّب 0x0000ffff8a5fdf32 هو عنوان mmap سليم تمامًا لمعمارية aarch64 رفضه فحص النطاق الخاص بـ x86-64.
ج) التحقق من التسريب عبر الإجماع (المرحلة 3). بدلًا من الوثوق بنافذة كومة مثبتة، يجمع الفحص الآن كل كائن 1337.NNNNNN صالح بنيويًا داخل memview، ويتطلب أن يشتق اثنان منها على الأقل نفس عنوان قاعدة memview (ptr - offset_of_value). عمليًا، يتفق 502 مرشحًا، وهذا دليل لا يمكن لأي جدول نطاقات تقديمه. ثم يقوم المؤشر المؤكَّد بمعايرة نافذة الكومة وقت التشغيل. كما نُقل التحقق من التنسيق إلى ما قبل اختبار التحكم بالكتابة (المكلف في الجولات).
د) حد فحص المرحلة 3 (إصلاح خلل). كان الفحص يمتد إلى 10 ميجابايت مثبتة بينما حجم memview هو 1 ميجابايت، فكان يقرأ ما بعد النهاية، ويتلقى ردًا فارغًا ويتوقف مع رسالة AssertionError: Empty data from memview. أصبح الآن محدودًا بقيمة STRLEN الحقيقية لـ memview، ويقرأ 256 كيلوبايت لكل جولة بدلًا من 64 كيلوبايت، وأُزيلت حلقة إعادة المحاولة مع النوم غير المجدية 6×1 ثانية.
هـ) إعادة كتابة المرحلة 5: موجَّهة عبر ELF، خالية من الانهيار (الأهم). كان التنفيذ القديم يفحص للأمام من مؤشر صورة، مجربًا العناوين وقارئًا أي طول تدّعيه ترويسة SDS تالفة. على هذا الهدف، مشى خارج نهاية القطاع القابل للقراءة فقط مباشرة إلى الفجوة غير المعيّنة عند 0x715000 وقتل الخادم (SIGSEGV في getrangeCommand → memcpy). لا يمكن جعل الفحص الأعمى آمنًا. البديل حتمي:
العثور على قاعدة الصورة. النزول صفحةً صفحة من أدنى مؤشر صورة مُسرَّب. الفحص بلا كلفة: أول خمسة بايتات من كل صورة ELF64 هي 7f 45 4c 46 02، وتأخذ sdslen() بايت الأعلام من ptr[-1] — لذا فإن توجيه الكائن المختطَف إلى base+5 يجعل e_ident[EI_CLASS]=0x02 هو بايت الأعلام، أي SDS_TYPE_16، الذي يكون طوله هو uint16 عند base+0 = 0x457f (0x7f45 بترتيب البايتات الكبير). قيمة STRLEN البالغة 17791 تمامًا هي توقيع ELF. لا حاجة إلى نسخة محلية من الملف الثنائي — تُقرأ الترويسة من ذاكرة الهدف نفسه.
فحص program headers للحصول على الحدود الدقيقة وقت التشغيل لكل قطاع PT_LOAD (مع معالجة إزاحة التحميل ET_DYN للأهداف من نوع PIE). كل قراءة لاحقة تُقيَّد بتعيين فعلي للذاكرة، لذا أصبح الانهيار عند الفجوة غير المعيّنة مستحيلًا بنيويًا.