Skip to content
KitploitKITPLOIT
उपकरणएक्सप्लॉइटब्लॉग
Log in
जमा करें
उपकरणएक्सप्लॉइटब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
Pixel_GPU_Exploit — Pixel7/8 Pro के लिए Android 14 कर्नेल शोषण | Kitploit
उपकरण/GitHubGitHub/0x36/pixel_gpu_exploit
एंड्रॉइड सुरक्षाविशेषाधिकार वृद्धिमेमोरी फोरेंसिकभेद्यता विश्लेषणशोषणलर्निंग और शिक्षाबाइनरी शोषण
GitHub0x36/pixel_gpu_exploit

Pixel_GPU_Exploit

Pixel7/8 Pro के लिए Android 14 कर्नेल शोषण

रिपॉजिटरी देखें
55788152 साल पहलेKitploit द्वारा समीक्षित

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

Mali GPU कर्नल LPE

यह लेख Mali GPU के भीतर दो कर्नल कमजोरियों का गहन विश्लेषण प्रदान करता है, जो डिफ़ॉल्ट एप्लिकेशन सैंडबॉक्स से पहुंच योग्य हैं, जिन्हें मैंने स्वतंत्र रूप से पहचाना और Google को रिपोर्ट किया। इसमें एक कर्नल एक्सप्लॉइट शामिल है जो मनमाना कर्नल r/w क्षमताएं प्राप्त करता है। परिणामस्वरूप, यह SELinux को अक्षम करता है और निम्नलिखित Android 14 संस्करणों पर चलने वाले Google Pixel 7 और 8 Pro मॉडल पर रूट तक विशेषाधिकार बढ़ाता है:

  • Pixel 8 Pro: google/husky/husky:14/UD1A.231105.004/11010374:user/release-keys
  • Pixel 7 Pro: google/cheetah/cheetah:14/UP1A.231105.003/11010452:user/release-keys
  • Pixel 7 Pro: google/cheetah/cheetah:14/UP1A.231005.007/10754064:user/release-keys
  • Pixel 7: google/panther/panther:14/UP1A.231105.003/11010452:user/release-keys (m4b4 (Marcel) द्वारा)

कमजोरियाँ

यह एक्सप्लॉइट दो कमजोरियों का लाभ उठाता है: gpu_pixel_handle_buffer_liveness_update_ioctl ioctl कमांड में अधूरे पैच के परिणामस्वरूप एक इंटीजर ओवरफ्लो, और टाइमलाइन स्ट्रीम संदेश बफ़र्स के भीतर एक सूचना रिसाव।

गलत इंटीजर ओवरफ्लो फिक्स के कारण gpu_pixel_handle_buffer_liveness_update_ioctl() में बफ़र अंडरफ्लो

Google ने gpu_pixel_handle_buffer_liveness_update_ioctl ioctl कमांड में एक इंटीजर ओवरफ्लो को इस कमिट में संबोधित किया। पहले, जब मैंने इस मुद्दे की रिपोर्ट की, तो मैंने सोचा कि बग पहले वर्णित पैच में किसी समस्या के कारण था। रिपोर्ट की समीक्षा करने के बाद, मुझे एहसास हुआ कि कमजोरी का मेरा विश्लेषण गलत था। पैच के अधूरे होने की मेरी पहली धारणा के बावजूद, यह प्रभावी रूप से गणना में अंडरफ्लो को हल और रोकता है। इससे मुझे संदेह हुआ कि परिवर्तन प्रोडक्शन बिल्ड में लागू नहीं किया गया था। हालाँकि, मैं गणना में अंडरफ्लो पैदा कर सकता हूँ, लेकिन ओवरफ्लो पैदा करना संभव नहीं है। यह सुझाव देता है कि ioctl कमांड को आंशिक रूप से ठीक किया गया है, हालाँकि ऊपर दिखाए गए पैच के साथ नहीं। IDA को देखने से पता चला कि प्रोडक्शन रिलीज़ में एक और अधूरा पैच भेजा गया था, और यह पैच mali gpu कर्नल मॉड्यूल की किसी भी git branch में मौजूद नहीं है।

यह कमजोरी पहली बार नवीनतम Android संस्करण में खोजी गई और 19 नवंबर, 2023 को रिपोर्ट की गई। Google ने बाद में मुझे सूचित किया कि उन्होंने पहले ही इसे आंतरिक रूप से पहचान लिया था और दिसंबर Android सुरक्षा बुलेटिन में इसे CVE-2023-48409 निर्दिष्ट कर दिया था, इसे एक डुप्लिकेट मुद्दे के रूप में लेबल किया। हालाँकि मैं यह सत्यापित करने में सक्षम था कि बग को मेरी रिपोर्ट से महीनों पहले आंतरिक रूप से पहचान लिया गया था, (लगभग 30 अगस्त की कमिट तिथि के आधार पर) फिर भी भ्रम बना हुआ है। विशेष रूप से, यह अजीब है कि सबसे हालिया डिवाइसों के अक्टूबर और नवंबर के सुरक्षा पैच स्तर (SPL) अभी भी इस कमजोरी से प्रभावित थे —मैंने इनसे पहले के संस्करणों की जाँच नहीं की है। इसलिए, मैं निर्णायक रूप से यह निर्धारित करने में असमर्थ हूँ कि क्या यह वास्तव में एक डुप्लिकेट मुद्दा था और क्या उपयुक्त पैच वास्तव में मेरे सबमिशन से पहले दिसंबर के लिए निर्धारित किया गया था या इस कमजोरी को संबोधित करने में कोई अनदेखी थी।

