अध्ययन में Chrome और Linux में MTE सुरक्षा को बायपास करने वाले व्यावहारिक हमलों का विवरण

लिंक की सूची

सारांश

1. परिचय

2. पृष्ठभूमि

• मेमोरी टैगिंग एक्सटेंशन
• अनुमानात्मक निष्पादन हमला

3. खतरे का मॉडल

4. टैग लीकेज गैजेट्स खोजना

• टैग लीकेज टेम्पलेट
• टैग लीकेज फजिंग

5. TIKTAG गैजेट्स

• TIKTAG-v1: अनुमान संकुचन का दोहन
• TIKTAG-v2: स्टोर-टू-लोड फॉरवर्डिंग का दोहन

6. वास्तविक दुनिया के हमले

6.1. Chrome पर हमला

7. मूल्यांकन

8. संबंधित कार्य

9. निष्कर्ष और संदर्भ

\

वास्तविक दुनिया के हमले

MTE-आधारित शमन में TIKTAG गैजेट्स की दोहन क्षमता को प्रदर्शित करने के लिए, यह खंड Chrome और Linux कर्नेल के खिलाफ दो वास्तविक दुनिया के हमले विकसित करता है (चित्र 9)। TIKTAG गैजेट्स का उपयोग करके वास्तविक दुनिया के हमले शुरू करने में कई चुनौतियां हैं। पहला, TIKTAG गैजेट्स को लक्ष्य एड्रेस स्पेस में निष्पादित किया जाना चाहिए, जिसके लिए हमलावर को लक्ष्य सिस्टम से गैजेट्स का निर्माण या खोज करनी होगी। दूसरा, हमलावर को टैग जांच परिणामों को लीक करने के लिए कैश स्थिति को नियंत्रित और निरीक्षण करना चाहिए। निम्नलिखित में, हम दो वास्तविक दुनिया के सिस्टमों पर TIKTAG गैजेट्स का उपयोग करते हुए वास्तविक दुनिया के हमलों का प्रदर्शन करते हैं: Google Chrome ब्राउज़र (§6.1) और Linux कर्नेल (§6.2), और शमन रणनीतियों पर चर्चा करते हैं।

\ 6.1. Chrome पर हमला

ब्राउज़र एक वेब ब्राउज़र वेब-आधारित हमलों के लिए एक प्राथमिक हमले की सतह है क्योंकि यह अविश्वसनीय वेब सामग्री, जैसे JavaScript और HTML को प्रोसेस करता है। हम पहले खतरे के मॉडल का अवलोकन करते हैं (§6.1.1) और V8 JavaScript इंजन में निर्मित एक TIKTAG गैजेट प्रदान करते हैं (§6.1.2)। फिर, हम ब्राउज़र का दोहन करने में TIKTAG गैजेट्स की प्रभावशीलता का प्रदर्शन करते हैं (§6.1.3) और शमन रणनीतियों पर चर्चा करते हैं (§6.1.4)।

\ ==6.1.1. खतरे का मॉडल।== हम Chrome ब्राउज़र हमलों के विशिष्ट खतरे के मॉडल का पालन करते हैं, जहां हमलावर का लक्ष्य रेंडरर प्रोसेस में मेमोरी भ्रष्टाचार कमजोरियों का दोहन करना है। हम मानते हैं कि पीड़ित उपयोगकर्ता हमलावर-नियंत्रित वेबसाइट पर जाता है, जो एक दुर्भावनापूर्ण वेबपेज प्रदान करता है। वेबपेज में तैयार HTML और JavaScript शामिल हैं, जो पीड़ित के रेंडरर प्रोसेस में मेमोरी भ्रष्टाचार कमजोरियों का दोहन करते हैं। हम मानते हैं कि Chrome की सभी अत्याधुनिक शमन तकनीकें लागू हैं, जिनमें ASLR [18], CFI [15], साइट आइसोलेशन [53], और V8 सैंडबॉक्स [56] शामिल हैं। इसके अतिरिक्त, एक ऑर्थोगोनल रक्षा के रूप में, हम मानते हैं कि रेंडरर प्रोसेस PartitionAlloc [2] में यादृच्छिक MTE टैगिंग सक्षम करता है।

