CVE-2026-25243 — تحرير مزدوج في zipmap عبر RESTORE في Redis → تنفيذ كود عن بُعد

الخلاصة. حمولة DUMP تالفة تُمرَّر إلى RESTORE تُطلق تحريرًا مزدوجًا في الكومة داخل محمّل hash-zipmap القديم في Redis. مع jemalloc الافتراضي يكون التحرير المزدوج صامتًا (يظل الخادم يعمل)، مما يحوّله إلى وسيلة التباس أنواع قابلة للتحكم. يحوّل هذا المستودع ذلك إلى تنفيذ كود عن بُعد مع تفعيل ASLR — يستدعي عامل Redis system("<attacker string>") ويستمر في تقديم الخدمة. ليست حجب خدمة.

# default Redis (DEBUG disabled), ASLR on — the most self-contained exploit (NO libc offsets):
$ python3 exploits/poc_rce_aslr_pie_rop.py --cmd "id > /tmp/pwned_pie 2>&1"
[*] self-cal: blob_base=0x7f352d800009 blob_robj=0x7f353286b8d8 pie_base=0x557ea9149000  (NO libc)
[*] fake dictType F=0x7f352e013c36  g1=0x557ea93cca87 execve=0x557ea91cee80
$ cat /tmp/pwned_pie
uid=0(root) gid=0(root) groups=0(root),...    # <- execve("/bin/sh","-c",<cmd>) as the redis process

التسريب الذي يتجاوز ASLR يستخدم بدون DEBUG — يقرأ عنوان إغلاق C الخاص بلغة Lua redis.call (EVAL 'return tostring(redis.call)')، نفس التقنية ذاتية الاحتواء والخالية من DEBUG كما في استغلالنا السابق لـ Redis. اشتقاق blob_base/blob_robj وقاعدة PIE يتم لاحقًا في وقت التشغيل من القراءة الزائدة (بدون إزاحة ثابتة). إنهاء PIE-ROP يستدعي execve@plt عبر JOP stack-pivot، لذا يستخدم صفر عناوين libc — الثوابت الوحيدة المرتبطة بالبناء هي إزاحات أدوات نسبية لـ PIE تُقرأ من ثنائي redis-server، تمامًا مثل جدول أدوات خاص بكل بناء في استغلالنا السابق لـ HLL. تم التحقق من uid=0(root)، مع تفعيل ASLR، 8/8، على خادم افتراضي معطّل DEBUG.

يتوفر نمطان للإنهاء. poc_rce_aslr_pie_rop.py (أعلاه) هو الأكثر اكتمالًا ذاتيًا — بدون libc، معايرة كاملة ذاتيًا — لكن execve يستبدل العامل (استخدم --cmd لصدفة عكسية؛ الأفضل لصدفة حقيقية). poc_rce_aslr_selfcal.py يُبقي العامل حيًا (system() ينشئ fork) مقابل إزاحتين خاصتين بإصدار libc. اختر بحسب حاجتك إلى بقاء الخادم.

الثغرة

يُزيل RESTORE key 0 <DUMP-payload> تسلسل كائن مُسلسَل. بالنسبة للنوع القديم RDB_TYPE_HASH_ZIPMAP (0x09)، يختلف المحقِّق والمحوِّل حول عدد البايتات التي يشغلها حقل الطول:

• يسير zipmapValidateIntegrity() باستخدام الحجم المشفَّر الفعلي (5 للبادئة الطويلة 0xFE)؛
• يستخدم zipmapNext() أثناء تحويل zipmap → listpack بايتًا واحدًا لأي طول مفكوك < 254.

الطول القصير المكتوب بالصيغة الطويلة ذات 5 بايتات يجتاز التحقق لكنه يجعل zipmapNext() يتخطى بطريقة خاطئة 4 بايتات. ينتج عن التخطي الخاطئ نفسه نتيجتان: قراءة زائدة من الكومة (zipmap.c) — وفي Redis فقط — تحرير مزدوج في الكومة داخل محمّل hash-zipmap في rdb.c:

