CVE-2019-5700

لسوء الحظ، ليس لدي اسم جذاب وذكي لهذه الثغرة. هذه الثغرة بسيطة جداً في الاستغلال. لقد تريثت فيها لفترة طويلة حتى أدركت أنها قد تؤثر على أجهزة أكثر مما اعتقدت في البداية.

النطاق:

تؤثر هذه الثغرة على معالجات Nvidia Tegra t114-t210 التي تشغل صور تمهيد Android، ولكن هناك تمييز مهم يجب توضيحه:

تعتمد أجهزة t114 بشكل أكبر بسبب أداة التحميل الموحدة (unified bootloader) التي تقوم أيضاً بتحميل TOS (TLK - شاشة Nvidia الآمنة)، مما يعني أن أداة التحميل تعمل بالفعل في سياق آمن...

أما في أجهزة t124+، تستخدم Nvidia الآن nvtboot كأداة تحميل مبكرة تقوم بتحميل TOS قبل تنفيذ أداة التحميل المعرضة للخطر، والتي تقوم بعد ذلك بتحميل وتنفيذ النواة. هذا يعني أننا نعمل في سياق غير آمن.

الشرح

لنلقي نظرة على رأس صورة تمهيد Android (الإصدار 1 - قبل Android 9):

struct boot_img_hdr
{
    uint8_t magic[BOOT_MAGIC_SIZE];
    uint32_t kernel_size;  /* size in bytes */
    uint32_t kernel_addr;  /* physical load addr */

    uint32_t ramdisk_size; /* size in bytes */
    uint32_t ramdisk_addr; /* physical load addr */

    uint32_t second_size;  /* size in bytes */
    uint32_t second_addr;  /* physical load addr */

    uint32_t tags_addr;    /* physical addr for kernel tags */
    uint32_t page_size;    /* flash page size we assume */
    uint32_t unused;
    uint32_t os_version;
    uint8_t name[BOOT_NAME_SIZE]; /* asciiz product name */
    uint8_t cmdline[BOOT_ARGS_SIZE];
    uint32_t id[8]; /* timestamp / checksum / sha1 / etc */
    uint8_t extra_cmdline[BOOT_EXTRA_ARGS_SIZE];
};

نرى حقول الصور المألوفة: kernel، ramdisk:

    uint32_t kernel_size;  /* size in bytes */
    uint32_t kernel_addr;  /* physical load addr */

    uint32_t ramdisk_size; /* size in bytes */
    uint32_t ramdisk_addr; /* physical load addr */

وأحياناً tags (التي تُستخدم غالباً لشجرة الجهاز أو ATAGS):

uint32_t tags_addr;    /* physical addr for kernel tags */
uint32_t page_size;    /* flash page size we assume */

ماذا عن الحقل "second"؟

uint32_t second_size;  /* size in bytes */
uint32_t second_addr;  /* physical load addr */

على الرغم من أنني لم أرها تُستخدم في جهاز إنتاجي شخصياً، فإن فهمي هو أن الصورة "الثانية" يمكن استخدامها كمرحلة تحميل ثانية أو كصورة إضافية تحتاج إلى التحميل. من خلال بحثي، فإن معظم أدوات التحميل من الشركات المصنعة الأخرى تتجاهل هذا الحقل لأنه غير مستخدم، أو تطبق فحوصات سلامة على الحجم والعنوان.

أداة التحميل من Nvidia تقوم بالفعل بتطبيق فحوصات سلامة على kernel وramdisk وdtb - حيث جميعها لها عناوين تحميل ثابتة (hardcoded) مما يعني أن عناوين التحميل في الرأس يتم تجاهلها. ومع ذلك، يبدو أن Nvidia ربما نسيت هذه الصورة المهملة في الغالب... حيث تقوم بتحميلها بشكل عشوائي دون أي فحوصات سلامة على العنوان أو الحجم. وهذا صحيح - يمكننا تحميل أي صورة، من أي حجم، إلى أي عنوان ذاكرة يمكن الوصول إليه (كل شيء على t114، الذاكرة غير الآمنة على t124+).

هذا يعني أنه يمكننا تعديل أداة التحميل في الذاكرة بحرية لتناسب احتياجاتنا. سواء كنا نريد تخطي التحقق من التوقيع (الذي يحدث فوراً بعد تحميل جميع الصور)، أو اختطاف تحميل TOS على t114 للحصول على تنفيذ كود في السياق الآمن، أو ببساطة تحميل بعض الشيلكود لتفريغ معلومات حساسة.

الاستغلال:

الاستغلال بسيط مثل إنشاء صورة تمهيد تحتوي على الصورة الثانوية كحمولة/شيلكود مع ضبط الحقول addr/len بحجم حمولتك والمكان الذي تريد وضعه فيه. يمكن أن تكون الصورة صغيرة بقدر 4 بايتات.

بعض الملاحظات الهامة:

في أجهزة t124+، ليس لدينا سياق آمن، حيث قام nvtboot بالفعل بتحميل TOS في مرحلة مبكرة من التمهيد، ثم يسلم التنفيذ إلى أداة تحميل لاحقة (EBT)، ولكن لا يزال بإمكاننا الكتابة بحرية إلى هذه الأداة التحميل المتأخرة في الذاكرة. أداة التحميل المعرضة للخطر هي التي تقوم بتحميل النواة، لذا فهي لا تزال ذات قيمة إذا كنت تريد تنفيذ كود غير موقع تعسفي.

ليس فقط عنوان التحميل غير موثوق، بل أيضاً الحجم، مما يفتح الباب لـ CVE-2019-5699 حيث يمكننا تجاوز متغيرات/مؤشرات مختلفة عن طريق صياغة حقل ضار للثانوية (secondary_size). لكنني لا أستطيع أن آخذ الفضل في ذلك لأنني أدركته بعد فوات الأوان بعد نشر النشرة الأمنية الأولية. ويبدو أيضاً أنه يتطلب عملاً أكثر بكثير...

تدفق التمهيد:

t114:

IROM->BCT->EBT->TOS->KERNEL

t124+ (قد يختلف قليلاً للمعالجات الأحدث ذات 64 بت):

IROM->BCT->NVTBOOT->TOS->EBT->KERNEL

الجدول الزمني:

تم الإبلاغ عن هذه المشكلة في البداية في 29 يوليو 2019 إلى فريق PSIRT الخاص بـ Nvidia (فريق الاستجابة للحوادث الأمنية للمنتجات). وطلبوا بأدب تأجيل الإفصاح حتى يتم إخطار جميع العملاء المتأثرين وتطبيق الإصلاحات - وقد التزمت بذلك بكل سرور. لقد حافظوا على التواصل طوال العملية وكان من الممتع التعامل معهم. اليوم (5 ديسمبر 2019) أنهت Nvidia أخيراً إصدار الإصلاح للكود المتأثر وقامت بنشر نشرتين أمنيتين مختلفتين تعكسان هذه المشكلة، بالإضافة إلى إعطائي الضوء الأخضر للإفصاح.

المراجع:

https://nvidia.custhelp.com/app/answers/detail/a_id/4875

https://nvidia.custhelp.com/app/answers/detail/a_id/4910

شكر خاص:

balika011

beaups

npjohnson

djrbliss/Dan Rosenberg لجعلي أتحقق بدقة من كيفية تحليل أدوات التحميل لرؤوس صور التمهيد