वैसे भी, इस बग को शक्तिशाली बनाने वाली बात निम्नलिखित है:

  • बफ़र info.live_ranges पूरी तरह से उपयोगकर्ता-नियंत्रित है।
  • ओवरफ्लो होने वाले मान उपयोगकर्ता-नियंत्रित इनपुट हैं, जिससे हम गणना को ओवरफ्लो कर सकते हैं ताकि info.live_ranges पॉइंटर buff कर्नल पते की शुरुआत से पहले एक मनमाना ऑफसेट पर हो सके।
  • आवंटन आकार भी उपयोगकर्ता-नियंत्रित इनपुट है, जो किसी भी सामान्य-उद्देश्य स्लैब आवंटक से मेमोरी आवंटन का अनुरोध करने की क्षमता देता है।

यह कमजोरी DeCxt::RasterizeScaleBiasData() बफ़र अंडरफ्लो कमजोरी के साथ समानताएं साझा करती है, जिसे मैंने 2022 में iOS 15 कर्नल में खोजा और एक्सप्लॉइट किया था।

टाइमलाइन स्ट्रीम संदेश बफ़र्स में कर्नल पॉइंटर्स का रिसाव

Mali GPU एक कस्टम timeline stream लागू करता है जिसे जानकारी एकत्र करने, उसे क्रमबद्ध करने और बाद में एक विशिष्ट प्रारूप का पालन करते हुए रिंग बफ़र में लिखने के लिए डिज़ाइन किया गया है। उपयोगकर्ता kbase_api_tlstream_acquire ioctl कमांड को कॉल करके फ़ाइल डिस्क्रिप्टर प्राप्त कर सकते हैं, जो उन्हें इस रिंग बफ़र से पढ़ने में सक्षम बनाता है। संदेशों का प्रारूप इस प्रकार है:

  • एक पैकेट हेडर

  • एक संदेश आईडी

  • एक क्रमबद्ध संदेश बफ़र, जहां विशिष्ट सामग्री संदेश आईडी पर निर्भर करती है। उदाहरण के लिए, __kbase_tlstream_tl_kbase_kcpuqueue_enqueue_fence_wait फ़ंक्शन kbase_kcpu_command_queue और dma_fence कर्नल पॉइंटर्स को संदेश बफ़र में क्रमबद्ध करता है, जिसके परिणामस्वरूप कर्नल पॉइंटर्स यूज़र स्पेस प्रक्रिया में लीक हो जाते हैं।```c void __kbase_tlstream_tl_kbase_kcpuqueue_enqueue_fence_wait( struct kbase_tlstream *stream, const void *kcpu_queue, const void *fence ) { const u32 msg_id = KBASE_TL_KBASE_KCPUQUEUE_ENQUEUE_FENCE_WAIT; const size_t msg_size = sizeof(msg_id) + sizeof(u64) + sizeof(kcpu_queue) + sizeof(fence) ; char *buffer; unsigned long acq_flags; size_t pos = 0;

    buffer = kbase_tlstream_msgbuf_acquire(stream, msg_size, &acq_flags);

    pos = kbasep_serialize_bytes(buffer, pos, &msg_id, sizeof(msg_id)); pos = kbasep_serialize_timestamp(buffer, pos); pos = kbasep_serialize_bytes(buffer, pos, &kcpu_queue, sizeof(kcpu_queue)); pos = kbasep_serialize_bytes(buffer, pos, &fence, sizeof(fence));

    kbase_tlstream_msgbuf_release(stream, acq_flags); }

प्रूफ ऑफ कॉन्सेप्ट एक्सप्लॉइट `kbase_kcpu_command_queue` ऑब्जेक्ट का पता `KBASE_TL_KBASE_NEW_KCPUQUEUE` संदेश आईडी की निगरानी करके लीक करता है, जिसे `kbasep_kcpu_queue_new` फ़ंक्शन द्वारा प्रेषित किया जाता है जब भी कोई नया kcpu कतार ऑब्जेक्ट आवंटित किया जाता है।

Google ने मुझे सूचित किया कि यह भेद्यता मार्च 2023 में रिपोर्ट की गई थी और उनके सुरक्षा बुलेटिन में  [CVE-2023-26083](https://source.android.com/docs/security/bulletin/2023-07-01) निर्दिष्ट की गई थी। फिर भी, मैं अक्टूबर और नवंबर के लिए सुरक्षा पैच स्तर (SPL) के साथ वितरित नवीनतम Pixel उपकरणों पर इस समस्या को दोहराने में सक्षम था, जो दर्शाता है कि सुधार सही ढंग से या बिल्कुल भी लागू नहीं किया गया था। बाद में, Google ने दिसंबर के सुरक्षा अद्यतन बुलेटिन में बिना श्रेय दिए इस समस्या का तुरंत समाधान किया, और बाद में मुझे बताया कि इस मुद्दे को डुप्लिकेट माना गया था। हालाँकि, इस मुद्दे को डुप्लिकेट के रूप में चिह्नित करने का औचित्य संदिग्ध बना हुआ है।

## शोषण
---
तो मेरे पास दो दिलचस्प भेद्यताएँ हैं। पहली आवंटित ~buff~ पते से पहले आने वाले किसी भी 16-बाइट संरेखित कर्नेल पते की सामग्री को संशोधित करने की एक शक्तिशाली क्षमता प्रदान करती है। दूसरी भेद्यता कर्नेल मेमोरी के भीतर वस्तुओं के संभावित स्थानों के बारे में संकेत प्रदान करती है।
टूल डाउनलोड करें