\ ==6.1.2. TIKTAG गैजेट का निर्माण।== V8 JavaScript वातावरण में, TIKTAG-v2 सफलतापूर्वक निर्मित किया गया और किसी भी मेमोरी एड्रेस के MTE टैग्स को लीक किया। हालांकि, हमें एक निर्माण योग्य TIKTAG-v1 गैजेट नहीं मिला, क्योंकि BR और CHECK के बीच का सख्त समय बाधा हमारी अनुमानात्मक V8 सैंडबॉक्स एस्केप तकनीक (§A) में व्यवहार्य नहीं था।

V8 TikTag-v2 गैजेट। चित्र 8 V8 JavaScript इंजन में निर्मित TIKTAG-v2 गैजेट और JIT संकलन के बाद इसका स्यूडो-C कोड है। इस गैजेट के साथ, हमलावर यह जान सकता है कि अनुमानित टैग Tg, target_addr को असाइन किए गए टैग Tm से मेल खाता है या नहीं। हमलावर तीन arrays तैयार करता है, slow, victim, probe, और एक idx मान। slow एक Unit8Array है जिसकी लंबाई 64 है और BR में ब्रांच मिसप्रिडिक्शन ट्रिगर करने के लिए एक्सेस किया जाता है। victim एक Float64Array है जिसकी लंबाई 64 है, जिसे स्टोर-टू-लोड फॉरवर्डिंग ट्रिगर करने के लिए एक्सेस किया जाता है। probe एक Uint8Array है जिसकी लंबाई 512 है, और

\ TEST में टैग जांच परिणाम को लीक करने के लिए एक्सेस किया जाता है। victim के आउट-ऑफ-बाउंड्स एक्सेस में एक Number प्रकार का idx मान उपयोग किया जाता है। idx मान इस प्रकार चुना जाता है कि victim[idx] अनुमानित टैग Tg के साथ target_addr की ओर इशारा करता है (अर्थात, (Tg«56)|target_addr)। V8 सैंडबॉक्स के बाहर target_addr को अनुमानात्मक रूप से एक्सेस करने के लिए, हमने अपने शोध के दौरान खोजी गई अनुमानात्मक V8 सैंडबॉक्स एस्केप तकनीक का लाभ उठाया, जिसका हम §A में विस्तार से वर्णन करते हैं। चित्र 8a की पंक्ति 8 TIKTAG-v2 गैजेट का BR ब्लॉक है, जो slow[0] के साथ ब्रांच मिसप्रिडिक्शन ट्रिगर करता है।

\ पंक्ति 12-13 CHECK ब्लॉक है, जो victim[idx] के साथ स्टोर-टू-लोड फॉरवर्डिंग करता है, अनुमानित टैग Tg के साथ target_addr को एक्सेस करता है। जब यह कोड JIT-संकलित होता है (चित्र 8b), एक बाउंड चेक किया जाता है, idx की तुलना victim.length से की जाती है। यदि idx एक आउट-ऑफ-बाउंड्स इंडेक्स है, तो कोड undefined रिटर्न करता है, लेकिन यदि victim.length फ़ील्ड को लोड होने में लंबा समय लगता है, तो CPU अनुमानात्मक रूप से निम्नलिखित स्टोर और लोड निर्देशों को निष्पादित करता है।

\ उसके बाद, पंक्ति 17 TEST ब्लॉक को लागू करती है, जो फॉरवर्ड किए गए मान val को एक इंडेक्स के रूप में probe को एक्सेस करता है। फिर से, probe की लंबाई के खिलाफ val पर एक बाउंड चेक पहले किया जाता है, लेकिन यह जांच सफल होती है क्योंकि PROBE_OFFSET, probe array की लंबाई से छोटा है। परिणामस्वरूप, probe[PROBE_OFFSET] केवल तभी कैश किया जाता है जब स्टोर-टू-लोड फॉरवर्डिंग सफल होती है, जो Tg के Tm से मेल खाने की स्थिति है।

