0vercl0k/cve-2019-9810Windows 64-bit पर Firefox के लिए CVE-2019-9810 एक्सप्लॉइट।
CVE-2019-9810 एक कमजोरी है जिसे Pwn2Own 2019 में Richard Zhu और Amat Cama द्वारा खोजा और शोषित किया गया था। यह Mozilla के JavaScript इंजन, Spidermonkey को प्रभावित करता है और रेंडरर समझौता प्राप्त करने के लिए उपयोग किया गया था।
यह समस्या लगभग दो महीने पहले mfsa2019-09 में ठीक कर दी गई थी।
संक्षेप में, यह बग एक सीमा जांच को अनावश्यक पाए जाने और अनुकूलित करने की अनुमति देता है, जिससे कोड सीमा से बाहर मेमोरी तक पहुंच सकता है। समस्या स्वयं Ion की पाइपलाइन के Alias Analysis पास में निहित है। नीचे दी गई तस्वीर GVN ऑप्टिमाइज़ेशन (सीमा जांच का अनुकूलित किया जाना) पास में बग के परिणाम को उजागर करती है और एक अच्छा सारांश प्रदान करती है यदि आप यही खोज रहे हैं:
यदि आप इसके बारे में अधिक जानना चाहते हैं, तो मैं A journey into IonMonkey: root-causing CVE-2019-9810 देखने की सिफारिश करूंगा।
रिपॉजिटरी में कोड के साथ-साथ कई शामिल हैं जिन्हें मैंने पहले अपने शोषणों के लिए विकसित किया था। मैंने उन्हें बस सुधारा और के साथ काम करने योग्य बनाया। परिणामस्वरूप, शोषण मानता है कि फ़ायरफ़ॉक्स में के लिए समर्थन चालू है, जिसे आप में को टॉगल करके कर सकते हैं।
about:configjavascript.options.bigint
शोषण का परीक्षण विंडोज RS5 64-बिट पर किया गया है और यह फ़ायरफ़ॉक्स के एक कस्टम बिल्ड को लक्षित करता है, इसलिए यदि इसे कहीं और काम करने के लिए थोड़ा काम करना पड़े तो आश्चर्य न करें :)। हालांकि, यदि आप बिना कुछ संकलित किए शोषण चलाना चाहते हैं, तो मैंने एक पैकेज्ड ब्राउज़र तैयार किया है जिसे मैंने release/firefox-68.0a1.en-US.win64.7z पर अपलोड किया है। इसमें js.exe शेल के साथ-साथ js.exe, firefox.exe और xul.dll के लिए निजी प्रतीक जानकारी भी शामिल है।
शोषण प्रक्रिया मेरे पिछले kaizen.js शोषण के समान ही काम करती है जैसा ऊपर बताया गया है। यह एक रिफ्लेक्टिव डीएलएल के ReflectiveLoader पर निष्पादन भेजता है जो पेलोड को लागू करता है:
js.exe द्वारा आमंत्रित किया गया है, तो यह बस stdout पर PWN भेजता है, एक कैलकुलेटर खोलता है और बाहर निकलता है।Firefox.exe प्रक्रियाओं में इंजेक्ट करके शुरू करता है। इसे प्राप्त करने के लिए, Javascript शोषण रिफ्लेक्टिव डीएलएल कॉपी के लिए एक पॉइंटर पास करता है, और रिफ्लेक्टिव डीएलएल इसे अन्य प्रक्रियाओं में मैप करता है। एक बार यह पूरा हो जाने पर, यह रिफ्लेक्टिव लोडर पर एक रिमोट थ्रेड बनाता है और एक झपकी लेता है। इसका कारण यह है कि शोषण अपनी वर्तमान स्थिति में काफी गंदा है और प्रक्रिया निरंतरता को लागू नहीं करता है। हालांकि, इस बिंदु पर मुझे नहीं लगता कि यह बहुत काम होगा। शायद मैं इसे कर लूँ :-)।Firefox.exe से निष्पादित होता है, तो यह xul!nsJSUtils::ExecutionContext::Compile फ़ंक्शन को इनलाइन-हुक करता है। यह फ़ंक्शन तब निष्पादित होता है जब स्क्रिप्ट को JavaScript इंजन द्वारा मूल्यांकित करने की आवश्यकता होती है; इसलिए यह मेरे इच्छित कार्य के लिए एक अच्छा उम्मीदवार लगा। हुक किया गया संस्करण बस हमारी पसंद के एक मनमाना JavaScript पेलोड को प्रीपेंड करता है।वास्तव में, ऊपर वर्णित की तुलना में और अधिक सूक्ष्म विवरण हैं, और इसलिए यदि आप रुचि रखते हैं तो आपको सत्य खोजने और स्रोतों को पढ़ने के लिए आमंत्रित किया जाता है :)।
पेलोड बनाने के लिए, आपको बस VS 2017 x64 प्रॉम्प्ट से nmake चलाना होगा।
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\bin निर्देशिका के अंदर एक payload.dll / payload.pdb फ़ाइल बनाता है। साथ ही एक JavaScript फ़ाइल जिसे payload.js कहा जाता है जो लोडर के ऑफसेट के साथ Uint8Array के अंदर dll को एम्बेड करता है।
मैंने इस शोषण को एक स्थानीय विंडोज बिल्ड के विरुद्ध लिखा जो निम्नलिखित रिवीजन आईडी के साथ सिंक्रोनाइज़ किया गया था: 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 फ्रंट-एंड के काम करने के तरीके को थोड़ा और समझने में समय बिताकर कोई बेहतर हुकिंग पॉइंट के साथ आ सकता है।
शोषण लिखने के बाद मैंने जो कुछ और रास्ते खोजे, उन पर इस बगज़िला प्रविष्टि में चर्चा की गई है: 982974 (JavaScript इंटरप्रेटर के लिए सिस्टम प्रिंसिपल और security.turn_off_all_security_so_that_viruses_can_take_over_this_computer)। यह देखना दिलचस्प होगा कि आज फ़ायरफ़ॉक्स के लिए इसका कितना हिस्सा अभी भी प्रासंगिक है।
शायद किसी ने पहले ही इस विषय पर शोध किया है और मैं पूरी तरह से चूक गया। किसी भी मामले में, किसी भी प्रतिक्रिया के साथ मुझसे संपर्क करने में संकोच न करें!
एक और दिलचस्प बात यह पता लगाना होगी कि ब्राउज़र के भीतर कोई स्थायित्व तंत्र स्थापित करने का कोई तरीका है या नहीं। मैंने इस क्षेत्र पर बिल्कुल शोध नहीं किया है, लेकिन यह बहुत अच्छा होगा :)।