x18-leak

iOS 11.2 ने एक कर्नेल सूचना लीक पेश किया जिसका उपयोग kASLR स्लाइड निर्धारित करने के लिए किया जा सकता था। यह समस्या एक नई जोड़ी गई सुविधा, __ARM_KERNEL_PROTECT__, का परिणाम थी, जिसने अनजाने में कर्नेल फ़ंक्शन Lel0_synchronous_vector_64_long का पता रजिस्टर x18 में प्रकट कर दिया जब thread_get_state का उपयोग करके एक थ्रेड के रजिस्टरों के मान प्राप्त किए जाते थे। यह समस्या तब खोजी गई जब iOS एप्लिकेशन क्रैश लॉग में कर्नेल पॉइंटर्स दिखाई देने लगे।

भेद्यता

iOS 11.2 में, Apple ने arm64 पर __ARM_KERNEL_PROTECT__ नामक एक सुविधा पेश की। osfmk/arm64/proc_reg.h में एक टिप्पणी के अनुसार:

__ARM_KERNEL_PROTECT__ एक ऐसी सुविधा है जो संभावित आर्किटेक्चरल या माइक्रोआर्किटेक्चरल कमजोरियों से बचाने के लिए है जो कोर को EL0 मोड में रहते हुए EL1-केवल मैपिंग को पढ़ने/एक्सेस करने की अनुमति दे सकती हैं। यह कोर के EL1 मोड से EL0 मोड में संक्रमण करने पर जितना संभव हो उतने मैपिंग को हटाकर, और कोर के EL0 मोड से EL1 मोड में संक्रमण करने पर उन मैपिंग को पुनर्स्थापित करके प्राप्त किया जाता है।

अर्थात, EL1 (कर्नेल मोड) से EL0 (उपयोगकर्ता मोड) में संक्रमण करते समय, जितना संभव हो उतने कर्नेल मैपिंग हटा दिए जाएंगे। इससे माइक्रोआर्किटेक्चरल कमजोरियों जैसे Spectre या Meltdown का शोषण करते समय कर्नेल मेमोरी मैपिंग के विरुद्ध संभावित हमले की सतह सीमित होनी चाहिए।

