استغلال CVE-2019-9810 لـ Firefox على Windows

CVE-2019-9810 هي ثغرة تم اكتشافها واستغلالها في Pwn2Own 2019 بواسطة Richard Zhu و Amat Cama. تؤثر على محرك JavaScript لمتصفح Mozilla، Spidermonkey، واستُخدمت لتحقيق اختراق المعالج الرسومي (renderer).

تم إصلاح المشكلة في mfsa2019-09 منذ حوالي شهرين.

نظرة عامة على المشكلة

باختصار، تسمح هذه الثغرة باعتبار فحص الحدود (bounds check) زائداً عن الحاجة وتحسينه وإزالته، مما يسمح للكود بالوصول إلى ذاكرة خارج الحدود. تكمن المشكلة نفسها في مرحلة تحليل الأسماء المستعارة (Alias Analysis) في خط أنابيب Ion. توضح الصورة أدناه نتيجة الثغرة في مرحلة تحسين GVN (إزالة فحص الحدود) وتعمل كملخص جيد إذا كان هذا ما تبحث عنه:

إذا كنت ترغب في معرفة المزيد عنها، أوصي بإلقاء نظرة على A journey into IonMonkey: root-causing CVE-2019-9810.

التنظيم

يحتوي المستودع على كود الاستغلال بالإضافة إلى مجموعة من الأدوات التي طورتها سابقاً لاستغلالات blazefox. لقد قمت فقط بتنظيفها وجعلها تعمل مع BigInt. ونتيجة لذلك، يفترض الاستغلال أن دعم BigInt مفعّل في Firefox، ويمكنك القيام بذلك عن طريق تبديل javascript.options.bigint في about:config.

تم اختبار الاستغلال ضد Windows RS5 64-bit ويستهدف بناءً مخصصاً لـ Firefox، لذا لا تتفاجأ إذا كان هناك حاجة إلى بعض العمل لجعله يعمل في مكان آخر :). ومع ذلك، إذا كنت ترغب فقط في تشغيل الاستغلال دون تجميع أي شيء، فقد أعددت متصفحاً محزمناً قمت برفعه في release/firefox-68.0a1.en-US.win64.7z. يتضمن أيضاً شل js.exe بالإضافة إلى معلومات الرموز الخاصة لـ js.exe و firefox.exe و xul.dll.

تعمل عملية الاستغلال بشكل مشابه جداً لاستغلال kaizen.js السابق كما ذُكر أعلاه. تقوم بتوجيه التنفيذ إلى ReflectiveLoader الخاص بـ dll عاكس ينفذ الحمولة:

1. إذا اكتشفت الحمولة أنها استُدعيت بواسطة js.exe، فإنها تقوم ببساطة بإغراق stdout بـ PWN، وتشغيل آلة حاسبة ثم الخروج.
2. إذا تم تشغيلها من المتصفح، تبدأ بحقن نفسها في عمليات Firefox.exe الأخرى. لتحقيق ذلك، يقوم استغلال JavaScript بتمرير مؤشر إلى نسخة الـ dll العاكسة، ويقوم الـ dll العاكس بتعيينها في العمليات الأخرى. بمجرد إنجاز ذلك، ينشئ خيطاً بعيداً على المحمل العاكس (reflective loader) ويأخذ غفوة. السبب في ذلك هو أن الاستغلال قذر جداً في حالته الحالية ولا ينفذ استمرارية العملية. على الرغم من ذلك، لا أعتقد أنه سيكون هناك الكثير من العمل. ربما سأتمكن من فعل ذلك :-).
3. عندما يتم تنفيذ الحمولة من Firefox.exe آخر، تقوم بتعليق داخلي (inline-hook) لدالة xul!nsJSUtils::ExecutionContext::Compile. يتم تنفيذ هذه الدالة عندما تحتاج النصوص البرمجية إلى التقييم بواسطة محرك JavaScript؛ لذا بدا هذا مرشحاً جيداً لما أردت فعله. النسخة المعدلة ببساطة تسبق أي حمولة JavaScript عشوائية من اختيارنا.
4. عندما يتم تثبيت الخطاف، فإنه يعود ببساطة. في هذه المرحلة، تم حقن JavaScript عشوائية في الأصول الأخرى. الحمولة التي أستخدمها هي ببساطة تغيير صورة الخلفية لتلك الأصول إلى صورة موضوع مذكرات مهندس عكسي، بالإضافة إلى إعادة توجيه كل الروابط إلى المدونة :).

