SmmExploit

هذا تقرير واستغلال لـ CVE-2021-26943، ثغرة تصعيد الامتيازات المحلية من kernel إلى SMM في BIOS لجهاز ASUS UX360CA الإصدار 303. تم إصلاح المشكلة في الإصدار 304.

وصف المشكلة

ملخص

يحتوي BIOS لجهاز UX360CA الإصدار 303 على 3 وحدات قابلة للاستغلال تسمح لمهاجم يملك امتياز ring0 باستبدال ذاكرة فيزيائية شبه عشوائية بما في ذلك SMRAM وتنفيذ تعليمات برمجية عشوائية في SMM.

يمكن تحديد هذه الوحدات كما يلي:

الاسم	GUID	SHA256
UsbRt	04EAAAA1-29A1-11D7-8838-00500473D4EB	8A3DEAFD0A688DD4360A65C98E434180152EB43EB2C913C663F13D5709776781
SdioSmm	EA343100-1A37-4239-A3CB-B92240B935CF	4578E1E147D846BB925DF881A2A0A3C3F1E6CD2AE033A8B0F769E5EB42783A0A
NvmeSmm	E5E2C9D9-5BF5-497E-8860-94F81A09ADE0	A9C762B13FC9C4156603D674C6DAEBC4369520D95ACB1D0FA976078D6F7F1003

هذه الوحدات من AMI (مورّد BIOS) وقد تكون موجودة في BIOS لمصنّعين آخرين (OEM).

الثغرات

الوحدات القابلة للاستغلال وواجهات SMI المقابلة لها هي: UsbRt (0x31) وSdioSmm (0x40) وNvmeSmm (0x42). جميع معالجات SMI هذه تقرأ عنوان الذاكرة الفعلية 0x40E للحصول على عنوان للعمل عليه وتكتب بايتًا واحدًا إلى العنوان في حالة حدوث خطأ، حتى لو كان العنوان داخل SMRAM.

على سبيل المثال، يبدو معالج SMI الخاص بـ SdioSmm كما يلي:

EFI_STATUS
EFIAPI
SdioSmm_SwSmi_40h(
  EFI_HANDLE  DispatchHandle,
  CONST VOID  *Context,
  VOID        *CommBuffer,
  UINTN       *CommBufferSize
  )
{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if ( EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0)))
    || userControlled->Offset0_FunctionCode >= 4 )
  {
    userControlled->Offset2 = 7;
  }
  else
  {
    // ...
  }
  return EFI_SUCCESS;
}

يبدو أن هذه المشكلة مطابقة لـ INTEL-SA-00057، التي تم توثيقها بشكل ممتاز في Aptiocalypsis. ومع ذلك، فإن إصدار BIOS 303 لـ UX360CA لا يتضمن إصلاحات لها.

الاستغلال

هذا يسمح لمهاجم لديه حق الوصول للكتابة إلى الذاكرة الفعلية وتعليمة OUT (أي امتيازات ring0) باستبدال محتويات SMRAM عبر الخطوات التالية:

1. تأكد من أن العنوان الفعلي 0x40e هو صفر (وهو الأرجح بالفعل)
2. اكتب عنوانًا من SMRAM، مثل 0x88400000، في العنوان الفعلي 0x104
3. أطلق SMI 0x40
4. يتم تحديث 0x88400000+2 بالقيمة 0x7.

يمكن استخدام هذا لتحقيق تنفيذ تعليمات برمجية عشوائية في SMM كما يلي:

1. ابحث عن عنوان جدول خدمات إدارة النظام (SMST) في SMRAM، عبر الخطوات التالية:
   1. احصل على نطاق العناوين الفعلية لشفرة UEFI زمن التشغيل (runtime) من محتويات قيمة .Raw في HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved
   2. ابحث عن عنوان SMM_CORE_PRIVATE_DATA بفحص التوقيع 'smmc' داخل نطاق العناوين.
   3. يحتوي SMM_CORE_PRIVATE_DATA على مؤشر إلى SMST عند الإزاحة 30h
2. استبدل المؤشر إلى دالة SmmLocateProtocol عند الإزاحة d0h من SMST باستخدام بدائية الكتابة أعلاه. يتم تحديث القيمة إلى 0x07070707.
3. اكتب شيل كود (shellcode) في الذاكرة الفعلية عند 0x07070707
4. أطلق SMI آخر يستدعي Smst->SmmLocateProtocol، مثل SMI 0xdf. سيتم تنفيذ الشيل كود عند 0x07070707 في SMM.

تنفيذ التعليمات البرمجية العشوائية في SMM قد يسمح للمهاجم بتجاوز الإجراءات الأمنية التي يفرضها كل من kernel وhypervisor مثل HVCI، كما هو موضح في تقرير آخر عن ثغرات SMM، وتحقيق الاستمرارية عبر تحديث محتويات فلاش SPI (BIOS).

إثبات المفهوم (PoC)