\ ==6.1.3. Chrome MTE बाईपास हमला।== चित्र 9a TIKTAG गैजेट्स के मनमाने टैग लीकेज प्रिमिटिव के साथ Chrome ब्राउज़र पर समग्र MTE बाईपास हमले को दर्शाता है। हम रेंडरर प्रोसेस में एक बफर ओवरफ्लो कमजोरी मानते हैं, जहां एक अस्थायी कमजोरी (जैसे, use-after-free) का दोहन काफी हद तक समान है। कमजोरी एक पॉइंटर (अर्थात, vuln_ptr) को एक कमजोर ऑब्जेक्ट (अर्थात, objvuln) में ओवरफ्लो करती है, आसन्न ऑब्जेक्ट (अर्थात, objtarget) को भ्रष्ट करती है।

\ PartitionAlloc के MTE प्रवर्तन के साथ, दो ऑब्जेक्ट्स में 14/15 संभाव्यता के साथ अलग-अलग टैग होते हैं। अपवाद उठाने से बचने के लिए, हमलावर को यह सुनिश्चित करना होगा कि objvuln और objtarget के टैग समान हों। TIKTAG-v2 का उपयोग objvuln ( 1 ) और objtarget ( 2 ) के टैग को लीक करने के लिए किया जा सकता है। यदि दोनों लीक किए गए टैग समान हैं, तो हमलावर कमजोरी का दोहन करता है, जो टैग जांच त्रुटि नहीं उठाएगा ( 3 )। अन्यथा, हमलावर objtarget को फ्री करता है और फिर से आवंटित करता है और टैग मेल खाने तक पहले चरण में वापस जाता है।

\ ==कैश साइड-चैनल ट्रिगर करना।== एक TIKTAG गैजेट का सफलतापूर्वक दोहन करने के लिए, हमलावर को निम्नलिखित आवश्यकताओं को पूरा करना होगा:

i) ब्रांच प्रशिक्षण,

ii) कैश नियंत्रण, और

iii) कैश माप। JavaScript में सभी तीन आवश्यकताओं को पूरा किया जा सकता है।

पहला, हमलावर गैर-शून्य slow[0] और इन-बाउंड्स idx के साथ गैजेट चलाकर ब्रांच प्रिडिक्टर को प्रशिक्षित कर सकता है, और slow[0] में शून्य मान और आउट-ऑफ-बाउंड्स idx के साथ BR में ब्रांच मिसप्रिडिक्शन ट्रिगर कर सकता है।

दूसरा, हमलावर JavaScript कैश इविक्शन तकनीकों [8, 21, 70] के साथ slow[0], victim.length, और probe[PROBE_OFFSET] की कैश लाइनों को इविक्ट कर सकता है।

तीसरा, हमलावर SharedArrayBuffer [16, 58] पर आधारित एक उच्च-रिज़ॉल्यूशन टाइमर के साथ probe[PROBE_OFFSET] की कैश स्थिति को माप सकता है।

\ ==मेमोरी भ्रष्टाचार कमजोरियों का दोहन।== लीक किए गए MTE टैग्स को देखते हुए, हमलावर रेंडरर में स्थानिक और अस्थायी मेमोरी भ्रष्टाचार कमजोरियों का दोहन कर सकता है। हमले की रणनीति काफी हद तक पारंपरिक मेमोरी भ्रष्टाचार हमलों के समान है लेकिन यह सुनिश्चित करनी चाहिए कि कमजोरी लीक किए गए टैग्स का उपयोग करते हुए टैग जांच त्रुटि नहीं उठाती। हम §C में हमले की रणनीति का और विस्तार करते हैं।

\ ==6.1.4. शमन।== ब्राउज़र रेंडरर प्रोसेस में TIKTAG गैजेट-आधारित MTE बाईपास हमलों को कम करने के लिए, निम्नलिखित शमन नियोजित किए जा सकते हैं:

i) अनुमानात्मक निष्पादन-जागरूक सैंडबॉक्स: हमलावरों को V8 सैंडबॉक्स जैसे सैंडबॉक्स वातावरण से TIKTAG-आधारित हमले शुरू करने से रोकने के लिए, सैंडबॉक्स को सैंडबॉक्स के मेमोरी क्षेत्र से परे किसी भी अनुमानात्मक मेमोरी एक्सेस को रोककर मजबूत किया जा सकता है। जबकि आधुनिक वेब ब्राउज़र रेंडरर से अविश्वसनीय वेब सामग्री को अलग करने के लिए एक सैंडबॉक्स का उपयोग करते हैं, वे अक्सर अनुमानात्मक पथों को अनदेखा करते हैं।

