Chronomaly

Chronomaly هو استغلال نواة لنظام أندرويد/لينكس باستخدام CVE-2025-38352. تمت كتابة الاستغلال خصيصًا لنواة لينكس الإصدار v5.10.157، ولكنه يجب أن يعمل ضد جميع النوى الضعيفة في سلسلة v5.10.x، حيث لا يتطلب أي إزاحات نصية محددة للنواة ليعمل.

لقد غطيت الثغرة بالتفصيل في سلسلة من ثلاث أجزاء من منشورات المدونة، من إثبات المفهوم إلى الاستغلال:

• الجزء 1 - تحليل ثغرة نواة أندرويد في البرية + إثبات المفهوم
• الجزء 2 - توسيع نافذة السباق بدون تصحيح للنواة
• الجزء 3 - كشف Chronomaly

إعداد البناء

تم اختبار هذا الاستغلال فقط ضد نواة لينكس x86_64 الإصدار v5.10.157 التي تعمل في QEMU. طلبت من صديق أن يرسل لي تكوين نواة هاتف Pixel 6a الخاص به لبناء تكوين النواة الخاص بي استنادًا إليه، وهذه هي خيارات التكوين المهمة لهذا الاستغلال (بدأت من تكوين kernelCTF كقاعدة):

• CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n
• CONFIG_PREEMPT=y (استباق كامل، بدون RT)
• CONFIG_SLAB_MERGE_DEFAULT=n
• DEBUG_LIST=n
• BUG_ON_DATA_CORRUPTION=n
• LIST_HARDENED=n

لتعطيل CONFIG_POSIX_CPU_TIMERS_TASK_WORK، يمكنك اتباع الخطوات الموضحة في أول منشور لي في المدونة هنا.

ارجع إلى ملف qemu.sh للحصول على سكريبت تشغيل QEMU الخاص بي. استخدمت 4 أنوية و 3 جيجابايت من الذاكرة العشوائية للاختبار.

معلمات الاستغلال التي ستحتاج لتغييرها

نظرًا لأن الاستغلال يعتمد على مؤقتات المعالج، فهناك معلمتان قد تحتاج لتغييرهما لتكييفه مع بيئتك.

CPU_USAGE_THRESHOLD

تُستخدم هذه المعلمة عند استهلاك وقت المعالج لإطلاق المؤقتات داخل race_func(). يجب ضبطها بحيث:

• لا تُطلق المؤقتات في كل محاولة إعادة (هذا يعني أن CPU_USAGE_THRESHOLD مرتفع جدًا، حيث تُطلق المؤقتات قبل أن يتمكن خيط race_func() من الخروج).
• تُطلق المؤقتات فقط في بعض الأحيان (هذا يعني أن المؤقتات تُطلق أحيانًا قبل خروج الخيط، وأحيانًا أخرى تُطلق أثناء خروجه).

لتحديد ما إذا كانت المؤقتات تُطلق أم لا، أدخل عبارة printf() في كود الاقتراع SIGUSR1 داخل free_func(). إذا رأيت الرسالة تُطبع، فهذا يعني أن المؤقتات أُطلقت.

إذا تم الضبط بشكل صحيح، ستبدأ في رؤية رسائل "الوالد تسابق متأخرًا جدًا / مبكرًا جدًا" في الطرفية.

PARENT_SETTIME_DELAY_US

PARENT_SETTIME_DELAY_US. تُستخدم هذه المعلمة من قبل العملية الأم لضرب نافذة السباق الثانية داخل send_sigqueue() في نفس الوقت مع العملية الابنة. قم بتشغيل الاستغلال، ولاحظ، وقم بتعديلها كالتالي:

• تظهر رسالة "الوالد تسابق متأخرًا جدًا، إعادة ضبط..." كثيرًا – قم بتقليل هذه المعلمة.
• تظهر رسالة "الوالد تسابق مبكرًا جدًا، إعادة ضبط..." كثيرًا – قم بزيادة هذه المعلمة.

من الناحية المثالية، تريد رؤية كل من "تسابق متأخرًا جدًا" و"تسابق مبكرًا جدًا" يُطبعان، وسيعمل الاستغلال في غضون دقيقة واحدة. إذا رأيت واحدًا فقط يحدث أكثر من الآخر، فاضبط وفقًا لذلك.

تحسينات محتملة

في تنفيذي للتقاطع عبر الذاكرة المخبئية، افترضت أن النواة ليست مشغولة جدًا، وأنه لم يكن هناك العديد من تخصيصات struct sigqueue. أضفت تعليقًا في sigqueue_crosscache_preallocs() يشرح ما ستحتاج إلى فعله لتحسين ذلك.

إذا كانت النواة مشغولة حقًا، أو كان هناك بالفعل بعض صفحات slab الخاصة بـ struct sigqueue في القائمة الجزئية لكل معالج / لكل عقدة، فإن التنفيذ الحالي للتقاطع عبر الذاكرة المخبئية في exploit.c سيفشل، ولن يتم إعادة تخصيص uaf_sigqueue / realloc_sigqueue كصفحة بيانات مخزن أنبوب.

اخترت عمدًا عدم جعل التقاطع عبر الذاكرة المخبئية يعمل في نواة مشغولة، حتى لا يُساء استخدام الاستغلال :)

أسئلة

إذا كان لديك أي أسئلة، يرجى الاتصال بي عبر X / تويتر!