يُظهر مشروع العرض التوضيحي المرفق استغلالًا ناجحًا، ويُفرغ محتويات سجلات MSR التي لا يمكن الوصول إليها إلا في SMM والعنوان الفعلي لمؤشر EPTP. كما يعدّل كود معالجة CPUID عند خروج VM (VM-exit) في hypervisor الخاص بـ Hyper-V لإرجاع سلسلة تعريف ناقل (vendor string) معدلة.

تم اختبار إثبات المفهوم على Windows build 18362.1256، مع تمكين HVCI وبدون تمكينه.

يمكن مشاهدة تسجيل للاستغلال الناجح على يوتيوب.

تعليمات الاختبار

1. افتح demo.sln في Visual Studio 2019
2. أنشئ الحل (Solution) لإصدار Debug أو Release
3. انسخ ملف demo.sys المُجمّع إلى النظام الهدف (مثل C:\users\user\desktop\demo.sys)

على النظام الهدف:

1. عطّل Secure Boot من إعدادات BIOS، ثم أعد التشغيل
2. فعّل وضع توقيع الاختبار (test signing)، ثم أعد التشغيل

   > bcdedit /set testsigning on
   

3. أنشئ الخدمة لتحميل demo.sys

   > sc create demo type= kernel binPath= C:\users\user\desktop\demo.sys
   

4. شغّل DebugView وفعّل "Capture Kernel" من قائمة "Capture".
5. شغّل العرض التوضيحي

   > sc start demo
   

6. إذا نجح الأمر، سيعرض DebugView قيم سجلات MSR المتعلقة بـ SMM.

   [+] ReportSmramRange: TSEG implied SMRAM: 0x88400000 - 0x88800000
   [-] ReportSmramRange: Exception occurred while accessing SMRR MSR : c0000096
   [+] FindSystemManagementServiceTable: SMM core found at 0x87f1b390 in RT Code
   [+] FindSystemManagementServiceTable: SMST found at 0x887fa710 in SMRAM
   [+] ExploitSmm: Patched SMST->SmmLocateProtocol in SMRAM
   [+] ExploitSmm: Placed SMM shell code
   [+] ExploitSmm: Triggered SMM exploit
   [+] DumpSmmExploitOuput: IA32_SMBASE             = 0x887cd000
   [+] DumpSmmExploitOuput: MSR_SMM_FEATURE_CONTROL = 0x1
   [+] DumpSmmExploitOuput: MSR_SMM_MCA_CAP         = 0xc00000000000000
   [+] DumpSmmExploitOuput: EPT pointer             = 0x10a72001e
   [+] DumpSmmExploitOuput: Patched Hv address      = 0x1004382f0
   [+] ExploitSmm: Successfully executed shell code in SMM. Failing DriverEntry to unload itself
   DriverEntry failed 0xc0000120 for driver \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\demo
   

7. إذا كان Hyper-V قيد التشغيل ونجح تعديل الكود، فسيعيد CPUID 0x4000000 سلسلة تعريف الناقل المعدلة Hv Tampered!.

   > CheckHvVendor.exe
   Executing CPUID(0x40000000) on CPU 0
   Result: Hv Tampered!
   Executing CPUID(0x40000000) on CPU 1
   Result: Hv Tampered!
   Executing CPUID(0x40000000) on CPU 2
   Result: Hv Tampered!
   Executing CPUID(0x40000000) on CPU 3
   Result: Hv Tampered!
   

الحل

الإصلاح هو تجنب استخدام المحتويات التي يتحكم فيها المستخدم تمامًا عندما تشير إلى عنوان داخل SMRAM، كما هو موضح أدناه.

{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if (!EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0))))
  {
    if (userControlled->Offset0_FunctionCode < 7 )
    {
      // ...
    }
    else
    {
      userControlled->Offset2 = 7;
    }
  }
  return EFI_SUCCESS;
}

اعتبارات

نقص الحماية لـ hypervisor

يتبع الإصلاح أفضل الممارسات الصناعية الحالية تمامًا ويمنع هجوم النائب المشوش (confused deputy attack) الذي يؤدي إلى تلف SMRAM.

لاحظ أنه لا يأخذ في الاعتبار مناطق ذاكرة hypervisor. فالمهاجم الذي يعرف عنوان الذاكرة الفعلية الذي تم تحميل hypervisor فيه أو يستخدمه لا يزال بإمكانه طلب SMI لاستبدال كود أو بيانات hypervisor وتحقيق تلفه.

هذه مشكلة شائعة وقديمة وحتى على مستوى التصميم.

نقص الدفاع المتعمق

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

على سبيل المثال، جدول صفحات SMM يستخدم ترابطًا هويًا (identity mapping) بصلاحيات قراءة وكتابة وتنفيذ كاملة، وكانت ميزة SMM_Code_Chk_En غير متاحة. هذا جعل الاستغلال تافهًا. كما لاحظت أن مخزن الاتصال الخاص بـ SMM لا يتم التحقق منه باستخدام SmmIsBufferOutsideSmmValid() كما هو موجود في EDK2، على الرغم من أنني لم أعثر على SMI قابل للاستغلال.