\ उदाहरण के लिए, Chrome V8 सैंडबॉक्स [56] और Safari Webkit सैंडबॉक्स [1] अनुमानात्मक पथों को पूरी तरह से मध्यस्थता नहीं करते हैं [27]। वर्तमान पॉइंटर कम्प्रेशन तकनीकों [64] के आधार पर, पॉइंटर्स के उच्च बिट्स को मास्क करके अनुमानात्मक पथों को सैंडबॉक्स क्षेत्र तक सीमित किया जा सकता है।

\ ii) अनुमान बाधा: §5 में सुझाए अनुसार, संभावित TIKTAG गैजेट्स के लिए BR के बाद एक अनुमान बाधा रखने से अनुमानात्मक टैग लीकेज हमलों को रोका जा सकता है। हालांकि, यह शमन प्रदर्शन-महत्वपूर्ण ब्राउज़र वातावरण में लागू नहीं हो सकता है, क्योंकि यह महत्वपूर्ण प्रदर्शन ओवरहेड पेश कर सकता है।

\ iii) गैजेट निर्माण की रोकथाम: §5.2 में सुझाए अनुसार, TIKTAG-v2 गैजेट को स्टोर और लोड निर्देशों के बीच पैडिंग निर्देशों द्वारा कम किया जा सकता है। एक TIKTAGv1 गैजेट, हालांकि हमें एक दोहन योग्य नहीं मिला है, को एक ब्रांच और मेमोरी एक्सेस के बीच पैडिंग निर्देशों द्वारा कम किया जा सकता है, जैसा कि §5.1 में वर्णित है।

\ 6.2. Linux कर्नेल पर हमला

ARM पर Linux कर्नेल मोबाइल उपकरणों, सर्वरों और IoT उपकरणों के लिए व्यापक रूप से उपयोग किया जाता है, जिससे यह एक आकर्षक हमले का लक्ष्य बन जाता है। कर्नेल में मेमोरी भ्रष्टाचार कमजोरी का दोहन उपयोगकर्ता के विशेषाधिकार को बढ़ा सकता है, और इस प्रकार MTE Linux कर्नेल के लिए एक आशाजनक सुरक्षा तंत्र है। Linux कर्नेल के खिलाफ TIKTAG-आधारित हमले ब्राउज़र हमले (§6.1) से अलग अद्वितीय चुनौतियों को प्रस्तुत करते हैं।

\ ऐसा इसलिए है क्योंकि हमलावर का एड्रेस स्पेस कर्नेल के एड्रेस स्पेस से अलग होता है जहां गैजेट निष्पादित किया जाएगा। निम्नलिखित में, हम पहले Linux कर्नेल के खतरे के मॉडल का अवलोकन करते हैं (§6.2.1) और Linux कर्नेल में हमारे द्वारा खोजे गए एक proof-of-concept TIKTAG गैजेट प्रदान करते हैं (§6.2.2)। अंत में, हम Linux कर्नेल कमजोरियों का दोहन करने में TIKTAG गैजेट्स की प्रभावशीलता का प्रदर्शन करते हैं (§6.2.3)।

\ ==6.2.1. खतरे का मॉडल।== यहां खतरे का मॉडल काफी हद तक कर्नेल के खिलाफ विशिष्ट विशेषाधिकार वृद्धि हमलों के समान है। विशेष रूप से, हम ARM-आधारित Android Linux कर्नेल पर ध्यान केंद्रित करते हैं, जो डिफ़ॉल्ट कर्नेल सुरक्षा (जैसे, KASLR, SMEP, SMAP, और CFI) के साथ कठोर है। हम आगे मानते हैं कि कर्नेल एक MTE यादृच्छिक टैगिंग समाधान के साथ कठोर है, उत्पादन-तैयार MTE समाधान, Scudo [3] के समान।