यदि आप XNU संस्करणों 4570.20.62 और 4570.31.3 के बीच के अंतर को देखते हैं, तो आपको फ़ाइल osfmk/arm64/locore.s में __ARM_KERNEL_PROTECT__ के संबंध में रजिस्टर x18 के कई नए संदर्भ मिलेंगे। विशेष रूप से, आप देखेंगे कि अपवाद वेक्टर Lel0_synchronous_vector_64, जो सिस्टम कॉल (निर्देश svc #0) पर आहूत अपवाद वेक्टर है, अब इस प्रकार दिखता है:

	.text
	.align 7
Lel0_synchronous_vector_64:
	MAP_KERNEL
	BRANCH_TO_KVA_VECTOR Lel0_synchronous_vector_64_long, 8

मैक्रो BRANCH_TO_KVA_VECTOR इस प्रकार परिभाषित है:

.macro BRANCH_TO_KVA_VECTOR
#if __ARM_KERNEL_PROTECT__
	/*
	 * Find the kernelcache table for the exception vectors by accessing
	 * the per-CPU data.
	 */
	mrs		x18, TPIDR_EL1
	ldr		x18, [x18, ACT_CPUDATAP]
	ldr		x18, [x18, CPU_EXC_VECTORS]

	/*
	 * Get the handler for this exception and jump to it.
	 */
	ldr		x18, [x18, #($1 << 3)]
	br		x18
#else
	b		$0
#endif /* __ARM_KERNEL_PROTECT__ */
.endmacro

यह मैक्रो फ़ंक्शन Lel0_synchronous_vector_64_long के लिए एक पॉइंटर को रजिस्टर x18 में लोड करके वास्तविक अपवाद वेक्टर कार्यान्वयन के लिए एक अप्रत्यक्ष शाखा निष्पादित करता है। हालांकि, ध्यान दें कि x18 का यह क्लोबर फ़ंक्शन fleh_dispatch64 द्वारा उपयोगकर्तास्पेस रजिस्टरों को सहेजने से पहले होता है, जिसे Lel0_synchronous_vector_64_long द्वारा कॉल किया जाता है। इसका मतलब है कि जब उपयोगकर्ता रजिस्टर सहेजे जाते हैं, तो x18 वास्तव में उपयोगकर्तास्पेस के मूल मान के बजाय Lel0_synchronous_vector_64_long का एक पॉइंटर होगा।

भले ही अपवाद वापसी पर x18 को साफ़ कर दिया जाता है, उपयोगकर्ता रजिस्टर स्थिति में एक कर्नेल पॉइंटर संग्रहीत करना समस्याग्रस्त है क्योंकि thread_get_state का उपयोग सहेजी गई उपयोगकर्ता रजिस्टर स्थिति को उपयोगकर्तास्पेस में कॉपी करने के लिए किया जा सकता है, जिसमें रजिस्टर x18 का मान भी शामिल है। Lel0_synchronous_vector_64_long फ़ंक्शन का पता प्राप्त करने के लिए एक थ्रेड को बस अपने आप पर thread_get_state कॉल करना होगा और x18 के रिपोर्ट किए गए मान को देखना होगा। इससे x18 के इस प्रकार प्राप्त मान से Lel0_synchronous_vector_64_long के स्थिर पते को घटाकर kASLR स्लाइड निर्धारित करना बहुत आसान हो जाता है।

शोषण

जैसा कि ऊपर उल्लेख किया गया है, शोषण बहुत आसान है: बस फ़ंक्शन thread_get_state को कॉल करें, रजिस्टर x18 के मान को देखें, और उसमें से कर्नेल फ़ंक्शन Lel0_synchronous_vector_64_long के स्थिर पते को घटाएं।

खोज

मैंने इस समस्या की खोज 26 फरवरी, 2018 को की, एक iOS एप्लिकेशन क्रैश लॉग में रजिस्टर x18 में एक कर्नेल पॉइंटर देखने के बाद। एक त्वरित जांच से पता चला कि डिवाइस पर हर क्रैश लॉग के रजिस्टर x18 में समान मान दिखाई दिया, जिसने एक गंभीर सूचना लीक का संकेत दिया।

इसके बाद मैंने प्रयोग के माध्यम से यह निर्धारित करने का प्रयास किया कि वास्तव में रजिस्टर x18 के साथ क्या हो रहा है। मैंने एक खाली iOS ऐप में एक ब्रेकपॉइंट सेट किया और रजिस्टर x18 का मान पढ़ने के लिए lldb का उपयोग किया, जिससे पुष्टि हुई कि लीक केवल क्रैश होने वाले अनुप्रयोगों तक सीमित नहीं था। इसके बाद मैंने इनलाइन असेंबली का उपयोग करके x18 का मान पढ़ने का प्रयास किया और पाया कि प्राप्त मान reg read x18 जैसे कमांड का उपयोग करते समय डिबगर द्वारा दिखाए गए मान से मेल नहीं खाता। इससे पता चला कि शायद लीक वास्तव में thread_get_state में था, और जब CPU उपयोगकर्तास्पेस में निष्पादित हो रहा था तब रजिस्टर x18 में वास्तव में कोई कर्नेल पॉइंटर नहीं था। thread_get_state का उपयोग करके x18 का मान पढ़ने वाले एक त्वरित प्रूफ-ऑफ-कॉन्सेप्ट ने पुष्टि की कि यह फ़ंक्शन वास्तव में लीक का स्रोत था।

समयरेखा

मैंने इस समस्या की सूचना 26 फरवरी, 2018 को Apple को दी, उसी दिन जब मैंने इसकी खोज की थी।

द्वारा Brandon Azad