स्टेजफ्राइट हाल ही में एंड्रॉइड द्वारा देखे गए सबसे खराब कारनामों में से एक है। विशिष्टताओं के बारे में अधिक पढ़ने और अपनी सुरक्षा कैसे करें यह जानने के लिए क्लिक करें!
एंड्रॉइड के सबसे मजबूत बिंदुओं में से एक मुख्य रूप से इसकी ओपन सोर्स प्रकृति रही है, जो हितधारकों को उनकी विशेष आवश्यकताओं के अनुरूप ओएस को फोर्क करने, संशोधित करने और पुनर्वितरित करने की अनुमति देता है। लेकिन जब मैलवेयर और सुरक्षा के मुद्दों की बात आती है तो ओपन सोर्स होने का यह लाभ दोधारी तलवार की तरह काम करता है। जब आपके पास किसी प्रोजेक्ट में बहुत सारे सक्षम योगदानकर्ता हों, जिनका स्रोत कोड निःशुल्क उपलब्ध हो, तो खामियों को ढूंढना और उन्हें ठीक करना आसान होता है। हालाँकि, स्रोत स्तर पर समस्या को ठीक करने से अक्सर अंतिम उपभोक्ता के हाथों में समस्या का समाधान नहीं होता है। इस प्रकार, जब डेटा-संवेदनशील उद्यम आवश्यकताओं के लिए ओएस चुनने की बात आती है तो एंड्रॉइड प्रमुख विकल्प नहीं है।
Google I/O 2014 में, Google ने लॉन्च के साथ अधिक सुरक्षित और उद्यम-अनुकूल पारिस्थितिकी तंत्र की ओर अपना पहला कदम बढ़ाया। एंड्रॉइड फॉर वर्क प्रोग्राम
. एंड्रॉइड फॉर वर्क ने उद्यम की जरूरतों के लिए एक दोहरी प्रोफ़ाइल दृष्टिकोण अपनाया, जिससे आईटी प्रशासक एक बना सकते हैं कर्मचारियों के लिए विशिष्ट उपयोगकर्ता प्रोफ़ाइल - एक काम पर केंद्रित है, अन्य प्रोफ़ाइल कर्मचारियों के व्यक्तिगत के लिए छोड़ दी गई है उपयोग। हार्डवेयर-आधारित एन्क्रिप्शन और व्यवस्थापक-प्रबंधित नीतियों के उपयोग के माध्यम से, कार्य और व्यक्तिगत डेटा अलग और सुरक्षित बने रहे। इसके बाद, बाद के महीनों में एंड्रॉइड फॉर वर्क पर अधिक ध्यान दिया गया, जिसमें मैलवेयर के खिलाफ डिवाइस की सुरक्षा पर बड़ा ध्यान दिया गया। Google ने भी योजना बनाई सभी डिवाइसों के लिए पूर्ण डिवाइस एन्क्रिप्शन सक्षम करें इसे बॉक्स से बाहर एंड्रॉइड लॉलीपॉप के साथ जारी किया जाना था, लेकिन प्रदर्शन संबंधी समस्याओं के कारण इसे रद्द कर दिया गया और इस कदम को ओईएम के कार्यान्वयन के लिए वैकल्पिक बना दिया गया।सुरक्षित एंड्रॉइड के लिए प्रयास पूरी तरह से Google का काम नहीं है, क्योंकि सैमसंग ने इसके माध्यम से इसमें महत्वपूर्ण भूमिका निभाई है AOSP में KNOX का योगदान, जो अंततः एंड्रॉइड फॉर वर्क को मजबूत किया. हालाँकि, जब उद्यम अपनाने की लोकप्रियता की बात आती है, तो एंड्रॉइड में हालिया सुरक्षा शोषण और कमजोरियाँ एक कठिन कार्य की ओर इशारा करती हैं। इसका उदाहरण हालिया स्टेजफ़्राइट भेद्यता है।
सामग्री:
- स्टेजफ़्राइट क्या है?
- स्टेजफ़्राइट कितना गंभीर है?
- स्टेजफ़्राइट को अन्य "विशाल कमजोरियों" से क्या अलग बनाता है?
- अद्यतन दुविधा
- एंड्रॉइड, पोस्ट-स्टेजफ़्राइट
- समापन नोट्स
स्टेजफ़्राइट क्या है?
सरल शब्दों में, स्टेजफ्राइट एक शोषण है जो एंड्रॉइड में मीडिया प्लेबैक के लिए कोड लाइब्रेरी का उपयोग करता है libstagefright. लिबस्टेजफ्राइट इंजन का उपयोग कोड को निष्पादित करने के लिए किया जाता है जो एमएमएस के माध्यम से एक दुर्भावनापूर्ण वीडियो के रूप में प्राप्त होता है, इस प्रकार एक सफल हमले को अंजाम देने के लिए केवल पीड़ित के मोबाइल नंबर की आवश्यकता होती है।
हमने अपने इन-हाउस विशेषज्ञ, XDA के वरिष्ठ मान्यता प्राप्त डेवलपर और डेवलपर एडमिन से संपर्क किया पल्सर_जी2 अधिक विस्तृत विवरण प्रदान करने के लिए।
"जैसा कि मैं यह लिख रहा हूं, [स्टेजफ्राइट] शोषण को ब्लैकहैट में समझाया जाना था [जोड़ना], हालाँकि अभी तक कोई स्लाइड या श्वेत पत्र विवरण उपलब्ध नहीं है।
इसलिए मैं इस स्पष्टीकरण को पूर्ण सटीकता आदि के साथ अत्यधिक गहन स्पष्टीकरण के बजाय क्या हो रहा है, इसके एक मोटे विचार के रूप में दे रहा हूं।
स्टेजफ्राइट को बनाने वाले कई अलग-अलग बग हैं, और इनका अपना सीवीई है [सामान्य कमजोरियाँ और जोखिम] ट्रैकिंग के लिए नंबर:
- सीवीई-2015-1538
- सीवीई-2015-1539
- सीवीई-2015-3824
- सीवीई-2015-3826
- सीवीई-2015-3827
- सीवीई-2015-3828
- सीवीई-2015-3829
दुर्भाग्य से जो पैच उपलब्ध हैं वे सीधे प्रत्येक सीवीई से जुड़े नहीं हैं (जैसा कि उन्हें होना चाहिए), इसलिए इसे समझाना थोड़ा गड़बड़ होगा।
1. [सीवीई-2015-1538]
MPEG4 हैंडलिंग कोड में, 3GPP मेटाडेटा (वह सामग्री जो प्रारूप और अन्य अतिरिक्त जानकारी का वर्णन करती है, जब कोई वीडियो 3GPP प्रारूप में होता है) हैंडलिंग कोड खराब है। इसने मेटाडेटा को अस्वीकार नहीं किया, जहां डेटा अत्यधिक बड़ा था, बल्कि केवल यह जांच कर रहा था कि क्या यह बहुत छोटा था। इसका मतलब यह था कि एक हमलावर के लिए "संशोधित" या "दूषित" फ़ाइल तैयार करना संभव था, जिसमें मेटाडेटा भाग जितना होना चाहिए उससे कहीं अधिक लंबा होगा।
"अविश्वसनीय" डेटा (यानी किसी उपयोगकर्ता से या आपके कोड के बाहर किसी अन्य प्रकार के स्थान से) को संभालने के लिए कोड लिखने में बड़ी चुनौतियों में से एक चर-लंबाई डेटा को संभालना है। वीडियो इसका एक आदर्श उदाहरण हैं. क्या हो रहा है इसके आधार पर सॉफ़्टवेयर को गतिशील रूप से मेमोरी आवंटित करने की आवश्यकता होती है।
इस मामले में, एक बफ़र को कुछ मेमोरी के पॉइंटर के रूप में बनाया जाता है, लेकिन जिस सरणी की ओर यह इंगित करता है उसकी लंबाई एक तत्व बहुत कम थी। मेटाडेटा को तब इस सरणी में पढ़ा गया था, और यह संभव था कि इस सरणी में अंतिम प्रविष्टि "शून्य" (या शून्य) न हो। यह महत्वपूर्ण है कि सरणी में अंतिम आइटम शून्य है, क्योंकि इसी तरह सॉफ़्टवेयर बताता है कि सरणी समाप्त हो गई है। अंतिम मान को गैर-शून्य बनाने में सक्षम होने से (चूंकि सरणी संभावित रूप से एक तत्व बहुत छोटा था), दुर्भावनापूर्ण कोड को कोड के दूसरे भाग द्वारा पढ़ा जा सकता है, और बहुत अधिक डेटा में पढ़ा जा सकता है। इस मान के अंत में रुकने के बजाय, यह अन्य डेटा को पढ़ना जारी रख सकता है जिसे इसे नहीं पढ़ना चाहिए।
(संदर्भ: ओम्निरोम गेरिट)
2. [सीवीई-2015-1539]
UTF-16 स्ट्रिंग होने के कारण मेटाडेटा का न्यूनतम संभव "आकार" 6 बाइट्स होना चाहिए। कोड पूर्णांक मान आकार लेता है, और उसमें से 6 घटा देता है। यदि यह मान 6 से कम था, तो घटाव "अंडरफ्लो" हो जाएगा और चारों ओर लपेट जाएगा, और हम एक बहुत बड़ी संख्या के साथ समाप्त हो जाएंगे। उदाहरण के लिए, कल्पना करें कि क्या आप केवल 0 से 65535 तक ही गिनती कर सकते हैं। यदि आप संख्या 4 लेते हैं, और 6 घटाते हैं, तो आप शून्य से नीचे नहीं जा सकते। तो आप 65535 पर वापस जाएं और वहां से गिनती करें। यहाँ यही हो रहा है!
यदि 6 से कम की लंबाई प्राप्त हुई थी, तो इससे फ़्रेम गलत तरीके से डिकोड हो सकता है, क्योंकि बाइट्सवाप प्रक्रिया वेरिएबल len16 का उपयोग करती है, जिसका मान शुरुआत की गणना से प्राप्त होता है (आकार-6). इससे अपेक्षा से कहीं अधिक बड़ा स्वैप ऑपरेशन हो सकता है, जो फ़्रेम डेटा में अप्रत्याशित तरीके से मान बदल देगा।
(संदर्भ: ओम्निरोम गेरिट)
3. [सीवीई-2015-3824]
एक बड़ी बात! यह बहुत बुरा है. इस अंतिम अंक का बिल्कुल विपरीत है - एक पूर्णांक अतिप्रवाह, जहां एक पूर्णांक "बहुत बड़ा" हो सकता है। यदि आप 65535 तक पहुँच जाते हैं (उदाहरण के लिए) और इससे अधिक की गिनती नहीं कर पाते हैं, तो आप इधर-उधर घूमेंगे, और फिर 0 पर चले जाएँगे!
यदि आप इसके आधार पर मेमोरी आवंटित कर रहे हैं (जो कि स्टेजफ्राइट कर रहा है!), तो आप सरणी में बहुत कम मेमोरी आवंटित करेंगे। जब इसमें डेटा डाला जाता था, तो यह संभावित रूप से दुर्भावनापूर्ण फ़ाइल निर्माता द्वारा नियंत्रित डेटा के साथ असंबंधित डेटा को अधिलेखित कर देता था।
(संदर्भ: ओम्निरोम गेरिट)
4. [सीवीई-2015-3826]
एक और घटिया! पिछले वाले के समान ही - एक और पूर्णांक अतिप्रवाह, जहां एक सरणी (बफर के रूप में प्रयुक्त) को बहुत छोटा बना दिया जाएगा। इससे असंबद्ध स्मृति को अधिलेखित किया जा सकेगा, जो फिर से ख़राब है। कोई व्यक्ति जो मेमोरी में डेटा लिख सकता है, वह अन्य असंबंधित डेटा को दूषित कर सकता है, और संभावित रूप से इसका उपयोग अपने नियंत्रण वाले कुछ कोड को आपके फोन पर चलाने के लिए कर सकता है।
(संदर्भ: ओम्निरोम गेरिट)
5. [सीवीई-2015-3827]
इन पिछले वाले के समान ही। कुछ मेमोरी पर स्किप करते समय एक वेरिएबल का उपयोग किया जाता है, और इसे घटाव के दौरान नकारात्मक बनाया जा सकता है (जैसे ऊपर)। इसके परिणामस्वरूप बहुत बड़ी "स्किप" लंबाई होगी, एक बफर ओवरफ्लो हो जाएगा, जिससे उस मेमोरी तक पहुंच मिल जाएगी जिसे एक्सेस नहीं किया जाना चाहिए।
(संदर्भ: ओम्निरोम गेरिट)
कुछ (संभावित) संबंधित सुधार भी हैं जो इसे [एंड्रॉइड] 5.1 में भी बनाते प्रतीत होते हैं।
(संदर्भ: ओम्निरोम गेरिट)
यह पिछले सुरक्षा सुधार के साथ समस्याओं को रोकने के लिए सीमा जांच जोड़ने के लिए चेक जोड़ता है, जो स्वयं ओवरफ्लो हो सकता है। सी में, जिन संख्याओं को एक हस्ताक्षरित इंट के रूप में दर्शाया जा सकता है, उन्हें एक हस्ताक्षरित इंट के रूप में संग्रहीत किया जाता है। अन्यथा वे संचालन के दौरान अपरिवर्तित रहते हैं। इन जाँचों में, कुछ पूर्णांकों को हस्ताक्षरित (अहस्ताक्षरित के बजाय) बनाया जा सकता था, जिससे बाद में उनका अधिकतम मूल्य कम हो जाएगा, और अतिप्रवाह होने की अनुमति मिल जाएगी।
(संदर्भ: ओम्निरोम गेरिट)
कुछ और पूर्णांक अंडरफ्लो होते हैं (जहां संख्याएं बहुत कम होती हैं, और फिर उन संख्याओं पर घटाव किया जाता है, जिससे वे नकारात्मक हो जाती हैं)। यह फिर से छोटी संख्या के बजाय बड़ी संख्या की ओर ले जाता है, और इससे उपरोक्त जैसी ही समस्याएं उत्पन्न होती हैं।
(संदर्भ: ओम्निरोम गेरिट)
और अंत में, एक और पूर्णांक अतिप्रवाह। पहले की तरह ही, इसका उपयोग अन्यत्र किया जाने वाला है, और यह ओवरफ्लो हो सकता है।
(संदर्भ: ओम्निरोम गेरिट)"
स्टेजफ़्राइट कितना गंभीर है?
के अनुसार ब्लॉग भेजा मूल शोध कंपनी, ज़िम्पेरियम रिसर्च लैब्स द्वारा प्रकाशित, स्टेजफ्राइट शोषण संभावित रूप से उजागर करता है 95% एंड्रॉइड डिवाइस - लगभग 950 मिलियन - इस भेद्यता के लिए क्योंकि यह एंड्रॉइड 2.2 चलाने वाले डिवाइस को प्रभावित करता है और ऊपर। मामले को बदतर बनाने के लिए, जेली बीन 4.3 से पहले के उपकरण "सबसे खराब जोखिम" पर हैं क्योंकि इनमें इस शोषण के खिलाफ पर्याप्त शमन नहीं हैं।
स्टेजफ्राइट से होने वाले नुकसान के संबंध में, पल्सर_जी2 ने टिप्पणी की:
[ब्लॉककोट लेखक = "पल्सर_जी 2"] "अपने आप में, स्टेजफ्राइट फोन पर सिस्टम उपयोगकर्ता तक पहुंच प्रदान करेगा। हालाँकि वास्तव में इसका दुरुपयोग करने के लिए आपको एएसएलआर (एड्रेस स्पेस लेआउट रैंडमाइजेशन) को बायपास करना होगा। यह हासिल किया गया है या नहीं यह अभी अज्ञात है। यह शोषण सिस्टम या मीडिया उपयोगकर्ता के रूप में आपके डिवाइस पर "मनमाना कोड" चलाने देता है। उनके पास डिवाइस पर ऑडियो और कैमरे तक पहुंच है, और सिस्टम उपयोगकर्ता रूट एक्सप्लॉइट लॉन्च करने के लिए एक शानदार जगह है। क्या आपको वे सभी अद्भुत रूट कारनामे याद हैं जिनका उपयोग आपने अपने फ़ोन को रूट करने के लिए किया था?
इन्हें संभावित रूप से आपके डिवाइस पर रूट हासिल करने के लिए चुपचाप उपयोग किया जा सकता है! जिसके पास रूट है वह फोन का मालिक है। उन्हें SELinux को बायपास करना होगा, लेकिन टॉवेलरूट ने इसे प्रबंधित किया, और पिंगपोंग ने भी इसे प्रबंधित किया है। एक बार जब वे रूट हो जाते हैं, तो आपके फ़ोन की हर चीज़ उनके लिए खुली होती है। संदेश, कुंजियाँ, आदि।"[/ब्लॉककोट]सबसे खराब स्थिति के बारे में बात करते हुए, कोड वितरित करने और इस शोषण को ट्रिगर करने के लिए केवल एक एमएमएस की आवश्यकता होती है। प्रयोगकर्ता संदेश खोलने की भी आवश्यकता नहीं है क्योंकि बहुत सारे मैसेजिंग ऐप उपयोगकर्ता के साथ इंटरैक्ट करने से पहले एमएमएस को प्री-प्रोसेस करते हैं। यह स्पीयर-फ़िशिंग हमलों से अलग है क्योंकि उपयोगकर्ता एक सफल हमले से पूरी तरह से बेखबर हो सकता है, और फ़ोन में सभी वर्तमान और भविष्य के डेटा से समझौता कर सकता है।
स्टेजफ्राइट को अन्य "बड़ी कमजोरियों" से क्या अलग बनाता है?
"सभी कमजोरियाँ उपयोगकर्ताओं के लिए कुछ जोखिम पैदा करती हैं। यह विशेष रूप से जोखिम भरा है, क्योंकि अगर किसी को दूर से इस पर हमला करने का कोई तरीका मिल जाता है (जो कि है)। संभव है, यदि एएसएलआर से बचने का कोई रास्ता मिल गया हो), इससे पहले कि आपको एहसास हो कि आप इसके अधीन हैं, इसे ट्रिगर किया जा सकता है आक्रमण करना"
एंड्रॉइड इंस्टालर हाईजैकिंग, फेकआईडी जैसे पुराने कारनामों के साथ-साथ टॉवेलरूट और पिंगपोंग जैसे रूट कारनामों को निष्पादित करने के लिए कुछ बिंदु पर उपयोगकर्ता की सहभागिता की आवश्यकता होती है। हालाँकि वे अभी भी इस तथ्य का "शोषण" कर रहे हैं कि यदि दुर्भावनापूर्ण तरीके से उपयोग किया जाए तो बहुत अधिक नुकसान हो सकता है, तथ्य यह है कि स्टेजफ्राइट सैद्धांतिक रूप से किसी पीड़ित के फ़ोन को ट्रोजन में बदलने के लिए केवल उसके मोबाइल नंबर की आवश्यकता होती है और इसलिए हाल ही में इस पर इतना अधिक ध्यान दिया जा रहा है दिन.
हालाँकि, एंड्रॉइड पूरी तरह से इस शोषण की दया पर निर्भर नहीं है। एंड्रॉइड सिक्योरिटी के लीड इंजीनियर, एड्रियन लुडविग ने कुछ चिंताओं को संबोधित किया Google+ पोस्ट:
[ब्लॉककोट लेखक = "एड्रियन लुडविग"] "एक आम, गलत धारणा है कि किसी भी सॉफ़्टवेयर बग को सुरक्षा शोषण में बदला जा सकता है। वास्तव में, अधिकांश बग शोषण योग्य नहीं हैं और एंड्रॉइड ने उन बाधाओं को सुधारने के लिए कई चीजें की हैं...
आइसक्रीम सैंडविच (एंड्रॉइड 4.0) के बाद से पेश की गई कुछ तकनीकों की सूची सूचीबद्ध है यहाँ. इनमें से सबसे प्रसिद्ध एड्रेस स्पेस लेआउट रैंडमाइजेशन (एएसएलआर) कहा जाता है, जो पूरी तरह से पूरा हो गया था एंड्रॉइड 4.1 में पीआईई (पोजीशन इंडिपेंडेंट एक्ज़ीक्यूटेबल्स) के समर्थन के साथ और अब 85% से अधिक एंड्रॉइड पर है उपकरण। यह तकनीक किसी हमलावर के लिए कोड के स्थान का अनुमान लगाना अधिक कठिन बना देती है, जो एक सफल शोषण के लिए आवश्यक है...
हम एएसएलआर पर ही नहीं रुके, हमने एनएक्स, फोर्टिफाईसोर्स, रीड-ओनली-रीलोकेशन्स, स्टैक कैनरीज़ और भी बहुत कुछ जोड़ा है।"[/ब्लॉककोट]
हालाँकि, अभी भी इस बात से इनकार नहीं किया जा सकता है कि एंड्रॉइड के भविष्य के लिए स्टेजफ्राइट एक गंभीर मामला है, और इसमें शामिल हितधारकों द्वारा इसे गंभीरता से लिया जा रहा है। स्टेजफ्राईट ने कमरे में सफेद हाथियों पर भी प्रकाश डाला - विखंडन की समस्या और अपडेट अंततः उपभोक्ता तक पहुंचते हैं।
अद्यतन दुविधा
अपडेट की बात करें तो यह देखना अच्छा है कि ओईएम उपयोगकर्ताओं की सुरक्षा की जिम्मेदारी ले रहे हैं, जैसा कि कई लोगों ने वादा किया है विशेष रूप से स्टेजफ्राइट जैसे कारनामों के लिए सुरक्षा सुधार और पैच को शामिल करने के लिए अद्यतन प्रक्रिया में सुधार करें।
Google ने सबसे पहले आधिकारिक बयान जारी करने का वादा किया है मासिक सुरक्षा अद्यतन (योजनाबद्ध ओएस और प्लेटफ़ॉर्म अपडेट के अलावा) इसके अधिकांश नेक्सस उपकरणों के लिए, जिसमें लगभग 3 साल पुराना नेक्सस 4 भी शामिल है। सैमसंग ने भी इसका अनुसरण करते हुए घोषणा की है कि वह इसे लागू करने के लिए वाहकों और भागीदारों के साथ काम करेगा मासिक सुरक्षा अद्यतन कार्यक्रम लेकिन यह इस कार्यान्वयन के उपकरणों और समयरेखा विवरण को निर्दिष्ट करने में विफल रहा। यह दिलचस्प है क्योंकि इसमें वाहकों के सहयोग से सुरक्षा अद्यतनों के लिए "फास्ट ट्रैक" दृष्टिकोण का उल्लेख है, इसलिए हम ऐसा कर सकते हैं कैरियर पर अधिक लगातार अपडेट की अपेक्षा करें (यद्यपि सुरक्षा आधारित, लेकिन उम्मीद है कि यह फर्मवेयर अपग्रेड में भी तेजी लाएगा)। उपकरण।
पैक में शामिल होने वाले अन्य ओईएम में एलजी भी शामिल है जो इसके साथ जुड़ेगा मासिक सुरक्षा अद्यतन. मोटोरोला ने भी घोषणा की है उन उपकरणों की सूची जिन्हें अद्यतन किया जाएगा स्टेजफ्राइट फिक्स के साथ, और सूची में कंपनी द्वारा 2013 के बाद से बनाए गए लगभग सभी डिवाइस शामिल हैं। ऐसा सोनी ने भी कहा है इसके उपकरणों को जल्द ही पैच प्राप्त होंगे बहुत।
एक बार के लिए, वाहक भी अपडेट के साथ आ रहे हैं। स्प्रिंट के पास है एक बयान जारी किया कुछ डिवाइसों को पहले ही स्टेजफ्राइट पैच प्राप्त हो चुका है, और अधिक डिवाइसों को अपडेट के लिए शेड्यूल किया गया है। AT&T ने भी इसका अनुसरण किया है कुछ उपकरणों को पैच जारी करके। वेरिज़ोन ने पैच भी जारी किया है, हालांकि यह एक धीमा रोलआउट है जो गैलेक्सी एस 6 एज और नोट 4 जैसे हाई-एंड स्मार्टफोन को प्राथमिकता देता है। टी-मोबाइल नोट 4 को स्टेजफ्राइट पैच अपडेट भी प्राप्त हुआ।
एक अंतिम उपयोगकर्ता के रूप में, कुछ एहतियाती कदम हैं जो आप पर हमला होने की संभावना को कम करने के लिए उठाए जा सकते हैं। शुरुआत के लिए, अपने फोन पर मौजूद मैसेजिंग ऐप्स में एमएमएस संदेशों की ऑटो पुनर्प्राप्ति अक्षम करें। इससे उन मामलों पर नियंत्रण रहना चाहिए जहां शोषण के काम करने के लिए किसी उपयोगकर्ता इंटरैक्शन की आवश्यकता नहीं थी। इसके बाद, अज्ञात और अविश्वसनीय स्रोतों से एमएमएस संदेशों से मीडिया डाउनलोड करने से बचने का ध्यान रखें।
एक XDA पावर उपयोगकर्ता के रूप में, आप भी कर सकते हैं स्टेजफ्राइट को अक्षम करने के लिए अपने बिल्ड प्रोप पर संपादन करें. यह अपने आप को स्टेजफ्राइट से बचाने का पूर्ण और निश्चित तरीका नहीं है, लेकिन यदि आप पुराने एंड्रॉइड बिल्ड पर अटके हुए हैं तो आप एक सफल हमले की संभावना को कम करने के लिए अपने मौके का लाभ उठा सकते हैं। कस्टम ROM समाधान भी हैं, जिनमें से अधिकांश नियमित आधार पर AOSP के साथ स्रोतों को सिंक करते हैं और इसलिए, इसमें स्टेजफ्राइट फिक्स शामिल होंगे। यदि आप AOSP आधारित ROM चला रहे हैं, तो यह अत्यधिक अनुशंसित है कि आप ROM की एक नई रिलीज़ को अपडेट करें जिसमें स्टेजफ्राइट पैच शामिल हैं। आप उपयोग कर सकते हैं यह एप यह जाँचने के लिए कि क्या आपका वर्तमान दैनिक ड्राइवर स्टेजफ़्राइट से प्रभावित है।
एंड्रॉइड, पोस्ट-स्टेजफ़्राइट
स्टेजफ्राइट एंड्रॉइड और इसके विखंडन के साथ-साथ अपडेट की समस्या के प्रति एक चेतावनी के अलावा और कुछ नहीं है। यह इस बात पर प्रकाश डालता है कि कैसे कोई स्पष्ट तंत्र नहीं है जिसके माध्यम से ऐसे महत्वपूर्ण सुधारों को कई उपकरणों में समय पर लागू किया जा सके। जबकि ओईएम उपकरणों के लिए पैच तैयार करने की कोशिश कर रहे हैं, लेकिन कड़वी सच्चाई यह है कि इनमें से अधिकांश सुधार केवल हाल के फ्लैगशिप तक ही सीमित होंगे। अन्य गैर-फ्लैगशिप और पुराने उपकरण, छोटे ओईएम से तो दूर, स्टेजफ्राइट की तरह उजागर होते रहेंगे।
इस कारनामे में एक आशा की किरण है: इसने एंड्रॉइड की अपडेट प्रक्रिया पर फिर से ध्यान आकर्षित किया और इसे एक ऐसे प्रकाश में रखा जो भविष्य में कई कॉर्पोरेट कंपनियों को उद्यम उपयोग के लिए एंड्रॉइड को अपनाने के लिए आकर्षित नहीं करेगा। जैसे-जैसे Google अधिक उद्यम अपनाने की दिशा में काम करता है, उसे अपनी अद्यतन रणनीति और OEM को अनुमति देने वाले नियंत्रण की मात्रा पर पुनर्विचार करने के लिए मजबूर होना पड़ेगा।
एंड्रॉइड एम दिन-ब-दिन बाजार में रिलीज होने के करीब आ रहा है, इसमें कोई आश्चर्य नहीं होगा अगर Google ने अपने प्ले सर्विसेज पैकेज के पक्ष में एओएसपी के अधिक से अधिक घटकों को अलग करने का फैसला किया। आख़िरकार, यह एक ऐसा क्षेत्र है जिस पर Google अभी भी पूर्ण नियंत्रण रखता है यदि किसी डिवाइस को Google Play Store के साथ शिप किया जाना है। यह इसके अपने नकारात्मक पहलू हैं खुले स्रोत वाले क्षेत्रों को निकट स्रोत वाली दीवारों से बदलने के रूप में।
एंड्रॉइड के भविष्य का अनुमान लगाते समय, एक (बहुत छोटी) संभावना है कि Google उन परिवर्तनों को भी सीमित कर सकता है जो OEM AOSP में कर सकते हैं। साथ आरआरओ ढांचा एंड्रॉइड एम में कार्यात्मक स्थिति में मौजूद होने के कारण, Google ओईएम को आरआरओ स्किन के रूप में केवल कॉस्मेटिक परिवर्तन करने के लिए प्रतिबंधित कर सकता है। इससे तेजी से अपडेट परिनियोजन की अनुमति मिलनी चाहिए, लेकिन इसकी कीमत ओईएम को एंड्रॉइड को पूरी तरह से अनुकूलित करने के अवसर से वंचित करना होगा।
एक अन्य मार्ग जो एक संभावना हो सकती है वह यह होगा कि शिपिंग के साथ आने वाले सभी उपकरणों के लिए इसे अनिवार्य बनाया जाए Google Play Store को एक निश्चित समयावधि, संभवतः दो, के लिए गारंटीकृत सुरक्षा अपडेट प्राप्त होंगे साल। महत्वपूर्ण सुरक्षा अपडेट और पैच की उपस्थिति की जांच करने के लिए प्ले सर्विसेज फ्रेमवर्क का उपयोग किया जा सकता है, अनुपालन न होने की स्थिति में प्ले स्टोर की पहुंच रद्द कर दी जाएगी।
समापन नोट्स
यह अभी भी अटकलें ही हैं क्योंकि इस समस्या को ठीक करने का कोई शानदार तरीका नहीं है। अत्यधिक अधिनायकवादी दृष्टिकोण की कमी के कारण, सुधारों की पहुंच में हमेशा कुछ न कुछ कमी रहेगी। एंड्रॉइड डिवाइसों की भारी संख्या के कारण, प्रत्येक डिवाइस की सुरक्षा की स्थिति पर नज़र रखना एक बहुत बड़ा काम होगा। समय की मांग है कि एंड्रॉइड अपडेट के तरीके पर पुनर्विचार किया जाए क्योंकि मौजूदा तरीका निश्चित रूप से सबसे अच्छा नहीं है। XDA डेवलपर्स में हम उम्मीद करते हैं कि Google की क्लोज्ड सोर्स योजनाओं के साथ काम करते हुए एंड्रॉइड अभी भी अपनी ओपन-सोर्स जड़ों के प्रति सच्चा बना रहेगा।
क्या आपका फ़ोन स्टेजफ़्राइट के प्रति संवेदनशील है? क्या आपको लगता है कि आपके फ़ोन को कभी स्टेजफ़्राइट पैच प्राप्त होगा? नीचे टिप्पणी करके हमें बताएं!