\ विशेष रूप से, प्रत्येक मेमोरी ऑब्जेक्ट को यादृच्छिक रूप से टैग किया जाता है, और जब कोई ऑब्जेक्ट फ्री किया जाता है तो एक यादृच्छिक टैग असाइन किया जाता है, जिससे स्थानिक और अस्थायी मेमोरी भ्रष्टाचार दोनों को रोका जा सकता है। हमलावर एक अप्रिविलेज्ड प्रोसेस चलाने में सक्षम है और कर्नेल में मेमोरी भ्रष्टाचार कमजोरियों का दोहन करके अपने विशेषाधिकार को बढ़ाने का लक्ष्य रखता है। यह माना जाता है कि हमलावर कर्नेल मेमोरी भ्रष्टाचार कमजोरियों को जानता है लेकिन कर्नेल मेमोरी के किसी भी MTE टैग को नहीं जानता। बेमेल टैग वाले कर्नेल ऑब्जेक्ट्स के बीच मेमोरी भ्रष्टाचार ट्रिगर करने से

\ टैग जांच त्रुटि उठाई जाएगी, जो वास्तविक दुनिया के दोहन के लिए अवांछनीय है। इस हमले में एक महत्वपूर्ण चुनौती यह है कि गैजेट को मौजूदा कर्नेल कोड को फिर से उपयोग करके निर्मित किया जाना चाहिए और सिस्टम कॉल द्वारा निष्पादित किया जाना चाहिए जिसे हमलावर कॉल कर सकता है। चूंकि ARMv8 आर्किटेक्चर उपयोगकर्ता और कर्नेल पेज टेबल को अलग करता है, उपयोगकर्ता स्पेस गैजेट्स अनुमानात्मक रूप से कर्नेल मेमोरी को एक्सेस नहीं कर सकते। यह सेटअप ब्राउज़र पर हमला करने के खतरे के मॉडल (§6.1) से बहुत अलग है, जिसने गैजेट बनाने के लिए हमलावर-प्रदान किए गए कोड का लाभ उठाया। हमने eBPF-आधारित गैजेट निर्माण को भी बाहर रखा [17, 28], क्योंकि eBPF अप्रिविलेज्ड Android प्रोसेस के लिए उपलब्ध नहीं है [33]।

\ ==6.2.2. कर्नेल TikTag गैजेट==। §4.1 में वर्णित के रूप में, TIKTAG गैजेट्स को कई आवश्यकताओं को पूरा करना चाहिए, और प्रत्येक आवश्यकता कर्नेल वातावरण में चुनौतियों को शामिल करती है।

पहला, BR में, cond_ptr के साथ एक ब्रांच मिसप्रिडिक्शन ट्रिगर किया जाना चाहिए, जो उपयोगकर्ता स्पेस से नियंत्रणीय होना चाहिए। चूंकि हाल के AArch64 प्रोसेसर उपयोगकर्ता और कर्नेल के बीच ब्रांच प्रिडिक्शन प्रशिक्षण को अलग करते हैं [33], ब्रांच प्रशिक्षण को कर्नेल स्पेस से किया जाना चाहिए।

दूसरा, CHECK में, guess_ptr को डिरेफरेंस किया जाना चाहिए। guess_ptr को उपयोगकर्ता स्पेस से इस प्रकार तैयार किया जाना चाहिए कि यह एक अनुमान टैग (Tg) एम्बेड करे और टैग (Tm) को लीक करने के लिए कर्नेल एड्रेस (अर्थात, target_addr) की ओर इशारा करे। ब्राउज़र JavaScript वातावरण (§6.1) के विपरीत, उपयोगकर्ता-प्रदान किए गए डेटा को सिस्टम कॉल में भारी रूप से सैनिटाइज़ किया जाता है, इसलिए एक मनमाना कर्नेल पॉइंटर बनाना मुश्किल है।