في الواقع، هناك مجموعة من التفاصيل الدقيقة الإضافية غير الموصوفة أعلاه، لذا إذا كنت مهتماً فأنت مدعو للبحث عن الحقيقة وقراءة المصادر :).

بناء الحمولة (payload)

لبناء الحمولة، كل ما عليك فعله هو تشغيل nmake من موجه أوامر VS 2017 x64.

CVE-2019-9810\payload>nmake

Microsoft (R) Program Maintenance Utility Version 14.16.27027.1
Copyright (C) Microsoft Corporation.  All rights reserved.

        ml64 /c src\trampoline.asm
Microsoft (R) Macro Assembler (x64) Version 14.16.27027.1
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: src\trampoline.asm
        if not exist .\bin mkdir bin
        type injected-script.js > src\injected-script.h
        cl /O1 /nologo /W3 /D_AMD64_ /DWIN_X64 /DREFLECTIVEDLLINJECTION_CUSTOM_DLLMAIN /Febin\payload.dll src\ReflectiveLoader.c src\ReflectiveDll.cc trampoline.obj /link /DLL /nologo /debug:full /PDBALTPATH:%_PDB%
ReflectiveLoader.c
Generating Code...
Compiling...
ReflectiveDll.cc
Generating Code...
   Creating library bin\payload.lib and object bin\payload.exp
        python jsify_payload.py bin\payload.dll
        move payload.js ..
        1 file(s) moved.
        del *.obj
        del src\injected-script.h
        if exist .\bin del bin\*.exp bin\*.ilk bin\*.lib

يؤدي هذا إلى إنشاء ملف payload.dll / payload.pdb داخل مجلد payload\bin. بالإضافة إلى ملف JavaScript يسمى payload.js يضم الـ dll داخل Uint8Array مع إزاحة المحمل (loader).

بناء Firefox

كتبت هذا الاستغلال ضد بناء محلي لـ Windows متزامن مع معرف المراجعة التالي: 2abb636ad481768b7c88619080cf224b2c266b2d (إذا كنت لا ترغب في بنائه بنفسك، فقد رفعت نسختي هنا: release/firefox-68.0a1.en-US.win64.7z):

$ hg --debug id -i
2abb636ad481768b7c88619080cf224b2c266b2d

واستخدمت ملف mozconfig التالي:

. "$topsrcdir/browser/config/mozconfigs/win64/common-win64"

ac_add_options --disable-crashreporter
ac_add_options --enable-debug-symbols

. "$topsrcdir/build/mozconfig.clang-cl"
. "$topsrcdir/build/mozconfig.lld-link"

# Use the clang version in .mozbuild
CLANG_LIB_DIR="$(cd ~/.mozbuild/clang/lib/clang/*/lib/windows && pwd)"
export LIB=$LIB:$CLANG_LIB_DIR

ac_add_options --enable-js-shell
ac_add_options --enable-jitspew
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff64

مناقشة

على الرغم من أنها كانت مناسبة لغايتي، إلا أنني لست متأكداً من أن xul!nsJSUtils::ExecutionContext::Compile هي الوظيفة المثالية لإدراج نصوص برمجية عشوائية. أنا متأكد من أن قضاء المزيد من الوقت في فهم كيفية عمل الواجهة الأمامية لـ xul قد يؤدي إلى نقطة ربط أفضل.

هناك زاويتان أخريان اكتشفتهما بعد كتابة الاستغلال تمت مناقشتهما في هذا الإدخال في bugzilla: 982974 (المبدأ الأساسي (System principal) لمفسر JavaScript و security.turn_off_all_security_so_that_viruses_can_take_over_this_computer). سيكون من المثير للاهتمام معرفة مدى ملاءمة هذا لـ Firefox اليوم.

ربما قام شخص ما بالفعل بالبحث في هذا الموضوع وفاتني الأمر تماماً. على أي حال، لا تتردد في التواصل معي بأي ملاحظات!

شيء آخر مثير للاهتمام هو استكشاف ما إذا كانت هناك أي طريقة للحصول على آلية استمرارية (persistence) داخل المتصفح. لم أبحث في هذا المجال على الإطلاق ولكن ذلك سيكون رائعاً :).