2014-10-01 7 views
8

मैं कॉन्टेक्स्ट क्लास में चेककॉलिंगऑरसेल्फप्रमिशन() के माध्यम से जा रहा था और सोच रहा था कि इसका शोषण कैसे किया जा सकता है; यानी यदि कुछ एप्लिकेशन कैली/आपके आवेदन की एक विधि को ट्रिगर करता है जो बदले में चेक कॉलिंगऑर स्वयंफर्मिशन() को कॉल करता है, अंत में अन्य एप्लिकेशन को उस अनुमति तक पहुंच प्रदान करता है, या संवेदनशील जानकारी जारी करता है जिसे अन्यथा उस अनुमति की आवश्यकता होती है।विशेषाधिकार वृद्धि के लिए चेककॉलिंगऑरसेल्फ पैरामिशन() का पता लगाने

यह विधि केवल किसी भी बुला आवेदन जो कॉल प्राप्त करने वाला आवेदन का एक ही प्रक्रिया में है द्वारा शोषण किया जा सकता है:

यह वही मैं जावा डॉक्टर के माध्यम से जाने के बाद समझ में आ रहा है। एक ही प्रक्रिया में शामिल होने के लिए दोनों ऐप्स को समान प्रमाणपत्र द्वारा हस्ताक्षरित किए जाने के अलावा, मेनिफेस्ट फ़ाइल में समान शेयरसराइड और प्रक्रिया की आवश्यकता होती है।

तो कॉलिंग एप्लिकेशन को निम्नलिखित करने की आवश्यकता है।

  1. पता होना चाहिए कि कौन सी प्रक्रिया और शेयरर आईडी आईडी कैली एप्लिकेशन चल रहा है। (मुझे यकीन नहीं है कि यह कितना व्यवहार्य है?)

  2. उसी प्रमाणपत्र के साथ हस्ताक्षर किया जाना चाहिए जिस पर कैली आवेदन पर हस्ताक्षर किए गए थे (संभावना है कि प्रमाण पत्र सुरक्षित रखा गया है)।

इस शोषण कि checkCallingOrSelfPermission() प्रलेखन के खिलाफ चेतावनी, या कोई अन्य (अधिक यथार्थवादी) तरीके है कि यह शोषण किया जा सकता है है की विधि है।

मैंने this post भी चेक किया, लेकिन उत्तर संतोषजनक नहीं था।

+0

"इस विधि का उपयोग केवल कॉलिंग एप्लिकेशन की एक ही प्रक्रिया में किसी भी कॉलिंग एप्लिकेशन द्वारा किया जा सकता है" - आपको "शोषण" संभव होने पर कोई भी बता सकता है कि आपको "शोषण" क्या है, यह समझाएगा। – CommonsWare

+1

@ कॉमन्सवेयर क्षमा करें अगर मैं पर्याप्त स्पष्ट नहीं था ... शोषण की व्याख्या करने के लिए शीर्ष पर जोड़ा गया विवरण .. – saurav

+0

"यदि कोई एप्लिकेशन कैली/आपके आवेदन की विधि कहता है जो बदले में चेककेलिंगर्सल्फप्रमिशन को कॉल करता है अन्य आवेदन की अनुमति "-' चेककॉलिंगऑरसेल्फ पैरामिशन() 'किसी को कुछ भी नहीं देती है। – CommonsWare

उत्तर

0

सब कुछ कोड में है।

चेककॉलिंगऑरसेल्फप्रमिशन() आईपीसी कॉल में सुरक्षित है।checkCallingOrSelfPermission() और checkCallingPermission()here के कार्यान्वयन की जांच करें। वे दोनों आईपीसी क्लाइंट/कॉलर की अनुमति की जांच करते हैं। जब कॉलर बाहर से है, तो वे बिल्कुल वही हैं!

यदि कॉलर अंदर से (उसी प्रक्रिया) से है, तो, अगर कोई आपकी प्रक्रिया के अंदर कोड निष्पादित कर सकता है, तो यह पहले ही शोषण कर चुका है। checkCallingOrSelfPermission() का उपयोग फिर से करने का कोई फायदा नहीं है।

+0

प्रश्न का उत्तर नहीं देता है ... दस्तावेज़ चेककॉलिंग स्वयं की अनुमति() का उपयोग करने के खिलाफ चेतावनी देते हैं। क्यूं कर? कोई इसका फायदा कैसे उठा सकता है? –

+0

@ टिमरे। उत्तर संपादित किया गया। जहां तक ​​मुझे पता है, चेककॉलिंगऑरसेल्फ पैरामिशन() शोषक नहीं है। – Swing

+0

फिर भी वास्तव में सवाल का जवाब नहीं देता है: "दस्तावेज 'चेककॉलिंगऑरसेल्फप्रमिशन()' का उपयोग करने के खिलाफ चेतावनी देते हैं। क्यों?"। जब तक आप यह नहीं कह रहे हैं कि दस्तावेज़ गलत हैं, जिन्हें आपको स्पष्ट रूप से कहने के लिए बाइंडर की गहरी समझ की आवश्यकता होगी। –

2

सामान्य परिस्थितियों Binder.callingPid() == Process.myPid() रखता है। यह आईपीसी अनुरोध को संभालने के दौरान बदलता है, सिस्टम को Binder द्वारा संग्रहीत पीआईडी ​​ मूल्य को कॉल करने में संशोधित करता है, यह कॉलर ऐप के पीआईडी ​​को असाइन करता है। हालांकि, यह परिवर्तन केवल उस धागे को प्रभावित करता है जहां दूरस्थ रूप से बुलाया गया विधि निष्पादित किया जाता है, अन्य धागे में समानता अभी भी होती है। इसलिए, यदि checkCallingOrSelfPermission() को ऐसे अप्रभावित धागे में बुलाया जाता है, तो यह PERMISSION_GRANTED लौटाएगा (बशर्ते सेवा ऐप उस अनुमति को रखे) और एक रिसाव (या अन्य बाइबिल के परिणाम) हो सकता है।

वैकल्पिक रूप से, clearCallingIdentity() को checkCallingOrSelfPermission() से पहले बुलाया जाता है, वही समस्या उत्पन्न हो सकती है, हालांकि मुझे विश्वास है कि ऐसा होने की संभावना कम है।

नेक्सस 6 पी, एंड्रॉइड 6.0.1 (MHC19I) पर परीक्षण किया गया।

+1

धन्यवाद, यह स्वीकार्य उत्तर होना चाहिए। –

संबंधित मुद्दे