\ उदाहरण के लिए, access_ok() यह सुनिश्चित करता है कि उपयोगकर्ता-प्रदान किया गया पॉइंटर उपयोगकर्ता स्पेस की ओर इशारा करता है, और array_index_nospec मैक्रो उपयोगकर्ता-प्रदान किए गए इंडेक्स के साथ अनुमानात्मक आउट-ऑफ-बाउंड्स एक्सेस को रोकता है। इस प्रकार, guess_ptr एक मौजूदा कर्नेल पॉइंटर होना चाहिए, विशेष रूप से वह कमजोर पॉइंटर जो मेमोरी भ्रष्टाचार का कारण बनता है। उदाहरण के लिए, use-after-free (UAF) में एक डैंगलिंग पॉइंटर या बफर ओवरफ्लो में एक आउट-ऑफ-बाउंड्स पॉइंटर का उपयोग किया जा सकता है। अंत में, TEST में, test_ptr को डिरेफरेंस किया जाना चाहिए, और test_ptr उपयोगकर्ता स्पेस से सुलभ होना चाहिए। कैश स्थिति माप को आसान बनाने के लिए, test_ptr एक सिस्टम कॉल तर्क के माध्यम से प्रदान किया गया उपयोगकर्ता स्पेस पॉइंटर होना चाहिए।

\ ==खोजे गए गैजेट्स।== हमने उपरोक्त आवश्यकताओं को पूरा करने वाले TIKTAG गैजेट को खोजने के लिए Linux कर्नेल के स्रोत कोड का मैन्युअल रूप से विश्लेषण किया। परिणामस्वरूप, हमें snd_timer_user_read() (चित्र 10) में एक संभावित रूप से दोहन योग्य TIKTAG-v1 गैजेट मिला। यह गैजेट TIKTAG-v1 (§5.1) की आवश्यकताओं को पूरा करता है। पंक्ति 10 (अर्थात, BR) पर, switch स्टेटमेंट एक उपयोगकर्ता-नियंत्रणीय मान tu->tread (अर्थात, cond_ptr) के साथ ब्रांच मिसप्रिडिक्शन ट्रिगर करता है। पंक्तियों 14-17 (अर्थात, CHECK) पर, tread (अर्थात, guess_ptr) को चार लोड निर्देशों द्वारा डिरेफरेंस किया जाता है। tread एक struct snd_timer_tread64 ऑब्जेक्ट की ओर इशारा करता है जिसे हमलावर मनमाने ढंग से आवंटित और फ्री कर सकता है।

\ यदि एक अस्थायी कमजोरी tread को एक डैंगलिंग पॉइंटर में बदल देती है, तो इसे guess_ptr के रूप में उपयोग किया जा सकता है। पंक्ति 20 पर, (अर्थात, TEST), एक उपयोगकर्ता स्पेस पॉइंटर बफर (अर्थात, test_ptr) को copy_to_user में डिरेफरेंस किया जाता है। चूंकि यह गैजेट उपयोगकर्ता स्पेस से सीधे पहुंच योग्य नहीं है, हमने कर्नेल कोड में एक मामूली संशोधन किया; हमने पंक्ति 6 पर डिफ़ॉल्ट केस के लिए जल्दी रिटर्न को हटा दिया। यह सुनिश्चित करता है कि बफर को केवल अनुमानात्मक पथ में एक्सेस किया जाता है ताकि अनुमानात्मक निष्पादन के कारण कैश स्थिति अंतर को देखा जा सके।

\ हालांकि यह संशोधन एक वास्तविक दुनिया के परिदृश्य में यथार्थवादी नहीं है, यह गैजेट की संभावित दोहन क्षमता को प्रदर्शित करता है यदि समान कोड परिवर्तन किए जाएं। हमने कई और संभावित रूप से दोहन योग्य गैजेट्स खोजे, लेकिन हम टैग मैच और मिसमैच के बीच कैश स्थिति अंतर का निरीक्षण करने में सक्षम नहीं थे। फिर भी, हमें लगता है कि उन गैजेट्स का दोहन करने की मजबूत संभावना है। TIKTAG-आधारित हमलों को शुरू करने में जटिल और संवेदनशील इंजीनियरिंग शामिल है, और इस प्रकार हम सभी संभावित मामलों के साथ प्रयोग करने में सक्षम नहीं थे।

