Chronomaly

Chronomaly एंड्रॉइड / लिनक्स कर्नेल के लिए CVE-2025-38352 का उपयोग करने वाला एक कर्नेल एक्सप्लॉइट है। यह एक्सप्लॉइट विशेष रूप से लिनक्स कर्नेल v5.10.157 के लिए लिखा गया था, लेकिन सभी संवेदनशील v5.10.x कर्नेल पर काम करना चाहिए, क्योंकि इसे काम करने के लिए किसी विशिष्ट कर्नेल टेक्स्ट ऑफ़सेट की आवश्यकता नहीं है।

मैंने इस भेद्यता को तीन-भाग वाली ब्लॉग पोस्ट श्रृंखला में विस्तार से कवर किया है, PoC से लेकर एक्सप्लॉइट तक:

• भाग 1 - In-the-wild एंड्रॉइड कर्नेल भेद्यता विश्लेषण + PoC
• भाग 2 - रेस विंडो को कर्नेल पैच के बिना बढ़ाना
• भाग 3 - क्रोनोमैली का अनावरण

बिल्ड सेटअप

यह एक्सप्लॉइट केवल QEMU में चल रहे x86_64 लिनक्स कर्नेल v5.10.157 के खिलाफ परीक्षण किया गया है। मैंने एक मित्र से उनके Pixel 6a कर्नेल कॉन्फ़िगरेशन को भेजने के लिए कहा ताकि मैं उस पर अपने कर्नेल कॉन्फ़िगरेशन को आधारित कर सकूं, और ये इस एक्सप्लॉइट के लिए महत्वपूर्ण कॉन्फ़िग विकल्प हैं (मैंने kernelCTF कॉन्फ़िग को आधार के रूप में लिया था):

• CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n
• CONFIG_PREEMPT=y (पूर्ण प्रीएम्प्शन, कोई RT नहीं)
• CONFIG_SLAB_MERGE_DEFAULT=n
• DEBUG_LIST=n
• BUG_ON_DATA_CORRUPTION=n
• LIST_HARDENED=n

CONFIG_POSIX_CPU_TIMERS_TASK_WORK को अक्षम करने के लिए, आप मेरी पहली ब्लॉग पोस्ट यहाँ में दिए गए चरणों का पालन कर सकते हैं।

अपने QEMU रन स्क्रिप्ट के लिए qemu.sh फ़ाइल देखें। मैंने परीक्षण के लिए 4 कोर और 3 GB RAM का उपयोग किया।

एक्सप्लॉइट पैरामीटर जिन्हें आपको बदलने की आवश्यकता होगी

CPU_USAGE_THRESHOLD

यह पैरामीटर race_func() के अंदर टाइमर को फायर करने के लिए CPU समय का उपभोग करते समय उपयोग किया जाता है। इसे इस प्रकार सेट किया जाना चाहिए कि:

• टाइमर हर पुनः प्रयास प्रयास पर फायर न करें (इसका तात्पर्य होगा कि CPU_USAGE_THRESHOLD बहुत अधिक है, क्योंकि टाइमर race_func() थ्रेड के बाहर निकलने से पहले फायर हो रहे हैं)।
• टाइमर केवल कभी-कभी फायर करें (इसका तात्पर्य होगा कि कभी-कभी टाइमर थ्रेड के बाहर निकलने से पहले फायर होते हैं, और अन्य समय में वे थ्रेड के बाहर निकलने के दौरान फायर होते हैं)।

यह निर्धारित करने के लिए कि टाइमर फायर हो रहे हैं या नहीं, free_func() में SIGUSR1 पोलिंग कोड में एक printf() स्टेटमेंट डालें। यदि आप संदेश प्रिंट होते देखते हैं, तो इसका मतलब है कि टाइमर फायर हो गए।

यदि सही ढंग से सेट किया गया है, तो आप टर्मिनल में "Parent raced too late / too early" संदेश देखना शुरू कर देंगे।

PARENT_SETTIME_DELAY_US

PARENT_SETTIME_DELAY_US। यह पैरामीटर पैरेंट प्रक्रिया द्वारा चाइल्ड प्रक्रिया के साथ एक ही समय पर send_sigqueue() के अंदर दूसरी रेस विंडो को हिट करने के लिए उपयोग किया जाता है। एक्सप्लॉइट चलाएं, निरीक्षण करें, और इसे निम्नानुसार संशोधित करें:

• "Parent raced too late, readjusting..." संदेश बहुत बार दिखाई देता है – इस पैरामीटर को कम करें।
• "Parent raced too early, readjusting..." संदेश बहुत बार दिखाई देता है – इस पैरामीटर को बढ़ाएं।

आदर्श रूप से, आप 'raced too late' और 'raced too early' दोनों मुद्रित होते देखना चाहते हैं, और एक्सप्लॉइट 1 मिनट के भीतर काम करेगा। यदि आप केवल एक को दूसरे से अधिक होते देखते हैं, तो तदनुसार समायोजित करें।

संभावित सुधार

अपने क्रॉस-कैश कार्यान्वयन में, मैंने मान लिया कि कर्नेल बहुत व्यस्त नहीं है, और कि struct sigqueue के कई आवंटन नहीं हुए हैं। मैंने sigqueue_crosscache_preallocs() में एक टिप्पणी जोड़ी है जो बताती है कि इसे सुधारने के लिए आपको क्या करने की आवश्यकता होगी।

यदि कर्नेल वास्तव में व्यस्त है, या per-cpu / per-node आंशिक सूची पर पहले से कुछ struct sigqueue स्लैब पेज मौजूद हैं, तो exploit.c में वर्तमान क्रॉस-कैश कार्यान्वयन विफल हो जाएगा, और uaf_sigqueue / realloc_sigqueue को पाइप बफर डेटा पेज के रूप में पुनः आवंटित नहीं किया जाएगा।

मैंने जानबूझकर क्रॉस-कैश को व्यस्त कर्नेल में काम करने के लिए नहीं बनाया, ताकि एक्सप्लॉइट का दुरुपयोग न हो :)

प्रश्न

यदि आपके कोई प्रश्न हैं, तो कृपया मुझसे X / Twitter के माध्यम से संपर्क करें!