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