\ विशेष रूप से, TIKTAG-v1 गलत पथ घटनाओं पर अनुमान संकुचन पर निर्भर करता है, जिसमें ब्रांच मिसप्रिडिक्शन पथ में एड्रेस अनुवाद त्रुटियां या अन्य अपवाद भी शामिल हो सकते हैं। चूंकि सिस्टम कॉल में जटिल नियंत्रण प्रवाह शामिल होते हैं, अनुमान संकुचन अपेक्षित रूप से ट्रिगर नहीं हो सकता। इसके अलावा, जब कर्नेल कोड बदलता है तो कई गैजेट्स दोहन योग्य हो सकते हैं। उदाहरण के लिए, ip6mr_ioctl() में एक TIKTAG-v1 गैजेट ने अपने सिस्टम कॉल पथ (अर्थात, ioctl) से बुलाए जाने पर MTE टैग लीकेज व्यवहार प्रदर्शित नहीं किया। हालांकि, गैजेट में एक सरल नियंत्रण प्रवाह के साथ अन्य सिस्टम कॉल (जैसे, write) में पोर्ट किए जाने पर टैग लीकेज था।

\ ==6.2.3. कर्नेल MTE बाईपास हमला।== चित्र 9b Linux कर्नेल पर MTE बाईपास हमलों को दर्शाता है। एक use-after-free कमजोरी को उदाहरण के रूप में लेते हुए, हम मानते हैं कि हमलावर ने एक संबंधित TIKTAG गैजेट, SysTikTagUAF(), की पहचान की है, जो कमजोरी द्वारा बनाए गए डैंगलिंग पॉइंटर के टैग जांच परिणाम को लीक करने में सक्षम है। उदाहरण के लिए, snd_timer_user_read() (चित्र 10) में TIKTAG-v1 गैजेट tread के टैग जांच परिणाम को लीक कर सकता है, जो एक use-after-free या double-free कमजोरी द्वारा एक डैंगलिंग पॉइंटर बन सकता है।

\ हमला निम्नानुसार आगे बढ़ता है: पहला, हमलावर एक कर्नेल ऑब्जेक्ट (अर्थात, objvuln) को फ्री करता है और इसके पॉइंटर (अर्थात, vuln_ptr) को एक डैंगलिंग पॉइंटर के रूप में छोड़ देता है ( 1 )। अगला, हमलावर SysAllocTarget() ( 2 ) के साथ objvuln के एड्रेस पर एक और कर्नेल ऑब्जेक्ट (अर्थात, objtarget) आवंटित करता है। फिर, हमलावर एक उपयोगकर्ता स्पेस बफर (अर्थात, ubuf) ( 3 ) के साथ SysTikTag() को कॉल करता है, और ubuf ( 4 ) के एक्सेस विलंब को मापकर टैग जांच परिणाम (अर्थात, Tm == Tg) को लीक करता है। यदि टैग मेल खाते हैं, तो हमलावर SysExploitUAF(), एक सिस्टम कॉल को ट्रिगर करता है जो use-after-free कमजोरी का दोहन करता है ( 5 )। अन्यथा, हमलावर objtarget को तब तक फिर से आवंटित करता है जब तक कि टैग मेल न खाएं।

\ ==कैश साइड-चैनल ट्रिगर करना।== §6.1.3 के अनुसार, एक सफल TIKTAG गैजेट दोहन के लिए i) ब्रांच प्रशिक्षण, ii) कैश नियंत्रण, और iii) कैश माप की आवश्यकता होती है। ब्रांच प्रशिक्षण के लिए, हमलावर ब्रांच प्रिडिक्टर को प्रशिक्षित कर सकता है और उपयोगकर्ता स्पेस से उपयोगकर्ता-नियंत्रित ब्रांच स्थितियों के साथ अनुमान को ट्रिगर कर सकता है। कैश नियंत्रण के लिए, हमलावर उपयोगकर्ता स्पेस बफर (अर्थात, ubuf) को फ्लश कर सकता है, जबकि कर्नेल मेमोरी एड्रेस को कैश लाइन बाउंसिंग [25] द्वारा इविक्ट किया जा सकता है। कैश माप के लिए, ubuf के एक्सेस विलंब को वर्चुअल काउंटर (अर्थात, CNTVCT_EL0) या मेमोरी काउंटर-आधारित टाइमर (अर्थात, CPU साइकिल रिज़ॉल्यूशन के पास) के साथ मापा जा सकता है।

