Android की सुरक्षा टीम, Android प्लैटफ़ॉर्म और Android डिवाइसों के साथ बंडल किए गए कई मुख्य Android ऐप्लिकेशन में, सुरक्षा से जुड़ी कमजोरियों को मैनेज करने के लिए ज़िम्मेदार है.
Android की सुरक्षा टीम, अंदरूनी रिसर्च की मदद से सुरक्षा से जुड़ी जोखिम की संभावनाओं का पता लगाती है. साथ ही, तीसरे पक्षों से मिली गड़बड़ियों की शिकायतों पर भी कार्रवाई करती है. बाहरी गड़बड़ियों के सोर्स में, सुरक्षा से जुड़ी समस्याओं की शिकायत करने के लिए बने फ़ॉर्म के ज़रिए बताई गई समस्याएं, पब्लिश की गई और पहले से पब्लिश की गई अकादमिक रिसर्च, अपस्ट्रीम ओपन सोर्स प्रोजेक्ट के रखरखाव करने वाले लोग, डिवाइस बनाने वाले हमारे पार्टनर की सूचनाएं, और ब्लॉग या सोशल मीडिया पर सार्वजनिक तौर पर बताई गई समस्याएं शामिल हैं.
सुरक्षा से जुड़ी समस्याओं की शिकायत करना
कोई भी डेवलपर, Android उपयोगकर्ता या सुरक्षा विशेषज्ञ, सुरक्षा से जुड़ी समस्याओं के बारे में बताने के लिए फ़ॉर्म भरकर, Android की सुरक्षा टीम को सुरक्षा से जुड़ी संभावित समस्याओं के बारे में बता सकता है.
सुरक्षा से जुड़ी समस्याओं के तौर पर मार्क किए गए गड़बड़ियां, संगठन से बाहर नहीं दिखती हैं. हालांकि, समस्या का आकलन करने या उसे ठीक करने के बाद, इन्हें दिखने दिया जा सकता है. अगर आपको सुरक्षा से जुड़ी किसी समस्या को ठीक करने के लिए, पैच या Compatibility Test Suite (CTS) टेस्ट सबमिट करना है, तो कृपया उसे गड़बड़ी की रिपोर्ट में अटैच करें. साथ ही, AOSP में कोड अपलोड करने से पहले, जवाब मिलने का इंतज़ार करें.
गड़बड़ियों की प्राथमिकता तय करना
सुरक्षा से जुड़े जोखिम को ठीक करने के लिए, सबसे पहले यह पता लगाना ज़रूरी है कि बग कितना गंभीर है और Android के किस कॉम्पोनेंट पर असर पड़ा है. गंभीरता से यह तय होता है कि समस्या को प्राथमिकता कैसे दी जाए. साथ ही, कॉम्पोनेंट से यह तय होता है कि गड़बड़ी को कौन ठीक करता है, किसे सूचना दी जाती है, और उपयोगकर्ताओं के लिए गड़बड़ी को कैसे डिप्लॉय किया जाता है.
कॉन्टेक्स्ट के टाइप
इस टेबल में, हार्डवेयर और सॉफ़्टवेयर की सुरक्षा से जुड़े कॉन्टेक्स्ट की परिभाषाएं दी गई हैं. कॉन्टेक्स्ट को, आम तौर पर प्रोसेस किए जाने वाले डेटा की संवेदनशीलता या उस क्षेत्र के हिसाब से तय किया जा सकता है जहां यह चलता है. सभी सुरक्षा कॉन्टेक्स्ट, सभी सिस्टम पर लागू नहीं होते. इस टेबल में, कम से ज़्यादा अनुमतियों वाले ऐक्सेस को क्रम में लगाया गया है.
| कॉन्टेक्स्ट टाइप | टाइप की परिभाषा |
|---|---|
| सीमित संदर्भ |
ऐसा सीमित वर्शन जिसमें सिर्फ़ कम से कम अनुमतियां दी जाती हैं. उदाहरण के लिए, भरोसेमंद ऐप्लिकेशन, सैंडबॉक्स किए गए एनवायरमेंट में गैर-भरोसेमंद डेटा को प्रोसेस करते हैं. |
| बिना अनुमति वाला कॉन्टेक्स्ट |
बिना खास अनुमति वाले कोड के लिए, एक सामान्य एक्ज़ीक्यूशन एनवायरमेंट. उदाहरण के लिए, ऐसा Android ऐप्लिकेशन जो untrusted_app_all एट्रिब्यूट वाले SELinux डोमेन में काम करता है.
|
| खास जानकारी |
खास सुविधाओं वाला एक प्रोसेसिंग एनवायरमेंट, जिसमें ऐलिमेंट की अनुमतियों का ऐक्सेस हो सकता है. साथ ही, यह एक से ज़्यादा उपयोगकर्ताओं की PII को मैनेज करता है और/या सिस्टम की सुरक्षा बनाए रखता है. उदाहरण के लिए, ऐसा Android ऐप्लिकेशन जिसमें ऐसी सुविधाएं हों जिन पर SELinux untrusted_app डोमेन से पाबंदी लगी हो या privileged|signature अनुमतियों का ऐक्सेस हो.
|
| ओएस कर्नेल |
ऐसी सुविधाएं जो:
|
| भरोसेमंद हार्डवेयर बेस (THB) | आम तौर पर, SoC पर मौजूद अलग-अलग हार्डवेयर कॉम्पोनेंट, जो डिवाइस के मुख्य इस्तेमाल के उदाहरणों (जैसे, सेल्युलर बेसबैंड, डीएसपी, जीपीयू, और एमएल प्रोसेसर) के लिए ज़रूरी फ़ंक्शन उपलब्ध कराते हैं. |
| बूटलोडर चेन | यह एक ऐसा कॉम्पोनेंट है जो डिवाइस को बूट करने पर कॉन्फ़िगर करता है और फिर Android OS को कंट्रोल देता है. |
| ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) | ऐसा कॉम्पोनेंट जिसे खतरनाक ओएस कर्नेल से भी सुरक्षित रखने के लिए डिज़ाइन किया गया है. उदाहरण के लिए, TrustZone और pKVM जैसे हाइपरवाइजर, जो वर्चुअल मशीनों को ओएस कर्नेल से सुरक्षित रखते हैं. |
| सिक्योर एन्क्लेव / सिक्योर एलिमेंट (एसई) |
यह एक वैकल्पिक हार्डवेयर कॉम्पोनेंट है. इसे डिवाइस के सभी अन्य कॉम्पोनेंट और फ़िज़िकल अटैक से सुरक्षित रखने के लिए डिज़ाइन किया गया है. इस बारे में ज़्यादा जानकारी के लिए, सुरक्षित एलिमेंट के बारे में जानकारी लेख पढ़ें. इसमें कुछ Android डिवाइसों में मौजूद Titan-M चिप भी शामिल है. |
गंभीरता
आम तौर पर, किसी बग की गंभीरता से यह पता चलता है कि बग का इस्तेमाल करने पर, क्या नुकसान हो सकता है. समस्या की गंभीरता का पता लगाने के लिए, इन शर्तों का इस्तेमाल करें.
| रेटिंग | एक्सप्लोरेशन के सफल होने का नतीजा |
|---|---|
| सबसे अहम सिद्धांत |
|
| ज़्यादा |
|
| ठीक-ठाक |
|
| कम |
|
| सुरक्षा पर काफ़ी कम असर (एनएसआई) |
|
किराये में बदलाव करने वाले मॉडिफ़ायर
सुरक्षा से जुड़ी कमज़ोरियों की गंभीरता का पता लगाना आम तौर पर आसान होता है. हालांकि, परिस्थितियों के आधार पर रेटिंग बदल सकती हैं.
| वजह | प्रभाव |
|---|---|
| हमला करने के लिए, इसे खास सुविधाओं वाले कॉन्टेक्स्ट में चलाना ज़रूरी है. यह TEE, SE, और pKVM जैसे हाइपरवाइजर पर लागू नहीं होता | -1 गंभीरता |
| जोखिम से जुड़ी जानकारी से, समस्या के असर को कम किया जा सकता है | -1 गंभीरता |
| बायोमेट्रिक ऑथेंटिकेशन को बायपास करने की सुविधा, जिसके लिए डिवाइस के मालिक की बायोमेट्रिक जानकारी की ज़रूरत होती है | -1 गंभीरता |
| कंपाइलर या प्लैटफ़ॉर्म कॉन्फ़िगरेशन, सोर्स कोड में मौजूद किसी जोखिम को कम करते हैं | अगर मौजूदा जोखिम की गंभीरता मध्यम या उससे ज़्यादा है, तो गंभीरता मध्यम |
| इसके लिए, डिवाइस के अंदरूनी हिस्सों को फ़िज़िकल ऐक्सेस करना ज़रूरी है. डिवाइस के बंद होने या चालू होने के बाद से अनलॉक न होने पर भी, ऐसा किया जा सकता है | -1 गंभीरता |
| डिवाइस के चालू होने और पहले से अनलॉक होने के दौरान, डिवाइस के अंदरूनी हिस्सों को फ़िज़िकल ऐक्सेस करना ज़रूरी है | -2 गंभीरता |
| स्थानीय हमला, जिसके लिए बूटलोडर चेन को अनलॉक करना ज़रूरी है | कम से ज़्यादा 'कम' |
| स्थानीय हमला, जिसके लिए डिवाइस पर डेवलपर मोड या डेवलपर मोड की किसी भी सेटिंग को चालू करना ज़रूरी हो. साथ ही, यह हमला डेवलपर मोड में मौजूद किसी गड़बड़ी की वजह से न हो. | कम से ज़्यादा 'कम' |
| अगर Google की दी गई SEPolicy के तहत, कोई भी SELinux डोमेन कार्रवाई नहीं कर सकता | सुरक्षा पर काफ़ी कम असर |
लोकल बनाम प्रोक्सिमल बनाम रिमोट
रिमोट अटैक वेक्टर से पता चलता है कि किसी ऐप्लिकेशन को इंस्टॉल किए बिना या डिवाइस का ऐक्सेस किए बिना, बग का इस्तेमाल किया जा सकता है. इसमें ऐसे बग शामिल हैं जो किसी वेब पेज को ब्राउज़ करने, ईमेल पढ़ने, एसएमएस मैसेज पाने या किसी खतरनाक नेटवर्क से कनेक्ट होने पर ट्रिगर हो सकते हैं.
प्रॉक्सिमल अटैक वेक्टर को रिमोट माना जाता है. इनमें ऐसे बग शामिल होते हैं जिनका फ़ायदा सिर्फ़ तब लिया जा सकता है, जब हमलावर टारगेट डिवाइस के आस-पास हो. उदाहरण के लिए, ऐसा बग जिसमें गलत वाई-फ़ाई या ब्लूटूथ पैकेट भेजने की ज़रूरत होती है. हम अल्ट्रा-वाइडबैंड (यूडब्ल्यूबी) और एनएफ़सी पर आधारित हमलों को प्रोक्सिमल मानते हैं. इसलिए, उन्हें रिमोट हमले माना जाता है.
लोकल अटैक के लिए, हमलावर के पास पीड़ित के डिवाइस का ऐक्सेस होना ज़रूरी है. सिर्फ़ सॉफ़्टवेयर के उदाहरण के तौर पर, ऐसा तब हो सकता है, जब पीड़ित ने नुकसान पहुंचाने वाले किसी ऐप्लिकेशन को इंस्टॉल किया हो या इंस्टैंट ऐप्लिकेशन को चलाने की अनुमति दी हो.
जोड़े गए डिवाइसों (जैसे, ब्लूटूथ साथी डिवाइस) को लोकल डिवाइस माना जाता है. हम जोड़े गए डिवाइस और जोड़े जाने की प्रोसेस में शामिल डिवाइस के बीच अंतर करते हैं.
- ऐसे गड़बड़ियां जिनकी वजह से उपयोगकर्ता, जोड़े जा रहे दूसरे डिवाइस की पहचान करने की सुविधा का इस्तेमाल नहीं कर पाता (जैसे, पुष्टि करना), उन्हें प्रोक्सिमल और इसलिए रिमोट माना जाता है.
- जो गड़बड़ियां, जोड़ने के फ़्लो के दौरान होती हैं, लेकिन उपयोगकर्ता की सहमति (अर्थात अनुमति) से पहले होती हैं उन्हें प्रोक्सिमल और इसलिए रिमोट माना जाता है.
- उपयोगकर्ता की सहमति मिलने के बाद होने वाली गड़बड़ियों को लोकल माना जाता है. भले ही, आखिर में डिवाइसों को जोड़ने की प्रोसेस पूरी न हो पाए.
हमले के फ़िज़िकल वेक्टर को स्थानीय माना जाता है. इनमें ऐसे बग शामिल होते हैं जिनका फ़ायदा सिर्फ़ वह व्यक्ति उठा सकता है जिसके पास डिवाइस का ऐक्सेस है. उदाहरण के लिए, स्क्रीन लॉक में मौजूद कोई बग या ऐसा बग जिसे ठीक करने के लिए यूएसबी केबल को प्लग इन करना पड़ता है. आम तौर पर, डिवाइसों को यूएसबी से कनेक्ट करने के दौरान, डिवाइस अनलॉक रहता है. इसलिए, यूएसबी कनेक्शन की ज़रूरत वाले हमले उतने ही खतरनाक होते हैं, चाहे डिवाइस अनलॉक हो या नहीं.
नेटवर्क की सुरक्षा
Android यह मानता है कि सभी नेटवर्क खतरनाक हैं और वे ट्रैफ़िक पर हमला कर सकते हैं या उस पर नज़र रख सकते हैं. लिंक-लेयर की सुरक्षा (उदाहरण के लिए, वाई-फ़ाई एन्क्रिप्शन), किसी डिवाइस और उससे कनेक्ट किए गए ऐक्सेस पॉइंट के बीच के कम्यूनिकेशन को सुरक्षित रखती है. हालांकि, यह डिवाइस और उन सर्वर के बीच के बाकी लिंक को सुरक्षित नहीं रखती जिनसे वह कम्यूनिकेट कर रहा है.
इसके उलट, एचटीटीपीएस आम तौर पर पूरे कम्यूनिकेशन को एंड-टू-एंड सुरक्षित करता है. इसके लिए, डेटा को सोर्स पर एन्क्रिप्ट (सुरक्षित) किया जाता है. इसके बाद, डेस्टिनेशन पर पहुंचने के बाद ही उसे डिक्रिप्ट (सुरक्षित से सामान्य में बदलना) किया जाता है और उसकी पुष्टि की जाती है. इस वजह से, लिंक-लेयर नेटवर्क की सुरक्षा को कमज़ोर करने वाली कमियों को, एचटीटीपीएस/TLS की कमियों के मुकाबले कम गंभीर माना जाता है: इंटरनेट पर ज़्यादातर कम्यूनिकेशन के लिए, सिर्फ़ वाई-फ़ाई एन्क्रिप्शन काफ़ी नहीं है.
बायोमेट्रिक ऑथेंटिकेशन
बायोमेट्रिक पुष्टि करना एक चुनौती भरा काम है. यहां तक कि सबसे अच्छे सिस्टम भी, मिलते-जुलते डेटा से गुमराह हो सकते हैं. ज़्यादा जानकारी के लिए, Android डेवलपर ब्लॉग: Android 11 में लॉकस्क्रीन और पुष्टि करने की सुविधा में हुए सुधार लेख पढ़ें. गंभीरता की इन रेटिंग से, हमले की दो क्लास के बीच अंतर किया जाता है. इनका मकसद, आखिरी उपयोगकर्ता के लिए असल जोखिम को दिखाना है.
पहले दर्जे के हमलों से, बायोमेट्रिक ऑथेंटिकेशन की सुविधा को सामान्य तरीके से बायपास किया जा सकता है. इसके लिए, डिवाइस के मालिक का अच्छी क्वालिटी का बायोमेट्रिक डेटा होना ज़रूरी नहीं है. उदाहरण के लिए, अगर कोई हमलावर फ़िंगरप्रिंट सेंसर पर गोंद का एक टुकड़ा रखता है और सेंसर पर बचे अवशेषों के आधार पर डिवाइस का ऐक्सेस देता है, तो यह एक आसान हमला है. इसे किसी भी डिवाइस पर किया जा सकता है. इसके लिए, डिवाइस के मालिक की जानकारी की ज़रूरत नहीं होती. इस हमले को सभी डिवाइसों पर लागू किया जा सकता है और इससे बड़ी संख्या में उपयोगकर्ताओं पर असर पड़ सकता है. इसलिए, इस हमले को गंभीरता की सबसे ज़्यादा रेटिंग दी जाती है. उदाहरण के लिए, लॉकस्क्रीन को बायपास करने के लिए, 'गंभीर' रेटिंग.
हमले की दूसरी कैटगरी में, आम तौर पर डिवाइस के मालिक के आधार पर, प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (स्पूफ़) शामिल होता है. कभी-कभी यह बायोमेट्रिक जानकारी आसानी से मिल जाती है. उदाहरण के लिए, अगर किसी व्यक्ति की सोशल मीडिया पर मौजूद प्रोफ़ाइल फ़ोटो, बायोमेट्रिक पुष्टि की सुविधा को धोखा देने के लिए काफ़ी है, तो बायोमेट्रिक बायपास को गंभीरता की सबसे ज़्यादा रेटिंग दी जाएगी. हालांकि, अगर किसी हमलावर को डिवाइस के मालिक से सीधे तौर पर बायोमेट्रिक डेटा हासिल करना पड़ता है, तो यह एक बड़ी समस्या है. इससे हमले का असर उन लोगों पर पड़ता है जो बायोमेट्रिक डेटा का इस्तेमाल करते हैं. इसलिए, इस मामले में -1 का मॉडिफ़ायर लागू होता है. उदाहरण के लिए, हमलावर को डिवाइस के मालिक के चेहरे का इन्फ़्रेरेड स्कैन हासिल करना पड़ता है.
SYSTEM_ALERT_WINDOW और टैपजैकिंग
SYSTEM_ALERT_WINDOW और टैपजैकिंग से जुड़ी हमारी नीतियों के बारे में जानकारी पाने के लिए,
BugHunter University के
सुरक्षा पर कोई असर न डालने वाले बग
पेज पर, "सुरक्षा के लिहाज़ से अहम नहीं होने वाली स्क्रीन पर, टैपजैकिंग/ओवरले SYSTEM_ALERT_WINDOW की समस्या" सेक्शन देखें.
Android Automotive OS में एक से ज़्यादा उपयोगकर्ताओं के लिए सुरक्षा
Android Automotive OS, अन्य डिवाइसों के साइज़, डाइमेंशन या कॉन्फ़िगरेशन के मुकाबले, कई उपयोगकर्ताओं के लिए सुरक्षा का एक अलग मॉडल अपनाता है. Android खाते को एक व्यक्ति के लिए बनाया जाता है. उदाहरण के लिए, किसी दोस्त को कुछ समय के लिए मेहमान उपयोगकर्ता के तौर पर असाइन किया जा सकता है, जो कार के मालिक से गाड़ी उधार लेता है. इस तरह के इस्तेमाल के उदाहरणों को ध्यान में रखते हुए, उपयोगकर्ताओं के पास डिफ़ॉल्ट रूप से, गाड़ी का इस्तेमाल करने के लिए ज़रूरी कॉम्पोनेंट का ऐक्सेस होता है. जैसे, वाई-फ़ाई और मोबाइल नेटवर्क की सेटिंग.
जिस कॉम्पोनेंट पर असर पड़ा है
गड़बड़ी को ठीक करने की ज़िम्मेदारी किस डेवलपमेंट टीम की है, यह इस बात पर निर्भर करता है कि गड़बड़ी किस कॉम्पोनेंट में है. यह Android प्लैटफ़ॉर्म का मुख्य कॉम्पोनेंट, ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (OEM) से मिला कर्नेल ड्राइवर या Pixel डिवाइसों पर पहले से लोड किया गया कोई ऐप्लिकेशन हो सकता है.
AOSP कोड में मौजूद गड़बड़ियों को, Android इंजीनियरिंग टीम हमारी इंटरनल रिपॉज़िटरी में ठीक करती है.
यह कॉम्पोनेंट भी इस बात पर असर डालता है कि उपयोगकर्ताओं को अपडेट कैसे मिलते हैं. फ़्रेमवर्क या कर्नेल में मौजूद गड़बड़ी को ठीक करने के लिए, ओवर-द-एयर (ओटीए) फ़र्मवेयर अपडेट की ज़रूरत होती है. इसे हर OEM को पॉइंट करना होता है. Google Play पर पब्लिश किए गए किसी ऐप्लिकेशन या लाइब्रेरी (उदाहरण के लिए, Gmail, Google Play services या वेबव्यू) में मौजूद बग को, Android उपयोगकर्ताओं को Google Play से अपडेट के तौर पर भेजा जा सकता है.
पार्टनर को सूचना देना
जब Android सुरक्षा बुलेटिन में AOSP की सुरक्षा से जुड़ी किसी समस्या को ठीक कर दिया जाता है, तो हम Android पार्टनर को समस्या की जानकारी देंगे और पैच उपलब्ध कराएंगे. बैकपोर्ट की सुविधा वाले वर्शन की सूची, Android के हर नए वर्शन के साथ बदलती रहती है. जिन डिवाइसों पर इसका इस्तेमाल किया जा सकता है उनकी सूची पाने के लिए, डिवाइस बनाने वाली कंपनी से संपर्क करें.
AOSP में कोड रिलीज़ करना
अगर सुरक्षा से जुड़ा बग AOSP कॉम्पोनेंट में है, तो उपयोगकर्ताओं के लिए ओटीए रिलीज़ होने के बाद, उसे ठीक कर दिया जाता है.
Android के अपडेट पाना
आम तौर पर, Android सिस्टम के अपडेट, डिवाइसों पर ओटीए अपडेट पैकेज के ज़रिए डिलीवर किए जाते हैं. ये अपडेट, डिवाइस बनाने वाली ओईएम कंपनी या डिवाइस के लिए सेवा देने वाली मोबाइल और इंटरनेट सेवा देने वाली कंपनी से मिल सकते हैं. Google Pixel डिवाइस के अपडेट, Google Pixel टीम से मिलते हैं. ये अपडेट, मोबाइल और इंटरनेट सेवा देने वाली कंपनी की तकनीकी तौर पर मंज़ूरी (टीए) की जांच की प्रक्रिया से गुज़रने के बाद मिलते हैं. Google, Pixel फ़ैक्ट्री इमेज भी पब्लिश करता है. इन्हें डिवाइसों पर साइड-लोड किया जा सकता है.
Google की सेवाएं अपडेट करना
Android की सुरक्षा टीम, सुरक्षा से जुड़े बग के लिए पैच उपलब्ध कराने के साथ-साथ, सुरक्षा से जुड़े बग की समीक्षा भी करती है. इससे यह पता चलता है कि उपयोगकर्ताओं को सुरक्षित रखने के दूसरे तरीके हैं या नहीं. उदाहरण के लिए, Google Play सभी ऐप्लिकेशन को स्कैन करता है और सुरक्षा से जुड़े किसी भी बग का फ़ायदा उठाने वाले ऐप्लिकेशन को हटा देता है. Google Play से बाहर के ऐप्लिकेशन इंस्टॉल करने पर, Google Play Services वाले डिवाइसों पर ऐप्लिकेशन की पुष्टि करें सुविधा का इस्तेमाल भी किया जा सकता है. इससे, उपयोगकर्ताओं को ऐसे ऐप्लिकेशन के बारे में चेतावनी दी जा सकती है जो नुकसान पहुंचा सकते हैं.
अन्य संसाधन
Android ऐप्लिकेशन डेवलपर के लिए जानकारी: https://developer.android.com
सुरक्षा से जुड़ी जानकारी, Android Open Source और Developer साइटों पर मौजूद है. शुरू करने के लिए ये जगहें अच्छी हैं:
रिपोर्ट
कभी-कभी, Android की सुरक्षा टीम रिपोर्ट या व्हाइटपेपर पब्लिश करती है. ज़्यादा जानकारी के लिए, सुरक्षा रिपोर्ट देखें.