Android की सुरक्षा टीम Android डिवाइसों के साथ बंडल किए गए कई मुख्य Android ऐप्लिकेशन और Android प्लैटफ़ॉर्म शामिल होते हैं.
Android की सुरक्षा टीम, अंदरूनी रिसर्च के ज़रिए सुरक्षा से जुड़े जोखिमों का पता लगाती है और साथ ही तीसरे पक्ष की ओर से रिपोर्ट की गई गड़बड़ियों के जवाब देती हैं. बाहरी गड़बड़ियां होने की वजहों में, रिपोर्ट की गई समस्याएं शामिल हैं से जोखिम की आशंका से जुड़ा फ़ॉर्म, शिक्षा से जुड़ी रिसर्च पब्लिश और पहले से पब्लिश की गई हो, अपस्ट्रीम ओपन सोर्स प्रोजेक्ट मेंटेनर, हमारे डिवाइस मैन्युफ़ैक्चरर पार्टनर से मिली सूचनाओं के साथ-साथ, सार्वजनिक तौर पर ज़ाहिर की गई समस्याओं को ब्लॉग या सोशल मीडिया पर शेयर करें.
सुरक्षा से जुड़ी समस्याओं की शिकायत करना
कोई भी डेवलपर, Android उपयोगकर्ता या सुरक्षा शोधकर्ता, Android सुरक्षा टीम को समस्याओं का सामना करना पड़ सकता है. जोखिम की आशंका से जुड़ा फ़ॉर्म भरें.
सुरक्षा से जुड़ी समस्याओं के तौर पर मार्क की गई गड़बड़ियां, बाहरी तौर पर नहीं दिखतीं. हालांकि, इन गड़बड़ियों को बाद में देखा जा सकता है समस्या का आकलन करने या उसे हल करने के बाद दिखेगा. अगर आपको पैच सबमिट करना है या सुरक्षा से जुड़ी समस्या को हल करने के लिए, कृपया इसे गड़बड़ी के साथ अटैच करें एओएसपी में कोड अपलोड करने से पहले, उसके जवाब का इंतज़ार करें.
गड़बड़ियों की जांच करना
सुरक्षा से जुड़े जोखिम की आशंका से निपटने का पहला काम, गड़बड़ी की गंभीरता की पहचान करना और Android के किस कॉम्पोनेंट पर असर पड़ा है. गंभीरता से यह तय होता है कि समस्या को किस तरह प्राथमिकता दी जाती है. इसके साथ ही, कॉम्पोनेंट यह तय करता है कि गड़बड़ी को कौन ठीक करता है, इसकी सूचना किसे दी जाती है, और समस्या को कैसे लागू किया जाता है उपयोगकर्ताओं को प्राथमिकता देनी चाहिए.
संदर्भ के टाइप
इस टेबल में, हार्डवेयर और सॉफ़्टवेयर की सुरक्षा से जुड़े कॉन्टेक्स्ट की परिभाषा दी गई है. कॉन्टेक्स्ट ये काम कर सकता है आम तौर पर प्रोसेस किए जाने वाले डेटा या उस एरिया से तय होती है जिसमें वह मौजूद होता है. नहीं सभी सुरक्षा कॉन्टेक्स्ट सभी सिस्टम पर लागू होते हैं. यह टेबल कम से कम से ज़्यादा के क्रम में है खास अधिकार के लिए.
| संदर्भ का टाइप | टाइप की परिभाषा |
|---|---|
| सीमित संदर्भ |
एक सीमित एक्ज़ीक्यूशन एनवायरमेंट, जहां सबसे कम अनुमतियां ही उपलब्ध होती हैं
दिया गया है. उदाहरण के लिए, किसी सैंडबॉक्स में भेजे गए गैर-भरोसेमंद डेटा को प्रोसेस करने वाले भरोसेमंद ऐप्लिकेशन पर्यावरण को ध्यान में रखकर काम करना. |
| बिना अनुमति के कॉन्टेक्स्ट |
एक सामान्य एक्ज़ीक्यूशन एनवायरमेंट, जिसकी उम्मीद अनचाहे कोड से होती है. उदाहरण के लिए, एक ऐसा Android ऐप्लिकेशन जो एक SELinux डोमेन में untrusted_app_all एट्रिब्यूट की वैल्यू सबमिट करें.
|
| खास अधिकारों वाला कॉन्टेक्स्ट |
यह खास तौर पर लागू होने वाला एक ऐसा एनवायरमेंट है जिसमें बेहतर अनुमतियों, हैंडल का ऐक्सेस हो सकता है
एक से ज़्यादा उपयोगकर्ताओं की व्यक्तिगत पहचान से जुड़ी जानकारी मौजूद होनी चाहिए और/या सिस्टम को पूरी सुरक्षा देने की ज़रूरत नहीं है. उदाहरण के लिए, ऐसी क्षमताओं वाला Android ऐप्लिकेशन जिन्हें SELinux untrusted_app डोमेन या इसके ऐक्सेस के साथ
privileged|signature अनुमतियां.
|
| OS कर्नेल |
ऐसी सुविधाएं जो:
|
| भरोसेमंद हार्डवेयर बेस (THB) | आम तौर पर, SoC पर हार्डवेयर कॉम्पोनेंट अलग-अलग होते हैं, जो ज़रूरी फ़ंक्शन देते हैं डिवाइस के मुख्य इस्तेमाल के उदाहरणों (जैसे कि सेल्युलर बेसबैंड, DSP, जीपीयू, और एमएल) से प्रोसेसर). |
| बूटलोडर चेन | एक कॉम्पोनेंट जो बूट पर डिवाइस को कॉन्फ़िगर करता है और फिर Android OS को कंट्रोल पास करता है. |
| ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) | एक ऐसा कॉम्पोनेंट जिसे प्रतिद्वंद्वी ओएस कर्नेल से भी सुरक्षित रखने के लिए डिज़ाइन किया गया है (उदाहरण के लिए, TrustZone और हाइपरवाइज़र, जैसे कि pKVM, जो ओएस से वर्चुअल मशीन को सुरक्षित रखते हैं कर्नेल). |
| सिक्योर एनक्लेव / सिक्योर एलिमेंट (एसई) |
एक वैकल्पिक हार्डवेयर कॉम्पोनेंट, जिसे
किसी डिवाइस पर हमले या शारीरिक हमले के बाद, आपको
सुरक्षा एलिमेंट के बारे में जानकारी. इसमें, कुछ Android डिवाइसों में मौजूद Titan-M चिप भी शामिल है. |
गंभीरता
आम तौर पर, किसी बग की गंभीरता से उस संभावित नुकसान की जानकारी मिलती है जो गड़बड़ी के ठीक होने पर होता है इसका सही इस्तेमाल नहीं किया जा सका. गंभीरता का पता लगाने के लिए, इन शर्तों को पूरा करें.
| रेटिंग | सफल शोषण का नतीजा |
|---|---|
| सबसे अहम सिद्धांत |
|
| ज़्यादा |
|
| ठीक-ठाक |
|
| कम |
|
| सुरक्षा पर कुछ हद तक असर (एनएसआई ) |
|
रेटिंग मॉडिफ़ायर
सुरक्षा से जुड़े जोखिमों की गंभीरता का पता लगाना आसान होता है, लेकिन रेटिंग में बदलाव हो सकते हैं स्थितियों के आधार पर.
| वजह | प्रभाव |
|---|---|
| हमला करने के लिए, खास कॉन्टेक्स्ट के तौर पर चलाना ज़रूरी है (TEE, SE, जैसे, pKVM) | -1 गंभीरता |
| जोखिम की आशंका से जुड़ी जानकारी, समस्या के असर को सीमित करती है | -1 गंभीरता |
| बायोमेट्रिक ऑथेंटिकेशन बायपास, जिसके लिए सीधे डिवाइस का मालिक | -1 गंभीरता |
| कंपाइलर या प्लैटफ़ॉर्म कॉन्फ़िगरेशन, सोर्स कोड में जोखिम की आशंका को कम करते हैं | अगर जोखिम की आशंका सामान्य या ज़्यादा हो, तो सामान्य तौर पर |
| डिवाइस के अंदर के हिस्सों का फ़िज़िकल ऐक्सेस ज़रूरी होता है. हालांकि, डिवाइस के बंद या बंद होने पर भी इसका इस्तेमाल किया जा सकता है चालू होने के बाद से, अनलॉक नहीं किया गया है | -1 गंभीरता |
| डिवाइस के चालू होने और उसके पहले से इस्तेमाल होने पर, डिवाइस के अंदर के हिस्से का ऐक्सेस ज़रूरी है अनलॉक किया गया | -2 गंभीरता |
| ऐसा लोकल हमला जिसके लिए बूटलोडर चेन को अनलॉक करने की ज़रूरत होती है | कम से ज़्यादा नहीं |
| ऐसा लोकल हमला जिसके लिए डेवलपर मोड या किसी स्थायी डेवलपर मोड सेटिंग की ज़रूरत होती है चालू हो और डेवलपर मोड में कोई गड़बड़ी न हो. | कम से ज़्यादा नहीं |
| यदि कोई भी SELinux डोमेन Google द्वारा प्रदान की गई SEPolicy के तहत संचालन नहीं कर सकता है | सुरक्षा पर नगण्य प्रभाव |
स्थानीय बनाम प्रॉक्सी बनाम रिमोट
रिमोट अटैक वेक्टर से पता चलता है कि ऐप्लिकेशन को इंस्टॉल किए बिना गड़बड़ी का फ़ायदा उठाया जा सकता है या उन्हें डिवाइस तक ऐक्सेस नहीं किया जा सकता. इसमें वे बग शामिल हैं, जिन्हें वेब पेज पर जाना, कोई ईमेल पढ़ना, एसएमएस मैसेज पाना या किसी गलत नेटवर्क से जुड़ना.
प्रॉक्सी अटैक वेक्टर को रिमोट माना जाता है. इनमें ऐसी गड़बड़ियां शामिल हैं जिनका सिर्फ़ फ़ायदा उठाया जा सकता है किसी ऐसे हमलावर की ओर से जो टारगेट किए गए डिवाइस के आस-पास हो. उदाहरण के लिए, ऐसा बग गलत वाई-फ़ाई या ब्लूटूथ पैकेट भेज रहे हैं. हम अल्ट्रा-वाइडबैंड (यूडब्ल्यूबी) और एनएफ़सी की मदद से काम करते हैं प्रॉक्सी के रूप में और दूर से हमला करता है.
स्थानीय हमलों के लिए यह ज़रूरी है कि हमलावर के पास पीड़ित तक पहले से पहुंच हो. एक काल्पनिक स्थिति में के लिए सॉफ़्टवेयर का उदाहरण दिया गया है, लेकिन नुकसान पहुंचाने वाले ऐसे ऐप्लिकेशन के ज़रिए ऐसा किया जा सकता है जिसे पीड़ित ने इंस्टॉल किया है या इंस्टैंट ऐप्लिकेशन जो उनके पास है को चलाने की सहमति दी गई.
सफलतापूर्वक जोड़े गए डिवाइस (जैसे कि ब्लूटूथ वाले कंपैनियन डिवाइस) को लोकल माना जाता है. बुध जोड़े गए डिवाइस और पेयर किए जा रहे डिवाइस के बीच फ़र्क़ करना फ़्लो.
- ऐसी गड़बड़ियां जो जोड़े गए दूसरे डिवाइस को पहचानने की उपयोगकर्ता की क्षमता को कम कर देती हैं (जैसे, पुष्टि करने के तरीके) प्रॉक्सी के तौर पर दिखते हैं, इसलिए इन्हें रिमोट माना जाता है.
- दूसरे डिवाइस से जोड़ने की प्रोसेस के दौरान, लेकिन उपयोगकर्ता की सहमति (जैसे कि अनुमति देने) से पहले होने वाली गड़बड़ियां को प्रॉक्सी के तौर पर दिखाया जाता है. इसलिए, इन्हें रिमोट माना जाता है.
- उपयोगकर्ता की सहमति मिलने के बाद होने वाली गड़बड़ियों को लोकल माना जाता है. भले ही, पेयर नहीं हो पाता है.
फ़िज़िकल अटैक वेक्टर को लोकल माना जाता है. इनमें ऐसी गड़बड़ियां शामिल हैं जिनका फ़ायदा सिर्फ़ लोग कोई हमलावर जिसके पास डिवाइस का फ़िज़िकल ऐक्सेस हो. उदाहरण के लिए, लॉक स्क्रीन में कोई बग या इसके लिए, यूएसबी केबल को प्लग-इन करना पड़ता है. डिवाइस का अनलॉक होना आम बात है यूएसबी कनेक्शन की ज़रूरत होने पर, हमले की गंभीरता एक जैसी होती है. इससे कोई फ़र्क़ नहीं पड़ता कि कि डिवाइस को अनलॉक करने की ज़रूरत है या नहीं.
नेटवर्क सिक्योरिटी
Android यह मानता है कि सभी नेटवर्क एक-दूसरे के विरोधी हैं. ऐसे में, हो सकता है कि वे नेटवर्क पर हमला कर रहे हों या उसकी जासूसी कर रहे हों ट्रैफ़िक कम कर सकता है. लिंक-लेयर सुरक्षा (जैसे, वाई-फ़ाई एन्क्रिप्शन), बातचीत को सुरक्षित रखती है से कनेक्ट होते हैं, तो यह डिवाइस और जिन सर्वर से वह कनेक्ट कर रहा है उनकी चेन की चेन में बचे हुए लिंक.
इसके उलट, एचटीटीपीएस आम तौर पर डेटा को एन्क्रिप्ट करके, पूरे कम्यूनिकेशन को एंड तक सुरक्षित रखता है पर भेजा जाता है, फिर अपने अंतिम गंतव्य पर पहुंचने के बाद उसे डिक्रिप्ट करके सत्यापित किया जाता है. इस वजह से, लिंक-लेयर नेटवर्क की सुरक्षा को जोखिम में डालने वाले जोखिम कम हो जाते हैं एचटीटीपीएस/टीएलएस में जोखिम की आशंकाओं से ज़्यादा गंभीर है: ज़्यादातर मामलों में वाई-फ़ाई एन्क्रिप्ट करना काफ़ी नहीं है का ध्यान रखना चाहिए.
बायोमेट्रिक पुष्टि
बायोमेट्रिक ऑथेंटिकेशन एक चुनौती भरा काम है. यहां तक कि अच्छे सिस्टम को भी उपयोगकर्ता धोखा दे सकते हैं नज़दीकी मिलान (देखें Android Developers ब्लॉग: Android 11 की लॉकस्क्रीन और पुष्टि करने के तरीके में किए गए सुधार). गंभीरता की ये रेटिंग, दो तरह के हमलों में अंतर करती हैं और इनका मकसद असली उपयोगकर्ता को होने वाले असल जोखिम के बारे में बताता है.
पहली कैटगरी के हमलों में, बायोमेट्रिक ऑथेंटिकेशन को सामान्य तरीके से बायपास किया जा सकता है. को मालिक की ओर से अच्छी क्वालिटी का बायोमेट्रिक डेटा उपलब्ध नहीं कराना चाहिए. उदाहरण के लिए, अगर कोई हमलावर यह फ़िंगरप्रिंट सेंसर पर मौजूद गम का टुकड़ा होता है. साथ ही, बची हुई चीज़ के आधार पर डिवाइस को ऐक्सेस देता है यह एक साधारण हमला है, जो किसी भी संवेदनशील डिवाइस पर किया जा सकता है. यह डिवाइस के मालिक की किसी भी जानकारी की ज़रूरत नहीं होती है. यह ध्यान में रखते हुए कि यह सामान्य है और ज़्यादा लोगों पर असर डाल सकता है. इसलिए, इस हमले को पूरी गंभीरता से रेटिंग दी जाती है (उदाहरण के लिए, लॉकस्क्रीन बायपास के लिए, हाई).
हमलों के एक अन्य ग्रुप में आम तौर पर, अटैक इंस्ट्रुमेंट (स्पूफ़) आधारित होता है डिवाइस मालिक पर. कभी-कभी बायोमेट्रिक जानकारी आसानी से हासिल की जा सकती है (इसके लिए उदाहरण के लिए, अगर सोशल मीडिया पर किसी व्यक्ति की प्रोफ़ाइल फ़ोटो, बायोमेट्रिक पुष्टि को गुमराह करने के लिए काफ़ी है, तो बायोमेट्रिक बायपास को पूरी गंभीरता की रेटिंग मिलेगी). हालांकि, अगर किसी हमलावर को इसकी ज़रूरत होगी, का इस्तेमाल, सीधे डिवाइस के मालिक से बायोमेट्रिक डेटा हासिल करने के लिए किया है. उदाहरण के लिए, उनका चेहरा दिखाई देता है, तो यह काफ़ी बड़ी रुकावट है और इससे इसलिए, -1 मॉडिफ़ायर है.
SYSTEM_ALERT_WINDOW और टैपजैकिंग
SYSTEM_ALERT_WINDOW और टैपजैकिंग से जुड़ी हमारी नीतियों के बारे में जानकारी के लिए,
"गैर-सुरक्षा-गंभीर स्क्रीन पर टैपजैकिंग/ओवरले System_ALERT_WINDOW की आशंका" देखें सेक्शन ऑफ़ बगहंटर यूनिवर्सिटीज़
ऐसी गड़बड़ियां जिनसे सुरक्षा पर कोई असर नहीं पड़ा
करें.
Android Automotive OS में मल्टी-यूज़र सुरक्षा
Android Automotive OS में, कई उपयोगकर्ताओं वाले सुरक्षा मॉडल का इस्तेमाल किया जाता है यह अन्य डिवाइसों के नाप या आकार से अलग है. Android के हर उपयोगकर्ता को शारीरिक व्यक्ति. उदाहरण के लिए, कुछ समय के लिए रहने वाले उपयोगकर्ता, क़र्ज़ लेने वाले दोस्त को असाइन किए जा सकते हैं कार के मालिक का पास दिया गया है. इस तरह के उपयोग के उदाहरणों के लिए, उपयोगकर्ताओं के पास डिफ़ॉल्ट रूप से गाड़ी को इस्तेमाल करने के लिए ज़रूरी कॉम्पोनेंट, जैसे कि वाई-फ़ाई और मोबाइल नेटवर्क का ऐक्सेस दें सेटिंग.
वह कॉम्पोनेंट जिस पर असर हुआ है
गड़बड़ी को ठीक करने के लिए ज़िम्मेदार डेवलपमेंट टीम, इस बात पर निर्भर करती है कि गड़बड़ी किस कॉम्पोनेंट में है. यह Android प्लैटफ़ॉर्म का मुख्य कॉम्पोनेंट हो सकता है, किसी ओरिजनल कंपनी से सप्लाई किया गया कर्नेल ड्राइवर उपकरण निर्माता (OEM) या Pixel डिवाइसों पर पहले से लोड किए गए ऐप्लिकेशन में से किसी एक के पास हो.
एओएसपी कोड में आने वाली गड़बड़ियों को Android की इंजीनियरिंग टीम ठीक करती है. कम गंभीरता वाले बग, बग कुछ कॉम्पोनेंट या जिन गड़बड़ियों की जानकारी सार्वजनिक तौर पर पहले से दी गई है उन्हें सीधे तौर पर सार्वजनिक रूप से उपलब्ध एओएसपी की मुख्य शाखा; वे डेटा को स्टोर करने की हमारी इंटरनल रिपॉज़िटरी में ठीक कर सकते हैं. चुनें.
कॉम्पोनेंट से भी यह तय होता है कि उपयोगकर्ताओं को किस तरह से अपडेट मिलते हैं. फ़्रेमवर्क या कर्नेल में कोई गड़बड़ी ओवर-द-एयर (OTA) फ़र्मवेयर अपडेट की ज़रूरत होती है, जिसे हर OEM को पुश करना पड़ता है. किसी ऐप्लिकेशन में कोई गड़बड़ी या Google Play में पब्लिश की गई लाइब्रेरी (उदाहरण के लिए, Gmail, Google Play Services या वेबव्यू) इसे Android उपयोगकर्ताओं को Google Play से अपडेट के तौर पर भेजा गया था.
पार्टनर को सूचना देना
जब Android सुरक्षा बुलेटिन में एओएसपी में सुरक्षा से जुड़े जोखिम की आशंका को ठीक किया जाता है, तो हम आपको सूचना देते हैं समस्या की जानकारी देने और पैच मुहैया कराने के लिए, Android पार्टनर. उन वर्शन की सूची जिन पर बैकपोर्ट इस्तेमाल किया जा सकता है Android के हर नए वर्शन में बदलाव किए जाते हैं. इनकी सूची देखने के लिए, डिवाइस बनाने वाली कंपनी से संपर्क करें इस्तेमाल किए जा सकते हैं.
AOSP के लिए कोड रिलीज़ किया जा रहा है
अगर सुरक्षा से जुड़ी गड़बड़ी किसी एओएसपी कॉम्पोनेंट में है, तो ओटीए के बाद एओएसपी को गड़बड़ी ठीक कर दी जाती है उपयोगकर्ताओं के लिए रिलीज़ किया गया. कम गंभीर समस्याओं के लिए समाधान सीधे एओएसपी के मुख्य प्लैटफ़ॉर्म पर सबमिट किए जा सकते हैं OTA के ज़रिए डिवाइसों के लिए समाधान उपलब्ध होने से पहले ब्रांच.
Android के अपडेट मिल रहे हैं
Android सिस्टम के अपडेट, आम तौर पर ओटीए अपडेट पैकेज के ज़रिए डिवाइसों पर दिए जाते हैं. ये अपडेट, डिवाइस बनाने वाले OEM या मोबाइल और इंटरनेट सेवा देने वाली कंपनी की तरफ़ से मिल सकते हैं डिवाइस में मौजूद सेवा की जानकारी देता है. Google Pixel डिवाइस के अपडेट कैरियर टेक्निकल मंज़ूरी (टीए) टेस्ट के तौर पर जुड़ जाता है. Google, पब्लिशर के लिए Pixel की फ़ैक्ट्री इमेज, जिन्हें डिवाइसों पर साइड-लोड किया जाता है.
Google की सेवाएं अपडेट की जा रही हैं
सुरक्षा से जुड़ी गड़बड़ियों के लिए पैच उपलब्ध कराने के साथ-साथ, Android की सुरक्षा टीम सुरक्षा की समीक्षा करती है ताकि यह तय किया जा सके कि लोगों को सुरक्षित रखने के और भी तरीके हैं या नहीं. उदाहरण के लिए, Google Play सभी ऐप्लिकेशन को स्कैन करने के लिए, ऐप्लिकेशन इस्तेमाल करते हैं और ऐसे किसी भी ऐप्लिकेशन को हटा देते हैं जो सुरक्षा बग का फ़ायदा उठाने की कोशिश करता है. इससे इंस्टॉल किए गए ऐप्लिकेशन के लिए Google Play के बाहर से, Google Play सेवाएं वाले डिवाइस भी चेतावनी देने के लिए ऐप्लिकेशन की पुष्टि करें सुविधा नुकसान पहुंचा सकने वाले ऐप्लिकेशन के बारे में उपयोगकर्ताओं को जानकारी देनी होगी.
अन्य संसाधन
Android ऐप्लिकेशन डेवलपर के लिए जानकारी: https://developer.android.com पर जाएं
सुरक्षा से जुड़ी जानकारी सभी Android ओपन सोर्स और डेवलपर साइटों पर मौजूद रहती है. बढ़िया शुरू करने के लिए जगहें:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
रिपोर्ट
कभी-कभी Android सुरक्षा टीम रिपोर्ट या व्हाइट पेपर पब्लिश करती है. यहां जाएं: ज़्यादा जानकारी के लिए, सुरक्षा रिपोर्ट देखें.