sds field = sdstrynewlen(fstr, flen);
if (!field || dictAdd(dupSearchDict, field, NULL) != DICT_OK || !lpSafeToAdd(lp, flen + vlen)) {
    dictRelease(dupSearchDict);   // (1) dictAdd took ownership of `field` -> freed here
    sdsfree(field);               // (2) freed AGAIN  -> double-free

يحمي Valkey هذا الأمر (if (!field_added) sdsfree(field))؛ بينما لم يفعل Redis الرئيسي ذلك، لذا فالتحرير المزدوج خاص بـ Redis فقط. يرفض الإصلاح الطول القصير المشفَّر بصيغة طويلة ويعيد ترتيب فحوصات وقت التحميل.

سلسلة الاستغلال (Redis 8.6.2, x86-64, jemalloc, PIE/NX/partial-RELRO)

silent double-free  ->  type-confusion overlap  ->  arbitrary pointer-forge
   ->  forge a hashtable hash's  dict->type  to a fake dictType
   ->  HGET hd "<field>"   ==   dictFind -> type->hashFunction(field)
      libc path  (selfcal): hashFunction = &system            -> system("<cmd>")   (worker survives)
      PIE path   (pie_rop): hashFunction = JOP-pivot g1, field = ROP chain
                            -> leave;ret pivots rsp onto the field
                            -> execve("/bin/sh","-c","<cmd>")  via execve@plt        (no libc, no DEBUG)

يُزرع dictType المزيّف داخل سلسلة بحجم 16 ميغابايت (SETRANGE) عند الإزاحة الوحيدة التي تتطابق فيها البايتات المنخفضة لعنوانها مع ترويسة sds لسلسلة المهاجم. تُهزم ASLR بالكامل في وقت التشغيل:

• system — تسريب واحد لمؤشر من الكومة. المسار الموصى به هو خالٍ من DEBUG: عنوان إغلاق C الخاص بـ Lua redis.call (EVAL 'return tostring(redis.call)') — نفس التسريب ذاتي الاحتواء الذي يستخدمه استغلالنا السابق لـ Redis. تقع مناطق jemalloc على إزاحة ثابتة من libc، لذا system = leaked_robj + Δlibc + system_off. (DEBUG OBJECT مجرد تيسير مخبري عندما يكون السكربت معطلًا بينما DEBUG مفعّل — الإعداد الأندر.)
• عنوان كتلة الـ 16 ميغابايت (mmap عشوائي بشكل مستقل) — يُقرأ عبر القراءة الاعتباطية الخاصة بالثغرة: زوّر قاموس SET بحيث يكون عضوه sds من نوع SDS_TYPE_32 بحجم 107 كيلوبايت، وتقوم SMEMBERS بقراءة زائدة عن الكومة المجاورة، ويُقرأ robj.ptr الخاص بالكتلة عند إزاحته المعروفة.

انظر WRITEUP.md للتحليل الكامل خطوة بخطوة ولتفاصيل jemalloc / Redis-8.x المكتسبة بصعوبة (حدود class-64، وسم إدخالات القاموس، mstr لحقول الهاش، التوسيع المسبق لفضاء المفاتيح).

المختبر

docker build -t cve-2026-25243 .
# stock (jemalloc) demo — DoS-or-not? shows the type confusion (no tooling):
docker run --rm -p 6379:6379 cve-2026-25243

# full chain — DEFAULT config (DEBUG disabled), the recommended exploit:
sysctl -w kernel.randomize_va_space=2            # ASLR ON
redis-server &                                   # DEBUG is off by default
python3 exploits/poc_rce_aslr_selfcal.py --host 127.0.0.1 --port 6379 --cmd "id > /tmp/pwned 2>&1"

تسريب هزيمة ASLR (بدون DEBUG)

يتبع تسريب مؤشر الكومة الأساسي نفس النهج المتبع في استغلالنا السابق لـ Redis: تسريب عنوان إغلاق C الخاص بـ Lua redis.call عبر EVAL 'return tostring(redis.call)'. سكربت Lua مفعّل افتراضيًا؛ بينما DEBUG معطّل افتراضيًا (enable-debug-command no) — لذا فإن تسريب Lua هو الأساسي الواقعي، وDEBUG OBJECT (poc_rce_aslr.py) مجرد تيسير مخبري. بعدها يقوم poc_rce_aslr_selfcal.py بشتقاق blob_base وblob_robj في وقت التشغيل من القراءة الزائدة (بمسح توقيع robj لكتلة 16 ميغابايت)، لذلك يكفي أن تكون DLUA/DFOBJ قريبة.

بالنسبة لإنهاء system، فإن القراءة الزائدة من الكومة الصغيرة لا تحتوي على مؤشرات libc، لذا لا يمكن اشتقاق libc ذاتيًا — يحتفظ poc_rce_aslr_selfcal.py بإزاحتين لإصدار libc (DLIBC, SYSTEM_OFF). أما إنهاء poc_rce_aslr_pie_rop.py فيزيل هذا الاعتماد كليًا: القراءة الزائدة نفسها تحمل مؤشرات PIE (يظهر dictType مشترك بشكل متكرر)، لذا تُعاير قاعدة PIE ذاتيًا كـ most-common-PIE-value − DICTTYPE_OFF، وتنتهي السلسلة بـ execve@plt عبر JOP stack-pivot (mov rbp,rdi; call *0x8(rax) → leave;ret يدير rsp نحو حقل HGET الذي يتحكم به المهاجم، وهو نفسه سلسلة ROP لـ execve("/bin/sh","-c",<cmd>)). الثوابت الوحيدة المرتبطة بالبناء هي إزاحات الأدوات النسبية لـ PIE والتي تُقرأ من — استخرجها لكل هدف باستخدام /، تمامًا كما يربط استغلالنا السابق لـ HLL جدول أدوات بكل ELF Build-ID. لا يُستخدم أي عنوان libc.

لقطات الشاشة

screenshots/05-pie-rop-libc-free.png (المعايرة الذاتية NO libc + uid=0، التشغيل الأكثر اكتمالًا ذاتيًا)، 01-rce-aslr-on.png (اللقطة الحاسمة uid=0)، 02-reliability.png (5/5)، 03-exploit-chain.png (الكود)، و04-debug-free-selfcal.png (تشغيل system الخالي من DEBUG وذاتي المعايرة على Redis افتراضي).

التأثير والإصدارات المتأثرة

• عن بُعد، دون امتياز خاص. RESTORE أمر عادي — على Redis غير مُصادَق/مكشوف (بدون requirepass) يمكن لأي عميل متصل تنفيذه؛ على مثيل مصادَق يمكن لأي مستخدم لا يملك منع -restore في ACL. نفس ملف الوصول كأوامر هياكل البيانات المستخدمة في استغلالات Redis الأخرى.
• مؤكَّد: تحرير مزدوج صامت في الكومة، التباس أنواع، قراءة اعتباطية لذاكرة العملية (تسريب معلومات ينقل المفاتيح/الأسرار/المؤشرات)، وتنفيذ كود عن بُعد (هذا المستودع).
• المتأثر: Redis < {6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3} — أي 6.2.x حتى 8.x الحالية؛ Valkey يتأثر بـ DoS/قراءة زائدة فقط (حارس field_added يمنع التحرير المزدوج).

التخفيف

قم بالترقية إلى إصدار مصحح. إذا تعذّر ذلك: قيّد RESTORE (ACL … -restore)، ولا تعرِّض Redis أبدًا دون مصادقة، وعطّل DEBUG.

بحث أمني مُصرَّح به، نُشر لتوعية المدافعين. لا تشغّله ضد أنظمة لا تملكها أو لا تملك إذنًا صريحًا لاختبارها.