\ ==मेमोरी भ्रष्टाचार कमजोरियों का दोहन।== TIKTAG गैजेट्स MTE को बाईपास करने और कर्नेल मेमोरी भ्रष्टाचार कमजोरियों का दोहन करने में सक्षम बनाते हैं। हमलावर कर्नेल में TIKTAG गैजेट को कॉल करके अनुमानात्मक रूप से मेमोरी भ्रष्टाचार को ट्रिगर कर सकता है और टैग जांच परिणाम प्राप्त कर सकता है। फिर, हमलावर टैग जांच परिणाम प्राप्त कर सकता है, और केवल तभी मेमोरी भ्रष्टाचार को ट्रिगर कर सकता है जब टैग मेल खाएं। हम §D में Linux कर्नेल MTE बाईपास हमले की प्रक्रिया का विस्तार करते हैं।

\ ==6.2.4. शमन।== Linux कर्नेल में TIKTAG गैजेट को कम करने के लिए, कर्नेल डेवलपर्स को निम्नलिखित शमनों पर विचार करना चाहिए:

i) अनुमान बाधा: अनुमान बाधाएं Linux कर्नेल में TIKTAG-v1 गैजेट को प्रभावी रूप से कम कर सकती हैं। हमलावरों को उपयोगकर्ता स्पेस बफर के माध्यम से टैग जांच परिणाम को लीक करने से रोकने के लिए, कर्नेल फ़ंक्शन जो उपयोगकर्ता स्पेस एड्रेस को एक्सेस करते हैं, जैसे copy_to_user और copy_from_user, को अनुमान बाधाओं के साथ कठोर किया जा सकता है। §5.1 में वर्णित के अनुसार, स्टोर एक्सेस के साथ टैग जांच परिणामों को लीक करने को स्टोर एक्सेस (अर्थात, TEST) से पहले एक अनुमान बाधा रखकर कम किया जा सकता है।

\ उदाहरण के लिए, copy_to_user का लाभ उठाने वाले गैजेट्स को कम करने के लिए, copy_to_user कॉल से पहले एक अनुमान बाधा डाली जा सकती है। उपयोगकर्ता स्पेस बफर के लिए लोड एक्सेस का उपयोग करने वाले गैजेट्स के लिए, यदि ब्रांच और कर्नेल मेमोरी एक्सेस (अर्थात, CHECK) के बीच डाले गए हों तो बाधाएं गैजेट्स को कम करती हैं। उदाहरण के लिए, copy_from_user का लाभ उठाने वाले गैजेट्स को कम करने के लिए, कर्नेल डेवलपर्स को सशर्त ब्रांच, कर्नेल मेमोरी एक्सेस, और copy_from_user() के पैटर्न को खोजने के लिए कर्नेल कोड बेस का सावधानीपूर्वक विश्लेषण करना चाहिए, और ब्रांच और कर्नेल मेमोरी एक्सेस के बीच एक अनुमान बाधा डालनी चाहिए।

\ ii) गैजेट निर्माण की रोकथाम: Linux कर्नेल में संभावित TIKTAG गैजेट्स को खत्म करने के लिए, कर्नेल स्रोत कोड का विश्लेषण और पैच किया जा सकता है। चूंकि TIKTAG गैजेट्स को कंपाइलर अनुकूलन द्वारा भी बनाया जा सकता है, एक बाइनरी विश्लेषण किया जा सकता है। प्रत्येक खोजे गए गैजेट के लिए, §5.1 और §5.2 में शमन रणनीतियों का पालन करते हुए, गैजेट निर्माण को रोकने के लिए निर्देशों को फिर से व्यवस्थित किया जा सकता है या अतिरिक्त निर्देश डाले जा सकते हैं।

:::info लेखक:

1. Juhee Kim
2. Jinbum Park
3. Sihyeon Roh
4. Jaeyoung Chung
5. Youngjoo Lee
6. Taesoo Kim
7. Byoungyoung Lee

:::

:::info यह पेपर CC 4.0 लाइसेंस के तहत arxiv पर उपलब्ध है।

:::

\